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 号前建下月分区），防止插入时因无目标分区报错
基本上就这些。分区表不是银弹，但它能把“查得慢、删得卡、备份崩”的痛点，变成可预测、可管理的操作。关键不在多，而在准——键选得准、策略用得准、维护跟得准。
