MySQL：分区数控制在1000以内和“8192上限按天能撑22年”两种说法打架，分区过多的DDL和元数据到底会慢到什么程度？

一、两种说法的来源与语义澄清

1.1 “8192 上限”是结构约束，不是性能承诺

MySQL 官方文档在 Partitioning Limitations Relating to Storage Engines 一节中明确：InnoDB 单表最多 8192 个分区，MyISAM 亦为 8192，且该上限与 open_files_limit、文件系统 inode 数量无直接绑定关系（MySQL 8.0 Reference Manual, 26.6.1）。这个数字的来历与早期分区实现中分区 ID 的位宽、以及内部表定义缓存的数组规模有关，属于“能表达”的上界，而非“能高效运行”的推荐值。

“8192 按天能撑 22 年”的推算逻辑是：8192 ÷ 365 ≈ 22.4。这个算式在数学上无误，但它隐含了三个强假设：每天恰好新增一个分区、期间不执行任何重建类 DDL、且查询与写入模式对分区裁剪完全友好。本文评述：该推算把“容量上限”误读为“可持续运行年限”，混淆了静态容量与动态运维成本，属于典型的边界条件缺失型结论。

1.2 “1000 以内”是经验阈值，来源分散且口径不一

“分区数控制在 1000 以内”在中文技术社区流传甚广，但很难追溯到单一权威出处。它更可能是多条独立经验的收敛：Percona 工程师在多次博客中提及“数百到一千量级后 DDL 与元数据锁开销显著上升”；部分云厂商的 RDS 规格文档对分区数给出建议区间；以及大量生产事故复盘中的“分区膨胀导致 ALTER TABLE ... REORGANIZE PARTITION 超时”案例。

笔者认为，1000 这个数字的工程价值不在于精确，而在于它对应了一个可观测的拐点区间：当分区数进入四位数，多数团队的表打开缓存（table_open_cache）、元数据锁等待、以及 DDL 的拷贝成本开始从“可忽略”转为“需要专门设计”。把它当作量级提示而非硬阈值，才是正确用法。

1.3 本文的分析主线：把“分区数”还原为四条成本链路

要回答“分区过多到底慢到什么程度”，必须先把“慢”拆开。笔者认为，分区数增长对 MySQL 的影响沿四条链路传导，每条链路的成本函数形态不同，拐点位置也不同：

链路一（文件层）：分区 → 独立表空间/文件 → 文件句柄与表打开缓存压力，近似线性但受缓存命中率调制。
链路二（字典层）：分区 → 数据字典中的分区对象 → 元数据锁与字典遍历，近似线性，但在 DDL 时表现为“全表遍历”。
链路三（DDL 层）：分区 → 重建/重组操作的拷贝与锁持有时间，近似线性甚至超线性（受排序与临时空间影响）。
链路四（优化器层）：分区 → 裁剪候选集 → 计划生成与统计信息维护，通常被裁剪后影响很小，但裁剪失效时急剧放大。

这条主线将贯穿全文：每一节都对应一条链路，给出机制、可测量指标与工程含义。读者可以据此判断自己的场景卡在哪条链路上，而不是笼统地问“分区多了会不会慢”。

二、成本平面一：文件层与表空间碎片

2.1 每个分区都是一个独立的物理单元

在 innodb_file_per_table=ON（MySQL 8.0 默认）下，每个分区对应一个独立的 .ibd 文件。一个 8192 分区的表，意味着至少 8192 个数据文件，加上每个分区可能存在的二级索引段、以及通用表空间场景下的段管理开销。文件系统层面，这直接消耗 inode，并让 fsync、目录遍历、备份工具的元数据扫描成本上升。

MySQL 8.0 引入的 InnoDB 通用表空间与临时表空间池在一定程度上缓解了文件数问题，但分区表默认仍走 file-per-table。官方文档亦提示，分区表在 open_files_limit 不足时可能触发“Too many open files”，需要同步调大该参数与 table_open_cache。

2.2 表打开缓存：分区数放大了缓存抖动的概率

