分区表需合理设计：分区字段须高频出现在查询条件中且分布均匀；优先选时间字段按日/月分区，慎用高基数ID；配合索引并确保WHERE带分区键、避免函数操作。
分区表不是加个 PARTITION BY 就完事，关键在“分得合理、查得精准、管得省心”。核心原则是：**分区字段必须高频出现在查询条件中，且数据分布尽量均匀，避免热点和空分区。**
选对分区键：别让WHERE条件“跨分区”失效
分区键本质是查询的“入口开关”。如果常用查询条件里从不出现分区字段，数据库仍要扫描所有分区，性能反而更差。
-
优先选时间字段：如
create_time、event_date。按天/月/年分区后，查“最近7天订单”只需访问7个分区，跳过99%历史数据。 -
慎用高基数ID类字段：比如用户ID或订单号——除非你总按某几个ID批量查（如
user_id IN (1001,1002)），否则哈希分区也难保证局部性。 - 组合分区要克制：Range + List 或 Range + Hash 可行，但三层以上嵌套会增加维护成本，且MySQL 8.0+才稳定支持子分区。
定好分区粒度：太粗压不住数据倾斜，太细拖慢元数据管理
以日志表为例：
- 按天分区：适合日增千万级、需精确到日分析的场景（如实时监控）；但一年365个分区，DDL操作略慢。
- 按月分区：平衡性最好，常见于报表类系统；单分区体积可控，归档删除也方便（
ALTER TABLE DROP PARTITION）。 - 避免按小时分区：日增百万条就生成24个分区，一年超8000个，MySQL元数据压力大，SHOW CREATE TABLE都可能卡顿。
配合索引与查询写法：分区只是“筛层”，索引才是“加速器”
分区解决的是“扫哪些物理文件”，索引解决的是“在文件里怎么快速定位”。二者必须协同：
-
每个分区独立建索引：MySQL自动为每个分区创建本地索引（Local Index），无需手动干预；但要注意主键必须包含分区键（如按
dt分区，则主键需为(id, dt)或直接含dt）。 -
WHERE条件必须带上分区键：写成
WHERE dt = '2024-06-01' AND status = 1才能Pruning（分区剪枝）；若只写WHERE status = 1，就会全分区扫描。 -
避免函数操作分区键：不要写
WHERE DATE(dt) = '2024-06-01'，这会让分区失效；应改用WHERE dt >= '2024-06-01' AND dt 。
定期维护：分区不是一劳永逸，要防“老分区膨胀、新分区缺失”
长期运行后，常见两个问题：
-
历史分区堆积：用
ALTER TABLE ... DROP PARTITION定期清理（如保留最近12个月），比DELETE快百倍，且不锁全表。 -
未来分区未预建：Range分区不会自动扩容。建议用脚本每月提前建好下3个月的分区（如月底自动执行
ALTER TABLE ADD PARTITION），防止插入时因无目标分区报错。 -
检查是否真生效：执行
EXPLAIN PARTITIONS SELECT ...，看输出的partitions列是否只列出预期的几个分区名，不是NULL或全量。
