页分裂和页合并频繁发生的根本原因是数据页填充率剧烈波动，而merge_threshold默认50%、innodb_fill_factor默认93.75%的固定阈值难以适应随机写入；uuid等非自增主键导致插入位置不可预测，极易触发中间页分裂与后续低利用率合并。
页分裂和页合并为什么会频繁发生
根本原因是数据页的填充率剧烈波动，而触发阈值固定（MERGE_THRESHOLD 默认 50%，innodb_fill_factor 默认 93.75%）。当写入模式与主键设计不匹配时，这种波动会被放大：
- 用
UUID或MD5类随机值作主键：新行插入位置完全不可预测，大概率落在中间页而非末尾，直接触发叶子节点分裂；后续删除又让该页利用率跌破 50%，再触发合并 - 大量
DELETE后不做清理：标记删除的行长期残留，页内有效数据占比下降，但空间无法被大记录复用，最终满足合并条件 - 频繁
UPDATE变长字段（如VARCHAR从 10 扩到 200）：原页放不下，强制迁移整行，既引发分裂（目标页满），又留下空洞（源页变稀疏） - 二级索引字段本身无序（如
email、created_at）：即使主键是自增，二级索引仍会因插入顺序混乱而高频分裂
如何用 SQL 直接查出正在分裂/合并的表
MySQL 不提供实时“正在分裂”的状态视图，但可通过间接指标定位高风险对象。关键看 INFORMATION_SCHEMA.INNODB_METRICS 和 SHOW ENGINE INNODB STATUS 的聚合统计：
- 查分裂累计次数：
SELECT NAME, COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME IN ('index_page_splits', 'index_page_merge_attempts') - 查当前页碎片率（需配合
DATA_FREE）：SELECT TABLE_NAME, ROUND(DATA_FREE / DATA_LENGTH, 2) AS frag_ratio FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE='InnoDB' AND DATA_LENGTH > 0 ORDER BY frag_ratio DESC LIMIT 5 - 查最近一次
SHOW ENGINE INNODB STATUS中的INSERT BUFFER AND ADAPTIVE HASH INDEX段，观察merged operations和page state是否持续变化
innodb_monitor_enable 能否捕获分裂细节
可以，但代价高，仅建议临时诊断。启用后 InnoDB 会在 error log 中记录每次分裂/合并的页号、索引名和原因：
- 开启：
SET GLOBAL innodb_monitor_enable = 'module_index'; - 日志中典型条目：
INDEX: test/t1 PRIMARY, page no 12345, split due to insert of record at slot 7 - ⚠️ 注意：
module_index会显著增加日志量和 I/O，生产环境切勿长期开启；且 MySQL 8.0.23+ 才支持细粒度模块控制 - 替代轻量方案：用
performance_schema.table_io_waits_summary_by_table查WRITE_DISK_OPS突增表，再结合业务写入特征反推
监控告警该盯住哪几个硬指标
不要等慢查询爆发才反应——页问题本质是写入链路的慢性损伤。以下三个指标组合能提前 1–2 天暴露风险：
-
innodb_buffer_pool_pages_dirty / innodb_buffer_pool_pages_total持续 > 70%：说明脏页刷盘压力大，常伴随分裂后大量页需刷新 - 每秒
Handler_write+Handler_update+Handler_delete总和突增，但Queries未同比上升：暗示底层在做大量数据迁移（分裂/合并的副作用） -
Innodb_data_writes与Innodb_data_fsyncs比值长期
这些值在 information_schema.GLOBAL_STATUS 或 Prometheus 的 mysql_global_status_* 指标中可直接获取。真正难的是把数值波动和具体表关联起来——必须搭配 TABLES 表的 DATA_FREE 和 UPDATE_TIME 做交叉比对。