table_open_cache 缓存的是“打开的表对象”，对分区表而言，每个被访问的分区都可能占用一个缓存槽位。若一个 2000 分区的表被全分区扫描（例如缺少分区键条件），瞬间需要打开的分区对象数远超缓存容量，触发 LRU 淘汰与反复打开/关闭，表现为 Opened_tables 快速增长、Table_open_cache_misses 上升。

这里的关键不是“分区多就一定慢”，而是分区多 + 查询未裁剪的组合。一个 5000 分区但每次查询都精确命中 1 个分区的表，其文件层压力与 10 分区表几乎相同；反之，一个 500 分区但频繁全扫的表，可能比前者更早出问题。本文评述：文件层成本的可控性很高，前提是把“分区裁剪命中率”作为核心 SLO 来监控。

三、成本平面二：数据字典与元数据锁

3.1 MySQL 8.0 数据字典的事务化改造

MySQL 8.0 将原先散落在 .frm 文件中的元数据收敛到 InnoDB 内的数据字典表（mysql.tables、mysql.partitions 等）。这一改造的收益是原子 DDL 与崩溃一致性，代价是元数据操作从“文件系统调用”变为“事务性表访问”，分区对象越多，字典表的行数越多，相关查询的扫描成本越高。

官方文档（MySQL 8.0 Reference Manual, 16.1 Data Dictionary）指出，数据字典表的访问走普通 InnoDB 路径，受 buffer pool 与索引影响。这意味着分区数增长会直接增加 mysql.partitions 的行数，进而影响任何需要枚举分区的操作（如 SHOW CREATE TABLE、information_schema.partitions 查询、以及 DDL 前的元数据加载）。

3.2 元数据锁（MDL）的持有时间与分区数的关系

MDL 是 MySQL 5.5 引入、5.7/8.0 强化的机制，用于保护表结构在语句执行期间不被并发修改。对分区表执行 DDL 时，MDL 需要覆盖“表 + 所有分区”的元数据对象。分区数越多，MDL 的申请、释放、以及等待队列中的对象数越多，MDL 等待的尾部延迟越容易放大。

这一点在 performance_schema.metadata_locks 中有直接观测：一个 8192 分区的表在执行 ALTER TABLE ... ADD PARTITION 时，可能产生数千条 MDL 记录，导致该视图查询本身变慢，也让“谁在阻塞谁”的排查变得困难。笔者认为，这是 1000 阈值最容易被低估的一面：它不只是 DDL 慢，而是故障排查的可观测性成本同步上升。

实操提示：排查分区表 MDL 阻塞时，可先查 performance_schema.metadata_locks 按 OBJECT_NAME 聚合计数，再结合 sys.schema_table_lock_waits 定位阻塞源。分区数大时建议先加 WHERE OBJECT_TYPE='TABLE' 过滤，避免视图本身被分区级记录淹没。

3.3 字典遍历的“全表扫描”性质

许多分区相关操作在语义上要求“知道所有分区”。例如 ALTER TABLE ... REORGANIZE PARTITION 需要校验分区定义、EXCHANGE PARTITION 需要定位目标分区、备份工具需要枚举所有分区文件。这些操作的复杂度是 O(N)（N 为分区数），且常数项包含字典表访问与文件系统调用。

本文评述：O(N) 本身不可怕，可怕的是 N 很大时这个 O(N) 发生在持锁路径上。若字典遍历发生在 MDL 持有期间，则 N 的增长会直接转化为锁持有时间的增长，进而放大并发事务的等待。这是“分区数影响并发吞吐”的主要机制之一，也是分段决策模型需要重点建模的部分。

四、成本平面三：DDL 算法与分区维护操作

4.1 DDL 算法的分类与分区表的适用性

MySQL 8.0 的 DDL 支持 INSTANT、INPLACE、COPY 三类算法。分区表的特殊性在于：分区维护类 DDL（ADD/DROP/REORGANIZE/EXCHANGE/TRUNCATE PARTITION）通常无法走 INSTANT，多数需要 INPLACE 或 COPY，且操作粒度是“分区级”而非“行级”。

