MySQL分区表不自动加速查询，仅当查询条件直接使用分区键触发分区裁剪时才减少I/O；否则可能比普通表更慢。

分区表不是自动加速查询的银弹

MySQL 分区表本身不提升单条查询性能，甚至可能让简单查询变慢。它真正起作用的场景是：配合 PARTITION PRUNING（分区裁剪），让优化器跳过大量无关分区，从而减少 I/O 和扫描行数。如果查询条件没用到分区键，或者用了函数/表达式导致无法裁剪，那所有分区都会被扫描——此时性能反而比普通表更差。

必须用分区键做查询条件才能触发裁剪

假设你按 created_at 做了 RANGE 分区，那么只有形如 WHERE created_at >= '2025-01-01' 或 WHERE created_at BETWEEN '2025-01-01' AND '2025-06-30' 这类直接比较才可能裁剪。以下写法会失效：

• WHERE DATE(created_at) = '2025-01-01'（函数包裹，无法裁剪）
• WHERE YEAR(created_at) = 20

  

  25（同上）
• WHERE created_at + INTERVAL 1 DAY > '2025-01-01'（表达式，裁剪失败）
• WHERE id = 123（没用到分区键，全分区扫描）

验证是否裁剪成功，执行 EXPLAIN PARTITIONS SELECT ...，看 partitions 列是否只列出部分分区名。

常见分区策略选型与陷阱

RANGE 和 LIST 分区支持裁剪最稳定；HASH 和 KEY 分区仅适用于等值查询且分区数为 2 的幂次时效果较好。实际中容易踩的坑包括：

• 按 id HASH 分区后，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 同步）。