SQL分区表的核心是实现查询“精准落库”，需基于业务访问模式选择分区键（如event_time、tenant_id），控制分区数量（1–5GB/分区），并配套本地索引、统计更新和执行计划验证，否则反而降低性能。
SQL分区表不是加个PARTITION BY就完事，核心是让查询能“精准落库”，否则反而拖慢性能、增加维护成本。设计前必须明确业务访问模式，再匹配分区策略，而不是先建再想怎么用。
明确分区目标：查得快，删得快，管得住
分区不是万能优化手段，只在以下场景真正有效：
- 按时间范围高频查询（如查最近30天订单）
- 按业务线/租户隔离数据（如多租户SaaS中按
tenant_id分片） - 定期清理历史数据（如每月自动
DROP PARTITION或TRUNCATE PARTITION） - 大表避免单点锁争用或IO瓶颈（需配合合理索引和执行计划）
如果查询经常跨分区、或WHERE条件不带分区键，分区反而引入额外路由开销，查询可能更慢。
选对分区键：必须是查询条件的高频等值或范围字段
分区键不是主键，也不是随意挑个字段。它必须满足两个硬性条件：
-
高频出现在WHERE子句中——比如日志表按
event_time分区，但查询总写WHERE user_id = ?，那就白分了 -
值分布相对均匀——避免“热点分区”，例如用
status（只有0/1）分区会导致90%数据挤在2个分区里
常见合理组合：DATE(event_time)（按天）、YEAR(event_time), MONTH(event_time)（按月二级分区）、HASH(tenant_id)（租户均衡打散）。
控制分区数量：别贪多，也别太少
分区数直接影响元数据管理开销和查询规划器负担：
- 按时间分区：建议单分区数据量在1–5GB之间，太小（如每小时一分）会导致分区数爆炸（一年超8000个），MySQL 8.0+虽支持，但
SHOW PARTITIONS、EXPLAIN会明显变慢 - 按HASH/KEY分区：分区数通常取2的幂（如4/8/16/32），便于哈希均匀；超过64个需谨慎评估收益
- 避免“动态无限建分区”逻辑——不要在应用层每次插入都判断并
ADD PARTITION，应预建未来3–6个月分区，配合定时任务补位
配套必须跟上：索引、统计、执行计划一个不能少
分区表≠自动优化。这些动作漏掉一个，效果直接打折：
-
每个分区独立维护本地索引——建表时用
LOCAL INDEX（MySQL）或确认PG的分区索引是否USING INDEX绑定正确 -
定期更新统计信息——尤其在大批量导入或删除分区后，执行
ANALYZE TABLE或VACUUM ANALYZE，否则优化器可能误判分区剪枝效果 -
查
EXPLAIN确认是否“Partition Pruning”生效——输出中看到partitions: p202404,p202405才表示真正只扫了2个分区；若显示partitions: all，说明分区键没走对或隐式类型转换导致失效
基本上就这些。分区是把双刃剑，设计阶段多花1小时想清楚访问模式，上线后能省下几十小时排障时间。不复杂，但容易忽略关键细节。
