MySQL分区表不自动加速查询，仅当查询条件直接使用分区键触发分区裁剪时才减少I/O；否则可能比普通表更慢。
分区表不是自动加速查询的银弹
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 同步）。
