SQL分区表设计核心是匹配业务访问模式，需合理选分区键（如高频查询字段）、定策略（RANGE/LIST/HASH）、控数量（16–512个），并配套索引、统计更新与自动化维护。
SQL分区表不是简单加个PARTITION BY就完事，核心在于让数据分布匹配业务访问模式——查得快、删得稳、扩得平、维护少。设计错一分，后期运维苦十分。
分区键选什么？看查询条件，不看“看起来整齐”
分区键必须是高频查询的过滤字段，且值分布要相对均匀。比如订单表按order_time分区很常见，但若80%订单集中在最近7天，而历史数据极少被查，那按月分区可能造成热点；反过来，若常按user_id查单个用户全量订单，且用户量大、订单分布均衡，user_id反而是更优选择。
- 优先选WHERE里稳定出现的字段（如
create_date、region_code、tenant_id） - 避免用高基数但无过滤价值的字段（如自增ID、UUID）
- 慎用多列组合分区——MySQL不支持，PostgreSQL虽支持但管理复杂，通常不如单列+二级索引灵活
分区策略怎么定？时间类用RANGE，租户类用LIST或HASH
主流策略就三种，适用场景差异明显：
-
RANGE分区：适合时间序列、金额区间等有天然顺序的数据。例如按
YEAR(create_time)或TO_DAYS(create_time)切分，便于按年/月归档、快速删除过期分区（ALTER TABLE ... DROP PARTITION） -
LIST分区：适合枚举型、离散值明确的字段，如
province_code或app_version。增删分区只需对应新增区域或版本，逻辑清晰 -
HASH分区：适合高基数且无规律的字段（如
user_id），能均匀打散数据。但无法做范围查询，也不支持删除旧数据——只能整体迁移或按条件DELETE
分区数量多少合适？宁少勿多，先跑再调
分区不是越多越好。每个分区是独立段（segment），过多会抬高元数据开销、拖慢DDL、增加查询优化器决策成本。经验参考：
- 单表建议控制在16~512个分区之间，具体看数据总量和单分区大小
- 目标单分区数据量：MySQL建议1–5GB，PostgreSQL建议5–20GB（取决于内存与IO能力）
- 新表起步可设6–12个预分配分区，后续按增长节奏动态添加（如每月加1个RANGE分区）
配套动作不能省：索引、统计、维护计划
分区表不是“设完即赢”，它放大了不规范操作的风险：
- 每个分区默认继承主表索引，但务必确认关键查询字段已建索引——分区剪枝（pruning）生效的前提是能走索引定位到具体分区
- 定期更新统计信息（如MySQL的
ANALYZE TABLE），否则优化器可能误判分区数，导致全分区扫描 - 设置自动化脚本管理生命周期：自动创建下月分区、自动清理N个月前分区、监控各分区行数偏差（防数据倾斜）
基本上就这些。分区表本质是数据治理的物理层表达，设计时多问一句“我最常怎么查、怎么删、怎么扩容”，答案自然浮现。