以最常见的 ADD PARTITION 为例，在 RANGE 分区末尾追加分区通常是轻量操作（仅更新元数据），但在 MAXVALUE 已存在时需要先 REORGANIZE，成本陡增。而 DROP PARTITION 虽快，却会触发统计信息失效与执行计划重编译。

4.2 重建类 DDL 的成本函数

当 DDL 需要 COPY 算法时，成本近似为“数据量 × 拷贝 + 索引重建 + 临时空间”。分区数在此处的放大效应体现在两方面：其一，每个分区独立建表空间、独立写 redo/undo，文件切换与 fsync 次数随分区数增加；其二，若 DDL 涉及分区定义变更（如 REORGANIZE），需要对受影响分区的全部数据做重分布，成本与“受影响分区数据量”成正比，而非与总数据量成正比——这是分区表做 DDL 的相对优势，但前提是操作能精确限定在少数分区上。

笔者认为，这里存在一个常被忽视的反直觉结论：在“只操作少量分区”的场景下，分区数多反而可能让单次 DDL 更快（因为单分区数据量小）；真正让 DDL 变慢的是“需要遍历或重建全部分区”的操作，例如修改分区键、重建整表、以及某些版本的 ALTER TABLE ... PARTITION BY 重定义。因此，“分区多导致 DDL 慢”必须限定操作类型，不能一概而论。

4.3 一个可操作的 DDL 时间估算框架

工程上需要的不是精确公式，而是量级判断。笔者建议用如下框架估算分区表 DDL 的耗时（模拟数据，用于说明结构，非实测）：

T_ddl ≈ T_meta(N) + T_copy(D_affected) + T_index(I_affected) + T_sync(F)

T_meta(N)      : 字典遍历与 MDL 申请，随分区数 N 近似线性
T_copy(D)      : 受影响分区数据量 D 的拷贝时间，受 IO 带宽约束
T_index(I)     : 受影响分区索引重建时间
T_sync(F)      : 文件创建/删除/fsync，随受影响文件数 F 增长

关键判断：
- 若操作只影响 1 个分区，T_meta 占比随 N 上升，是主要变量；
- 若操作影响全部分区，T_copy 主导，N 的影响被摊薄；
- 若 N 很大且 T_meta 占比高，应优先考虑减少 N 或改用非分区方案。

这个框架的价值在于把“分区多导致 DDL 慢”拆成可分别优化的项。例如，若观测到 T_meta 占比高，可通过减少分区数、或把大表拆成多张中等分区表来缓解；若 T_copy 占比高，则应优化 IO 或改用 EXCHANGE PARTITION 的“影子表”模式。

五、成本平面四：优化器路径与执行计划

5.1 分区裁剪是“第一道闸门”

MySQL 优化器对分区表的处理分为两步：先做分区裁剪（partition pruning），把候选分区集缩小；再在候选集上做常规的访问路径选择。裁剪发生在优化阶段早期，依据是 WHERE 条件中的分区键谓词。若谓词能精确命中少数分区，后续优化成本与普通表无异；若裁剪失效（如对分区键使用函数、隐式类型转换、或谓词不包含分区键），候选集退化为全部分区，优化器需要为每个分区估算行数并合并，成本随 N 增长。

官方文档（MySQL 8.0 Reference Manual, 26.4 Partition Pruning）列出了裁剪生效的条件，包括分区键必须是列引用、谓词需为常量或可求值表达式等。本文评述：裁剪失效是分区表最常见的性能事故来源，而它与分区数的关系是“乘法”而非“加法”——裁剪失效时，N 越大，代价越高；裁剪有效时，N 几乎无关。因此，监控“裁剪命中率”比监控“分区数”更有意义。

5.2 统计信息与分区级基数

InnoDB 的统计信息以索引为单位采集，分区表的每个分区有自己的统计信息。当优化器需要跨分区估算时，会聚合各分区的基数。分区数越多，统计信息的采集与聚合成本越高，且 ANALYZE TABLE 的耗时随分区数线性增长。对于 8192 分区的表，一次全量统计信息采集可能耗时数分钟到数十分钟，期间占用 IO 与 CPU。

