MySQL并行复制性能异常与锁等待问题解析-代码聚汇网

MySQL并行复制性能异常与锁等待问题解析

Nicholas Qin

1. MySQL并行复制性能异常问题深度解析

最近在排查一个MySQL从库复制延迟问题时，发现了一个反直觉的现象：在特定场景下，启用并行复制（replica_parallel_workers=8）反而比单线程复制（replica_parallel_workers=1）慢了4倍多。这个案例发生在MySQL 8.0.40版本，事务隔离级别为Read Committed（RC），启用了WRITESET并行复制机制。

1.1 问题现象与初步分析

从库出现持续增加的复制延迟，通过show slave status\G观察到Relay_Master_Log_File和Exec_Master_Log_Pos都在缓慢变化。使用mysql-binlog-time-extractor工具分析binlog后发现一个矛盾现象：主库写入量大的时段（04:57-05:02）没有延迟，而写入量较小的时段（09:30左右）却出现了延迟。

错误日志中出现了大量锁等待超时报错，这在RC隔离级别下显得尤为反常。因为RC级别通常只加记录锁，理论上不应该出现如此频繁的锁等待。通过binlog_summary.py分析延迟时段的binlog文件（binary-log.005636 ~ binary-log.005639），发现操作模式高度一致：对同一张表biz_schema.tbl_product_service_mapping01的DELETE和INSERT操作占据了绝大多数。

1.2 问题复现与测试验证

为了精确复现问题，我设计了一套测试方案：

搭建测试环境，使用相同的表结构和数据
将问题binlog文件作为relay log进行重放
设置replicate-do-table只重放问题表
分别测试并行复制和单线程复制的性能

测试结果令人惊讶：

并行复制（8线程）平均耗时359.06秒
单线程复制平均仅83.07秒

错误日志显示并行复制过程中出现了大量锁等待超时错误，而单线程复制则没有这个问题。这显然与我们对并行复制的性能预期相悖。

2. 锁等待问题的深入分析

2.1 锁等待的成因探究

通过sys.innodb_lock_waits和performance_schema.data_locks视图，我们观察到了一个典型的锁等待环路：

PID 10的INSERT操作被PID 14持有的S,GAP锁阻塞
PID 14的INSERT操作又被PID 12持有的S,GAP锁阻塞
PID 12因replica_preserve_commit_order=ON的设置，必须等待PID 10提交

这种循环等待最终导致事务超时重试，严重拖慢了复制速度。

2.2 RC级别下为何会出现GAP锁

在Read Committed隔离级别下出现GAP锁，这与业务采用DELETE+INSERT的更新方式密切相关。MySQL的DELETE操作只是标记记录为删除（delete-marked），实际清理由purge线程异步完成。当INSERT操作遇到被标记删除但尚未清理的相同唯一键记录时，会触发以下加锁行为：

对已删除记录的唯一索引项加S锁
对该索引项的间隙加S,GAP锁
新插入的记录会继承下一条记录的GAP锁

这种机制确保了在并发插入时的唯一性约束，但也导致了意外的锁冲突。

2.3 并行复制与锁等待的关联

WRITESET并行复制机制原本会根据事务修改的主键或唯一索引来判断是否可并行执行。但在DELETE+INSERT模式下：

并行工作线程同时处理不同c1值的INSERT操作
这些INSERT操作需要相同的GAP锁
由于replica_preserve_commit_order的限制，形成了循环等待

单线程复制由于没有并行冲突，反而避免了这种锁竞争。

3. 问题解决方案与优化建议

3.1 应用层优化方案

索引设计优化：
- 将唯一索引改为普通二级索引（如果业务允许）
- 考虑使用联合主键替代自增主键+唯一索引的方案
更新逻辑重构：
- 用UPDATE替代DELETE+INSERT模式
- 如果必须使用DELETE+INSERT，考虑批量处理减少事务数

数据模型调整：

sql复制-- 原表结构
CREATE TABLE tbl_product_service_mapping01 (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  c1 INT,
  c2 INT,
  UNIQUE KEY(c1, c2)
);

-- 优化后的表结构方案一（去掉唯一约束）
CREATE TABLE tbl_product_service_mapping01 (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  c1 INT,
  c2 INT,
  KEY(c1, c2)
);

-- 优化后的表结构方案二（使用联合主键）
CREATE TABLE tbl_product_service_mapping01 (
  c1 INT,
  c2 INT,
  PRIMARY KEY(c1, c2)
);

3.2 数据库层优化方案

参数调整：
- 设置replica_preserve_commit_order=OFF（非Group Replication环境）
- 适当增加innodb_lock_wait_timeout（需权衡超时与响应速度）
并行复制策略：
- 对于特定表可以设置replicate-do-table限制并行范围
- 考虑使用基于事务的并行复制而非WRITESET

监控与告警：

sql复制-- 锁等待监控查询
SELECT * FROM sys.innodb_lock_waits;

-- 工作线程状态监控
SELECT THREAD_ID, EVENT_NAME, WORKER_ID, 
       APPLY_TRANSACTION_RETRIES 
FROM performance_schema.events_transactions_current
WHERE STATE = 'ACTIVE';

3.3 各优化方案效果对比

我们测试了不同优化方案下的性能表现：

优化方案	平均执行时间(秒)	锁等待次数	适用场景
原方案（8线程）	359.06	高频	不推荐
单线程复制	83.07	无	临时解决方案
普通索引+8线程	33.50	少量	可接受唯一约束放宽
关闭提交顺序保证	21.11	无	非Group Replication环境
改用UPDATE语句	18.75	无	需应用改造

4. 经验总结与最佳实践

4.1 关键发现

在DELETE+INSERT模式下，即使RC级别也可能产生GAP锁
并行复制的性能优势在某些场景下会转化为锁竞争劣势
replica_preserve_commit_order可能加剧锁等待问题

4.2 操作建议

设计阶段：
- 评估真正需要唯一约束的场景
- 避免滥用DELETE+INSERT的更新模式

开发阶段：

java复制// 不好的实践：先删除后插入
public void updateRecord(Connection conn, Record record) {
  try {
    conn.setAutoCommit(false);
    delete(conn, record.getId());
    insert(conn, record);
    conn.commit();
  } catch (SQLException e) {
    conn.rollback();
  }
}

// 好的实践：直接更新
public void updateRecord(Connection conn, Record record) {
  try {
    update(conn, record);
  } catch (SQLException e) {
    // 处理异常
  }
}

运维阶段：

对高频操作表进行定期锁分析

bash复制# 监控锁等待的脚本示例
watch -n 5 "mysql -e 'SELECT * FROM sys.innodb_lock_waits\G'"

建立并行复制性能基线，关注异常波动

4.3 深度优化技巧

purge线程调优：

适当增加innodb_purge_threads
监控purge lag情况

sql复制SHOW ENGINE INNODB STATUS\G
-- 查看"History list length"值

批量处理优化：
- 将多个DELETE+INSERT合并为事务
- 使用LOAD DATA替代大批量INSERT
版本升级考量：
- MySQL 8.0对并行复制有持续改进
- 测试新版本的WRITESET实现是否有优化

这个案例揭示了MySQL并行复制机制与特定业务模式交互产生的意外性能陷阱。通过深入分析锁机制和复制原理，我们不仅解决了当前问题，更为类似场景提供了系统的优化思路。在实际应用中，需要根据业务特点和数据一致性要求，选择最适合的优化组合方案。