mysql单表文件过大本身不直接导致性能下降，真正拖慢的是查询时被迫扫描的物理页数和索引失效带来的随机io；innodb分区表仅在查询能精准命中少数分区时有效，否则全分区扫描开销更大。
MySQL单表文件过大本身不会直接导致性能下降，真正拖慢的是查询时被迫扫描的物理页数和索引失效带来的随机IO。InnoDB分区表不是“银弹”，它只在特定条件下有效——必须让查询能精准落到单个或少数几个分区上，否则比普通大表还慢。
为什么PARTITION BY RANGE常被误用
很多人照着文档建了按id或create_time分区的表，但业务查询根本没带上分区键，比如：
SELECT * FROM orders WHERE user_id = 12345;
这种查询会触发全分区扫描，MySQL要打开每个分区的.frm + .ibd文件、读取各自的索引B+树、合并结果——开销远高于单表一次B+树遍历。
- 分区裁剪（partition pruning）只发生在
WHERE条件中明确包含分区字段且能静态推导时 -
user_id即使有索引，在分区表里也变成“二级索引下的二级索引”，回表路径更长 - 分区数不是越多越好：
PARTITION p0 ... p99会让优化器执行计划生成变慢，尤其涉及GROUP BY或ORDER BY时
EXPLAIN PARTITIONS必须每次验证
建完分区表后，不跑EXPLAIN PARTITIONS就上线，等于盲开。
正确示例（假设按月分区）：
EXPLAIN PARTITIONS SELECT * FROM orders WHERE order_date >= '2025-03-01' AND order_date <p>输出中的<code>partitions</code>列应只显示<code>p202503</code>；如果出现<code>p202501,p202502,p202503,...</code>或<code>all</code>，说明没裁剪成功。</p>
- 时间字段必须是
DATE/DATETIME类型，不能是VARCHAR存的字符串日期 - 避免使用函数包裹分区字段：
WHERE YEAR(order_date) = 2025会禁用裁剪 - 分区字段上建的索引，必须是该字段单独作为最左前缀，比如
(order_date, status)可以，(status, order_date)不行
分区表与普通表索引的差异
分区表的每个分区都是独立的InnoDB子表，所以：
- 主键必须包含分区字段（否则建表报错），例如
PRIMARY KEY (id, order_date) - 二级索引默认是
local的：每个分区维护自己的索引B+树，user_id索引在每个分区里都存在一份 - 想全局去重？
UNIQUE索引必须包含分区字段，否则无法保证跨分区唯一性 - 删除旧分区用
ALTER TABLE orders DROP PARTITION p202401，比DELETE快得多且不产生undo log，但要注意外键约束会阻止该操作
比分区更值得优先尝试的替代方案
多数场景下，以下三件事比急着上分区更有效：
- 确认
innodb_buffer_pool_size是否设到物理内存的60%–70%，否则再好的索引也卡在磁盘IO - 把高频查询的
WHERE + ORDER BY + SELECT字段组合成覆盖索引，避免回表，例如INDEX (user_id, status, create_time)配合SELECT id, status FROM ... - 用归档表替代分区：把历史数据
INSERT INTO orders_archive SELECT ... FROM orders WHERE create_time ，再<code>DELETE，简单直接且不影响线上查询逻辑
分区表真正的适用点很窄：你有稳定的时间范围查询模式，且能接受DDL变更复杂度；一旦业务查询模式漂移，分区反而成为技术债。别为了“用了新技术”而分区，只为“这一步能让某类慢查询从秒级降到毫秒级”才动它。
