从库SQL Thread会卷入死锁，因其回放relay log时与用户事务或并行Worker在同表加锁顺序冲突，满足死锁四要素：多事务、持锁申请、锁不兼容、循环等待；典型信号是Seconds_Behind_Master卡住且错误日志报“Deadlock found”。
MySQL主从复制本身不产生死锁，但从库回放 relay log 时，SQL Thread 或并行 Worker Thread 与用户事务、或与其他 Worker 之间加锁顺序冲突，会真实触发 InnoDB 死锁。 这类死锁不是配置错误，而是并发模型与锁机制碰撞的结果，必须从执行路径、索引结构、复制策略三方面协同干预。
为什么从库 SQL Thread 会被卷入死锁
主从同步不是“只读复制”，而是把主库事务原样重放。只要从库允许写（哪怕只读应用误连、监控脚本、定时任务），就满足死锁四要素：
-
SHOW SLAVE STATUS中Seconds_Behind_Master突增或卡在 0，Slave_SQL_Running_State停在executing，且错误日志出现Deadlock found when trying to get lock—— 这是典型信号 - MySQL 5.7 单线程 SQL Thread 不会自己死锁，但极易和用户连接的
UPDATE冲突；MySQL 8.0+ 开启slave_parallel_workers > 0后，多个 Worker Thread 若未按COMMIT_ORDER或WRITESET协调顺序加锁，相互间死锁概率陡增 - 常见诱因：从库上执行了
UPDATE ... WHERE non_unique_index = ?，触发 Next-Key Lock；而 SQL Thread 正在回放同表另一条范围更新，两事务锁住不同间隙却反向申请对方持有的锁
如何确认死锁来自 Slave 线程而非普通业务
不能只看应用报错。必须交叉验证三处输出，缺一不可：
- 查
SHOW ENGINE INNODB STATUS\G，定位LATEST DETECTED DEADLOCK区块，检查参与事务的trx_mysql_thread_id：若其中一个远小于当前活跃连接 ID（例如12、7），且trx_query显示为UPDATE ... FROM binlog或含relay-log字样，基本可断定是 Worker 或 SQL Thread - 运行
SELECT * FROM performance_schema.replication_applier_status_by_worker\G，看哪个WORKER_ID的LAST_ERROR_MESSAGE包含Deadlock和具体表名 - 如果
Last_SQL_Error有死锁但INNODB STATUS里找不到对应记录，说明死锁已过去、日志被覆盖 —— 立即执行SET GLOBAL innodb_print_all_deadlocks = ON，否则后续排查将失去关键上下文
禁止从库写 + 补全索引 + 收紧并行策略
核心原则：不让 SQL Thread / Worker 和其他事务在同张表上抢同一类锁。这不是性能优化，而是隔离刚需：
- 从库必须设为只读：
SET GLOBAL read_only = ON（注意：这不阻止 SUPER 权限用户，还需SET GLOBAL super_read_only = ON彻底封死） - 所有被回放事务高频更新的字段，必须有匹配的索引：比如主库
UPDATE t SET status='done' WHERE create_time < '2026-05-01'，从库t.create_time就必须有索引，否则全表扫描 + 大量间隙锁必然引发冲突 - MySQL 8.0+ 并行复制慎用
LOGICAL_CLOCK（默认），改用WRITESET：STOP SLAVE; SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; START SLAVE;→ 改为SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; SET GLOBAL slave_preserve_commit_order = ON;，再配合slave_parallel_workers = 4（勿盲目调高）
容易被忽略的细节：长事务与隐式锁升级
很多团队修复了索引、关掉了从库写，死锁仍偶发——问题常藏在事务边界里：
- 从库上的监控 SQL 或慢查询分析脚本，如果用了
SELECT ... FOR UPDATE或LOCK IN SHARE MODE，哪怕只查一行，也会和正在回放的INSERT形成 Gap Lock 冲突 - ORM 自动生成的语句（如 MyBatis 动态 where）若条件顺序不一致，导致同一张表两次更新走不同索引路径，锁顺序天然错乱
-
innodb_lock_wait_timeout默认 50 秒，但死锁检测是即时的；真正危险的是那些没触发死锁、却长期持有锁的事务 —— 它们会拖慢 Worker 回放速度，间接放大竞争窗口
