读写锁不直接触发页分裂或合并，但显著影响其执行时机与并发表现：s锁不阻塞分裂但可能延迟x-latch获取，x锁加剧热页争用，长事务s锁抑制页合并，真正瓶颈在于事务生命周期与索引设计。
读写锁本身不直接触发页分裂或页合并，但会显著影响这些操作的执行时机、并发表现和锁争用强度。
Shared Lock 为什么不会阻塞页分裂/合并
页分裂和页合并是 InnoDB 内部维护 B+ 树结构的物理操作，发生在 buf_pool 中对数据页的修改阶段。Shared Lock（S 锁）只保护逻辑一致性（如 SELECT），不阻止页级物理结构调整。即使一个事务持有了某行的 S 锁，InnoDB 仍可在后台执行页分裂——只要不修改该行所在页的同一记录或不破坏其可见性规则。
但要注意：SELECT ... LOCK IN SHARE MODE 或 SELECT ... FOR UPDATE 会升级为意向锁（IS / IX），而页分裂时需获取页级别的 x-latch（独占闩锁）。此时若页上存在活跃的 S 锁（尤其是大量未释放的 S 锁），可能延迟 x-latch 获取，间接拖慢分裂流程。
- 页分裂本身不检查行级 S 锁，但需等待页上所有 latch 被释放才能开始
- 高并发只读事务若长期持有 S 锁（如长事务未提交），会延长页 latch 等待窗口
- InnoDB 的页分裂不是“原子事务操作”，它不参与 MVCC 版本链管理，只作用于当前页的物理布局
Exclusive Lock 如何加剧页分裂时的锁争用
当多个事务同时尝试插入或更新同一索引页（尤其二级索引）时，它们各自持有的 X 锁会竞争页的 x-latch。页分裂过程中必须独占该页，因此任何正在等待 X 锁的事务都会被阻塞，直到分裂完成并释放 latch。
典型现象是：SHOW ENGINE INNODB STATUS 中出现大量 wait for x-latch on page，且 ROW OPERATIONS 区域显示 split 相关等待。
- 随机主键（如 UUID）或非顺序二级索引字段更新，极易导致多个 X 锁争抢同一热页
- 页分裂期间，父节点也要加
x-latch更新指针，形成“向上传播”的锁等待链 - 如果分裂触发了根节点分裂（
root split），整个索引树顶层将短暂不可写，X 锁请求全部排队
页合并为何更怕 Shared Lock 长期占用
页合并的触发条件是页利用率低于 innodb_merge_threshold（默认 50%），但它不是立即执行的后台任务，而是由 purge 线程或主循环在空闲时扫描判断。一旦决定合并，InnoDB 必须同时持有两个相邻页的 x-latch，并将其中一页的数据迁移过去。
问题在于：如果其中一个页上有未提交事务持有的 S 锁（哪怕只是 SELECT），该页的 page_get_latched 可能失败，导致合并跳过这对页。这不是死锁，而是“合并被跳过”，碎片持续存在。
- 合并失败不会报错，也不会重试，仅记录到
INFORMATION_SCHEMA.INNODB_METRICS的index_page_merge_attempts和index_page_merge_successful - 长时间运行的只读事务（例如报表查询）会让页“看起来”始终有活跃访问，抑制合并
- 使用
READ COMMITTED隔离级别比REPEATABLE READ更利于页合并，因为 S 锁释放更早
实际排查时该看哪些指标
不要只盯着 SHOW PROCESSLIST，页分裂/合并的锁瓶颈往往藏在底层 latch 层。重点关注：
-
innodb_buffer_pool_pages_misc值是否异常升高（说明大量页被用于锁/压缩等非数据用途） -
innodb_mutex_os_wait_times中dict_sys_mutex或btr_search_latch的等待时间突增 -
SHOW ENGINE INNODB STATUS的LATEST DETECTED DEADLOCK区域虽少出现，但若出现，大概率是页分裂 + X 锁 + 多表更新交织所致 - 监控
INFORMATION_SCHEMA.INNODB_METRICS表中index_page_splits和index_page_merges的比率；若 splits 远高于 merges，说明写入模式严重碎片化，且合并机制被抑制
页分裂和合并真正难调的点不在 SQL 写法，而在事务生命周期管理与索引键选择——锁只是放大器，不是根源。
