张翮1. MySQL并行复制性能异常案例分析：当多线程比单线程慢四倍
最近在排查一个MySQL从库复制延迟的案例时，遇到了一个反直觉的现象：在特定场景下，启用并行复制（replica_parallel_workers=8）的从库，其复制速度竟然比单线程复制（replica_parallel_workers=1）慢了四倍多。这个案例涉及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写入情况。有趣的是，延迟开始出现的时间点（2025-09-01 09:30）主库写入量并不大，而在主库写入量较大的时间段（04:57-05:02）反而没有出现延迟。这个矛盾现象提示我们，延迟问题可能与特定类型的事务有关，而非简单的写入量问题。
1.2 关键发现：DELETE+INSERT操作模式
通过binlog_summary.py工具对延迟时段的四个binlog文件（binary-log.005636 ~ binary-log.005639）进行分析，发现一个显著特征：操作次数排名前两位的均为同一张表biz_schema.tbl_product_service_mapping01的DELETE与INSERT操作。具体数据如下：
code复制TABLE_NAME DML_TYPE NUMS
biz_schema.tbl_product_service_mapping01 INSERT 71271
biz_schema.tbl_product_service_mapping01 DELETE 67434
进一步分析发现，业务逻辑是通过先DELETE再INSERT的方式实现数据更新，且对于相同的唯一索引值，INSERT操作总是出现在对应的DELETE操作之后。这种操作模式在并行复制环境下埋下了隐患。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 问题复现与根因分析
2.1 实验环境搭建与测试
为了精确复现问题，我设计了一套测试方案：
- 初始化relay log环境：
sql复制CHANGE MASTER TO MASTER_HOST='dummy';
STOP SLAVE;
RESET SLAVE ALL;
- 用问题binlog替换relay log文件：
bash复制cp binary-log.005636 /data/mysql/3306/data/instance-20250903-0701-relay-bin.000001
chown mysql.mysql /data/mysql/3306/data/instance-20250903-0701-relay-bin.000001
- 启动SQL线程进行重放：
sql复制CHANGE MASTER TO RELAY_LOG_FILE='instance-20250903-0701-relay-bin.000001',
RELAY_LOG_POS=1,
MASTER_HOST='dummy';
START SLAVE SQL_THREAD;
测试结果显示，在replica_parallel_workers=8时，平均重放时间为359.06秒；而设置为单线程时，平均仅需83.07秒——多线程反而慢了四倍多。
2.2 锁等待问题深度解析
通过检查错误日志，发现重放过程中存在大量锁等待超时报错。在RC隔离级别下，这显得尤为反常，因为通常RC只会加记录锁而不会出现间隙锁。
分析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.3 RC级别下出现GAP锁的奥秘
深入分析发现，这种异常锁行为与DELETE+INSERT的操作模式密切相关：
- DELETE操作并不会立即物理删除数据，而是标记为"delete-marked"状态
- 当INSERT相同唯一键值时，MySQL会：
- 对delete-marked记录加S锁
- 对记录间隙加S,GAP锁
- 这种机制是为了确保唯一性约束，即使记录处于逻辑删除状态
通过以下实验可以验证这一行为：
sql复制-- 会话1：创建测试表
CREATE TABLE test.t1(
id BIGINT AUTO_INCREMENT PRIMARY KEY,
c1 INT,
c2 INT,
UNIQUE KEY(c1,c2)
);
-- 会话2：暂停purge线程
FLUSH TABLES test.t2 FOR EXPORT;
-- 会话1：插入后删除数据
INSERT INTO test.t1(c1,c2) VALUES(10512476,1),(10512476,2);
DELETE FROM test.t1;
-- 会话3：尝试插入
BEGIN;
INSERT INTO test.t1(c1,c2,id) VALUES(10512476,1,18158557178);
-- 查看锁信息
SELECT object_schema, object_name, index_name,
lock_type, lock_mode, lock_status, lock_data
FROM performance_schema.data_locks;
结果显示在RC级别下确实获得了S锁和S,GAP锁，这与常规认知不同。
3. 解决方案与优化建议
3.1 应用层优化方案
-
索引设计优化：
- 将唯一索引改为普通二级索引（如果不严格要求唯一性）
- 考虑使用联合主键替代自增主键+唯一索引的方案
-
业务逻辑改造：
- 用UPDATE替代DELETE+INSERT模式
- 实现逻辑删除（is_deleted标记）而非物理删除
- 批量处理代替单行操作
-
SQL优化：
- 减少单事务操作量
- 合理安排操作顺序，减少锁冲突
3.2 数据库层优化方案
-
参数调整：
sql复制SET GLOBAL replica_preserve_commit_order=OFF; -- 允许乱序提交，打破等待环 SET GLOBAL replica_parallel_type=LOGICAL_CLOCK; -- 使用基于事务的并行复制 -
监控与告警：
- 监控
performance_schema.data_lock_waits - 设置长事务告警阈值
- 监控
-
版本升级：
- 考虑升级到MySQL 8.0.41+，该版本优化了并行复制的锁机制
3.3 各方案性能对比
通过实测比较不同优化方案的效果：
| 优化方案 | 平均执行时间(秒) | 相对基准提升 |
|---|---|---|
| 基准线(唯一索引+并行8线程) | 359.06 | - |
| 单线程模式 | 83.07 | 4.32倍 |
| 普通索引+并行8线程 | 33.50 | 10.72倍 |
| 关闭提交顺序保证+并行8线程 | 21.11 | 17.01倍 |
4. 经验总结与最佳实践
4.1 关键教训
-
不要假设RC级别绝对无GAP锁：在唯一约束和删除操作共同作用下，RC也可能产生GAP锁
-
并行复制不是银弹：特定工作负载下，多线程可能比单线程更慢
-
DELETE+INSERT模式的风险：这种"先删后插"的更新方式在并发环境下极易引发锁问题
4.2 推荐的最佳实践
-
设计阶段：
- 评估是否真正需要唯一约束
- 考虑使用自增主键+普通索引的组合
-
开发阶段：
- 优先使用UPDATE语句
- 避免大事务，控制单事务操作量
-
运维阶段：
- 监控复制延迟和锁等待
- 定期检查长事务
-
调优阶段：
- 根据工作负载特点调整并行复制参数
- 考虑使用WRITESET并行复制(replica_parallel_type=WRITESET)
4.3 扩展思考
这个案例揭示了MySQL内部机制的一些有趣细节：
-
唯一性检查的实现：即使在RC级别，为保证唯一性，MySQL仍会采用严格的锁机制
-
逻辑删除的影响：delete-marked记录在purge前仍会影响并发行为
-
并行复制的复杂性：事务间的依赖关系可能导致意想不到的锁冲突
对于高频更新的业务系统，建议在开发测试阶段就模拟生产环境的并发压力，提前发现这类潜在问题。同时，DBA团队应该建立完善的监控体系，对异常的锁等待和复制延迟能够快速响应。