SQL分区表设计核心是按查询习惯自然切分数据，优先选高频查询字段（如时间范围用RANGE、用户ID用HASH），避免低选择性字段，分区数宜控制在16–512间，需配合明确WHERE条件触发分区裁剪。
SQL分区表设计核心是让数据按查询习惯“自然切分”，不是越多分区越好，而是让常用查询条件能精准命中少数分区，跳过大量无关数据。
按查询频率最高的字段分区
比如订单表常按时间范围查最近30天，就用日期字段做RANGE分区；用户行为日志常按用户ID聚合分析，可考虑HASH分区（如user_id % 64）。避免用变动频繁或低选择性的字段（如性别、状态码）做分区键，否则容易导致数据倾斜或分区失效。
控制分区数量适中，别盲目拆多
- MySQL建议单表分区数在16–512之间，超1000个分区可能引发元数据管理开销和DDL变慢
- PostgreSQL对分区数量更友好，但每个分区仍需独立统计信息，太多会拖慢ANALYZE和执行计划生成
- 按月分区的表运行5年后有60个分区，基本可控；按天分区满一年就有365个，需评估是否真需要——可前期按月，后期冷数据再按天细化归档
配合分区裁剪，写SQL时注意写法
分区裁剪（Partition Pruning）不会自动生效，需确保WHERE条件中分区键参与且形式明确：
- ✅ 支持裁剪：
WHERE create_time >= '2024-01-01' AND create_time - ❌ 不触发裁剪：
WHERE DATE(create_time) = '2024-01-15'（函数包裹导致无法匹配分区边界） - ⚠️ 注意隐式类型转换：
WHERE partition_key = '2024'（字符串）vs= 2024（整型），可能导致分区失效
定期维护分区，别建完就丢
分区表不是一劳永逸，要主动管理生命周期：
- 自动清理过期分区：用
DROP PARTITION或DETACH PARTITION（PG）移除历史数据，比DELETE快得多 - 新增未来分区：提前创建下季度/下个月的空分区，避免INSERT时动态创建带来的锁与延迟
- 检查数据分布：用
SELECT PARTITION_NAME, TABLE_ROWS FROM INFORMATION_SCHEMA.PARTITIONS（MySQL）观察是否严重倾斜
基本上就这些。分区是利器，但依赖合理设计和持续运营，不是加了PARTITION BY就自动变快。