笔者认为，统计信息成本是“1000 阈值”在优化器层的直接体现：当分区数进入四位数，ANALYZE TABLE 从“秒级后台任务”变成“需要调度窗口的运维操作”，进而影响执行计划的稳定性。这是一个典型的“量变引起质变”场景。

5.3 执行计划缓存与 Prepared Statement

MySQL 8.0 移除了查询缓存，但保留了 Prepared Statement 的执行计划复用。分区表的执行计划中会记录候选分区列表，当分区结构变化（ADD/DROP PARTITION）时，相关计划需要失效重编译。分区数多、DDL 频繁的场景下，计划重编译的频率上升，表现为 Com_stmt_reprepare 增长与偶发的延迟毛刺。

这一层的成本通常小于前三层，但在高并发短查询场景下不可忽略。工程上的缓解手段包括：避免在业务高峰执行分区 DDL、使用 pt-online-schema-change 或 gh-ost 的在线变更路径、以及把分区维护放在低峰窗口。

六、可复现的压测方法与度量口径

6.1 压测设计原则

要回答“慢到什么程度”，必须有可复现的度量。笔者建议的压测设计遵循三条原则：其一，固定数据总量，只改变分区数，避免数据量成为混杂变量；其二，分别测量四条链路的指标，而不是只看 QPS；其三，记录硬件与配置基线，因为分区成本对 IO 与内存高度敏感。

具体做法：构造一张按天分区的日志表，数据总量固定为约 5000 万行，分别创建 100、500、1000、2000、4000 个分区的变体（模拟数据，用于方法演示），在相同硬件上执行以下操作并记录耗时：ADD PARTITION、DROP PARTITION、ANALYZE TABLE、SHOW CREATE TABLE、以及一次裁剪命中与一次裁剪失效的查询。

6.2 度量口径与记录模板

-- 记录 MDL 等待（执行 DDL 期间另开会话采样）
SELECT OBJECT_TYPE, OBJECT_NAME, LOCK_TYPE, LOCK_STATUS, COUNT(*) AS cnt
FROM performance_schema.metadata_locks
GROUP BY OBJECT_TYPE, OBJECT_NAME, LOCK_TYPE, LOCK_STATUS
ORDER BY cnt DESC LIMIT 20;

-- 记录表打开缓存命中情况
SHOW GLOBAL STATUS WHERE Variable_name IN
('Opened_tables','Table_open_cache_misses','Innodb_open_files');

-- 记录分区级统计信息采集耗时（前后取时间差）
SELECT NOW(6);
ANALYZE TABLE t_log;
SELECT NOW(6);

-- 记录裁剪命中情况（EXPLAIN 的 partitions 列）
EXPLAIN SELECT * FROM t_log WHERE dt = '2024-06-01';

记录模板应包含：分区数、数据总量、硬件规格、MySQL 版本、innodb_buffer_pool_size、table_open_cache、以及上述各项耗时。只有口径一致，跨团队的数据才可比较。

6.3 预期趋势与解读

基于前述机制，合理的预期是：ADD/DROP PARTITION 的耗时随分区数缓慢上升（元数据主导），在 1000 附近开始出现可感知的抬升；ANALYZE TABLE 与 SHOW CREATE TABLE 近似线性增长；裁剪命中的查询耗时基本持平，裁剪失效的查询耗时随分区数显著上升。若实测与预期偏离，应优先检查是否有隐式类型转换、函数包裹分区键、或统计信息陈旧。

本文评述：压测的意义不在于得到一个“绝对阈值”，而在于建立“本环境下的成本曲线”。不同硬件、不同 MySQL 小版本、不同 innodb_buffer_pool_size 都会让曲线平移。把曲线画出来，比记住一个数字更有价值。

七、分段决策模型与工程阈值建议

7.1 三区间模型

综合四条链路的成本形态，笔者提出一个三区间决策模型（基于机制推理与社区实践归纳，非精确实测）：

