SQL分区表需实现数据分布、查询路径、维护成本的正向闭环；分区键应高频出现在WHERE等值/范围条件中且基数适中、更新少；粒度宜控单分区200万~2000万行或1~10GB；须避免隐式转换、函数包裹分区键及索引未覆盖分区键等问题。
SQL分区表不是简单加个PARTITION BY就完事，核心在于让数据分布、查询路径、维护成本三者形成正向闭环。设计失败的分区表，轻则查得慢、写得卡，重则引发锁表、元数据膨胀、甚至误删整区数据。
分区键选什么？看查询模式，不是看时间或ID
很多人一上来就按create_time年月分区，结果发现80%的查询带的是user_id和status，导致每次都要扫全分区——分区失效。关键逻辑是：分区键必须高频出现在WHERE条件的等值或范围过滤中，且该字段基数适中、更新极少。
- 订单系统若常查“某用户近3个月订单”，
(user_id, create_time)组合分区比单按时间更有效 - 日志表按
log_type一级分区 +event_date二级分区，能同时支持按类型聚合和按日期归档 - 避免用自增ID或UUID做分区键——分布看似均匀，但几乎无法用于过滤，等于白分
分区粒度怎么定？平衡扫描效率与管理开销
粒度太粗（如按年分区），单分区过大，查询仍要扫描大量无关数据；粒度太细（如按小时分1万+分区），会导致元数据暴涨、DDL变慢、MySQL 5.7前可能触发Too many partitions错误。
- 通用经验：单分区数据量控制在200万~2000万行，或物理大小在1~10GB之间
- 按天分区适合日活百万级业务；按周/月更适合数据增长平缓、查询跨度大的分析型场景
- 提前预估3~5年数据总量，再反推分区数量上限（例如MySQL建议不超过8192个分区）
如何让旧分区自动归档、新分区自动创建？靠事件+脚本双保险
MySQL原生不支持自动创建未来分区，PostgreSQL虽有FOR VALUES FROM...TO语法，但仍需手动维护。真正可靠的方案是“定时任务+预建机制”：
- 用存储过程+事件调度器（Event Scheduler），每天凌晨检查并新增下N个月的分区（如预建6个月）
- 对过期分区，不直接
DROP，而是先RENAME到归档库，再异步清理，避免长事务阻塞 - 配合应用层配置开关（如
partition_auto_manage=on），灰度启用，避免误操作影响线上
分区后查询为什么还是慢？检查这三点再优化
执行计划里出现type=ALL或partitions=NULL，说明分区没生效。常见原因：
-
隐式类型转换：查询条件用字符串传数字ID（
WHERE user_id = '123'），导致分区裁剪失败 -
函数包裹分区键：如
WHERE DATE(create_time) = '2024-01-01'，应改写为create_time >= '2024-01-01' AND create_time - 联合索引未覆盖分区键：分区键未纳入索引最左前缀，或索引顺序不合理，导致无法利用分区+索引双重剪枝
基本上就这些。分区表不是银弹，它是把双刃剑——用对了，查得快、删得稳、扩得平；用错了，就是给系统埋雷。重点始终是：以查询驱动设计，用数据验证效果，靠机制保障可持续。
