分区表不是自动加速查询的银弹
MySQL 分区表本身不提升单条查询性能，甚至可能让简单查询变慢。它真正起作用的场景是：配合
PARTITION PRUNING（分区裁剪），让优化器跳过大量无关分区，从而减少 I/O 和扫描行数。如果查询条件没用到分区键，或者用了函数/表达式导致无法裁剪，那所有分区都会被扫描——此时性能反而比普通表更差。
必须用分区键做查询条件才能触发裁剪
假设你按
created_at做了 RANGE 分区，那么只有形如
WHERE created_at >= '2024-01-01'或
WHERE created_at BETWEEN '2024-01-01' AND '2024-06-30'这类直接比较才可能裁剪。以下写法会失效：
WHERE DATE(created_at) = '2024-01-01'（函数包裹，无法裁剪）
WHERE YEAR(created_at) = 2024（同上）
WHERE created_at + INTERVAL 1 DAY > '2024-01-01'（表达式，裁剪失败）
WHERE id = 123（没用到分区键，全分区扫描）
验证是否裁剪成功，执行
EXPLAIN PARTITIONS SELECT ...，看
partitions列是否只列出部分分区名。
常见分区策略选型与陷阱
RANGE 和 LIST 分区支持裁剪最稳定；HASH 和 KEY 分区仅适用于等值查询且分区数为 2 的幂次时效果较好。实际中容易踩的坑包括：
按idHASH 分区后，
WHERE id IN (1,2,3)看似能裁剪，但 MySQL 5.7+ 才完善支持，旧版本可能扫全表 按时间 RANGE 分区时，忘记定期
ALTER TABLE ... REORGANIZE PARTITION添加新分区，导致新数据全落到
MAXVALUE分区，热点集中 分区数过多（比如按天分 3 年 = 1095 个分区），会导致打开表文件数暴增、DDL 变慢、元数据锁竞争加剧 唯一索引必须包含分区键，否则建表失败：
UNIQUE KEY (a,b)在按
c分区时，必须写成
UNIQUE KEY (a,b,c)
分区表维护成本常被低估
分区表的
OPTIMIZE PARTITION、
TRUNCATE PARTITION虽快，但 DDL 操作仍需锁表（MySQL 8.0 对部分操作已支持并发，但非全部）。更隐蔽的问题是： 备份工具（如 mysqldump）默认不识别分区，
--single-transaction下可能产生不一致快照 Percona XtraBackup 支持分区级备份，但恢复时不能只还原单个分区，必须整表还原 监控项如
information_schema.PARTITIONS查询本身在分区数多时就变慢，影响运维脚本 主从复制中，分区 DDL 若跨版本（如 5.7 → 8.0），可能因分区语法差异导致中断
真正需要分区的信号，不是“数据量大”，而是“有明确的冷热分离边界 + 高频按该维度过滤 + 删除旧数据频繁”。否则，先考虑归档表、覆盖索引或列存引擎（如 ClickHouse 同步）。
