SQL分区表通过物理分片提升查询与维护效率，关键在于精准选择高区分度且常被过滤的分区键、匹配数据特征的RANGE/LIST/HASH/KEY策略、合理控制16~64个分区数量，并配合分区裁剪与定期维护。
SQL分区表不是简单把大表拆开，而是按规则把数据物理分片，让查询、维护更高效。设计好坏直接决定性能提升还是反拖后腿。
分区键选什么？核心是“常被过滤+高区分度”
分区键就是决定每行数据落到哪个分区的列。选错了，分区就形同虚设。
- 优先选WHERE里高频出现的列，比如order_time（查最近7天订单）、region_id（按地区统计）
- 避免用低基数列，比如status（只有0/1/2），容易导致分区倾斜——有的分区塞满，有的空着
- 尽量别用表达式或函数做分区键，如YEAR(create_time)在MySQL中不支持直接分区，得改用create_time本身再配合RANGE分区
用哪种分区策略？看数据特征和常用操作
常见策略有四种，适用场景差异明显：
- RANGE分区：适合时间字段（如按月/年归档日志），或数值范围（如用户ID分段）。注意边界连续且不重叠
- LIST分区：适合明确有限枚举值，比如按province_code分华东、华北、华南三个分区。增删区域时只需调整LIST，不用动数据
- HASH分区：适合均衡分布，比如按user_id % 4分4个区。但无法做范围查询（如“查user_id在1000~5000之间的记录”会跨多个分区）
- KEY分区：类似HASH，但由数据库自动哈希（支持非数字列，如VARCHAR），MySQL推荐替代HASH用于主键/唯一键场景
分区数量多少合适？别贪多，也别太少
分区不是越多越好。太多会增加元数据开销、影响DDL速度；太少又起不到隔离效果。
- 常规建议：单表16~64个分区较平衡。比如按月分区，覆盖3~5年数据，大概36~60个分区
- 超大宽表（百列+TB级）可适当增加，但需配合实际IO能力测试
- 特别注意：MySQL单表最多8192个分区，PostgreSQL无硬限制但超过200个需谨慎评估维护成本
别忘了配套动作：分区裁剪和定期维护
分区生效的前提是查询能触发Partition Pruning（分区裁剪）——只扫相关分区，跳过无关的。
- 写SQL时，WHERE条件必须包含分区键（且不能被函数包裹），否则可能全分区扫描
- 定期做DROP PARTITION（历史归档）或REORGANIZE PARTITION（合并小分区），避免碎片化
- 新建分区要提前（比如每月1号前建下月分区），防止插入时因无目标分区报错
基本上就这些。分区表不是银弹，但它能把“查得慢、删得卡、备份崩”的痛点，变成可预测、可管理的操作。关键不在多，而在准——键选得准、策略用得准、维护跟得准。