7.2 操作路径：从评估到落地

若现有表已进入红区，建议按以下步骤处理：第一步，用 information_schema.partitions 统计各分区行数，识别“大量空分区或极小分区”；第二步，评估能否用 DROP PARTITION 清理历史分区（注意备份与合规要求）；第三步，若分区数由“按天”导致，考虑改为“按周/按月”，把 N 降低一个数量级；第四步，若业务确实需要细粒度分区，考虑拆成多张表（如按年分表 + 表内按月分区），把单表分区数控制在黄区。

笔者认为，第四步的“分表 + 分区”组合是大型日志场景的常见折中：分表把元数据规模控制在可管理范围，分区保留单表内的数据生命周期管理能力。代价是应用层需要路由逻辑，收益是 DDL 与元数据成本可控。

7.3 对“22 年”推算的再审视

回到开头的争议：8192 分区按天确实能“表达”22 年的数据，但工程上几乎不会有人真的让单表累积 22 年分区而不做任何清理或重建。真实场景中，分区表的价值在于“滚动窗口”——保留最近 N 天，删除最旧分区。此时分区数由“保留窗口长度”决定，而非“系统运行年限”。把 8192 当作“可用年限”的推算，忽略了分区表的本质用法。

本文评述：正确的容量规划口径应是“保留窗口内需要多少个分区”，而不是“上限除以每天分区数”。若保留 90 天，按天分区只需 90 个分区，远在绿区；若保留 3 年，按天分区约 1095 个，进入黄区偏红，此时应考虑按月分区（36 个）或分表。这个视角的转换，比争论 1000 还是 8192 更有实际意义。

八、替代方案对比与前沿预判

8.1 分区 vs 分表 vs 冷热分离

分区不是唯一的数据生命周期管理手段。分表（应用层或中间件）把元数据压力分散到多张表，单表分区数可控；冷热分离把历史数据迁移到归档库或对象存储，主表保持小规模。三者的取舍取决于查询模式：若查询天然带时间范围且需要跨历史聚合，分区更优；若查询主要命中近期数据，冷热分离更彻底；若需要水平扩展写入，分表更合适。

官方文档与社区实践均指出，分区表的优势场景是“时间序列 + 范围查询 + 定期清理”，劣势场景是“唯一索引跨分区”“频繁全表扫描”“复杂 JOIN”。本文评述：选型时应先确认查询模式，再决定是否分区，而不是先分区再适配查询。

8.2 前沿方向：更轻的元数据与更智能的裁剪

从 MySQL 8.0 的演进看，数据字典事务化、原子 DDL、以及 INSTANT ADD COLUMN 等特性都在降低 DDL 的元数据成本。分区方向的前沿包括：更细粒度的统计信息、裁剪规则的增强（如对表达式分区的支持）、以及云原生数据库中“分区即对象存储前缀”的架构。后者把分区元数据从数据库内核转移到对象存储的命名空间，理论上可支持更大分区数，但引入了新的延迟与一致性问题。

笔者认为，短期内 MySQL 社区版不会大幅提高 8192 上限，因为瓶颈不在“能否表达”，而在“运维成本”。真正值得关注的是元数据操作的并行化与增量统计，这两项若落地，红区阈值可能上移。但在那之前，1000 量级的经验阈值仍有现实指导意义。

九、结论与展望

“1000 以内”与“8192 上限”并不矛盾，它们分别描述工程舒适区与结构容量上限。分区过多的真实成本沿文件层、字典层、DDL 层、优化器层四条链路传导，其中字典层与 DDL 层的锁持有时间是并发场景下最需要警惕的部分。工程上应以“保留窗口内的分区数”为规划口径，以“裁剪命中率”为核心监控指标，以三区间模型指导阈值设定。

展望未来，元数据操作的增量化和并行化是降低分区成本的关键方向；在此之前，合理的做法是把分区数控制在黄区以内，对红区表制定明确的治理路径。分区是工具，不是目标——先想清楚查询模式与生命周期，再决定分不分、分多少。