MySQL主从同步本身不直接死锁，但Slave SQL Thread回放事务时，若与用户事务或并行Worker Thread并发加锁顺序不一致，会触发InnoDB死锁；需通过SHOW SLAVE STATUS、错误日志及INNODB STATUS交叉验证，并禁止从库写、补全索引、规范并行复制策略来解决。
MySQL 主从同步本身不会直接“发生死锁”，但 Slave 线程（尤其是 SQL Thread 或 MySQL 8.0+ 的 Worker Thread）在回放 relay log 时，可能因执行的事务与自身正在运行的其他事务（比如用户连接发起的 DML）或内部机制冲突，触发 InnoDB 死锁——此时报错会出现在 SHOW SLAVE STATUS 的 Seconds_Behind_Master 持续为 0 或突增、Slave_SQL_Running_State 卡在 “executing”、且错误日志出现 Deadlock found when trying to get lock。
为什么 Slave SQL Thread 会卷入死锁
主从同步不是“复制锁”，而是把主库的事务原样（或逻辑等价）在从库重放。一旦从库有并发写入（例如应用直连从库做只读+少量写）、或开启了并行复制（slave_parallel_workers > 0），就完全具备死锁四要素：
- 多个事务：SQL Thread 回放的事务 + 用户连接发起的事务（或另一个 Worker Thread 的事务）
- 持有并等待：SQL Thread 持有某行 X 锁，同时申请另一行锁；用户事务恰好反向持有后者、申请前者
- 锁兼容性冲突：典型如
UPDATE ... WHERE non_unique_index = ?触发 Next-Key Lock，范围重叠又顺序不一致 - 循环等待链形成：InnoDB 检测到后，随机选择一个事务回滚 —— 如果被回滚的是 SQL Thread 的事务，就会中断同步
特别注意：MySQL 5.7 单线程 SQL Thread 几乎不会和自己死锁，但可能和用户事务死锁；MySQL 8.0+ 并行复制下，多个 Worker Thread 之间加锁顺序若未严格按 commit_order 或 WRITESET 协调，极易相互死锁。
如何确认是 Slave 线程触发的死锁
不能只看应用日志。必须交叉验证三处信息：
- 查
SHOW SLAVE STATUS\G：重点看Slave_SQL_Running: No+Last_SQL_Error是否含Deadlock found when trying to get lock - 查从库错误日志（
mysqld.err）：搜索deadlock，定位时间点，确认回滚事务的TRANSACTIONID 是否属于 SQL Thread（通常含thread_id: N，N 是系统线程 ID，可通过SELECT * FROM performance_schema.threads WHERE TYPE='FOREGROUND'对照） - 查
SHOW ENGINE INNODB STATUS\G输出中的LATEST DETECTED DEADLOCK：确认参与死锁的两个事务中，至少一个的mysql-thread-id对应 SQL Thread 或 Worker Thread（其trx_mysql_thread_id通常远小于普通连接 ID，且trx_query是来自 relay log 的 UPDATE/INSERT）
如果 Last_SQL_Error 是死锁，但 SHOW ENGINE INNODB STATUS 里没看到对应记录，说明死锁已过去、日志被覆盖 —— 此时需立即开启 innodb_print_all_deadlocks = ON 持久化记录。
解决 Slave 死锁的实操步骤
核心原则：不让 SQL Thread 和用户事务/其他 Worker Thread 在同一张表上“抢锁”。具体操作：
- 禁止应用直连从库执行写操作（
INSERT/UPDATE/DELETE），哪怕只是临时配置表。这是最干净的解法 - 若必须写从库，确保写操作与主库同步的表**完全隔离**（不同库、不同表名），且写操作加锁顺序固定（如 always
ORDER BY primary_key） - 检查并行复制策略：
slave_parallel_type = LOGICAL_CLOCK（推荐）或WRITESET，避免用DATABASE（易跨表锁冲突）；同时确认slave_preserve_commit_order = ON（MySQL 5.7+）保证事务提交顺序与主库一致 - 对高频同步的表，补全索引：特别是
WHERE条件字段必须有高效索引，避免全表扫描导致锁扩大（如UPDATE t SET x=1 WHERE status='pending'没索引 → 锁全表 → 高概率死锁） - 临时应急：执行
STOP SLAVE; SET GLOBAL innodb_lock_wait_timeout = 10; START SLAVE;（降低锁等待超时，让死锁更快暴露并回滚，而非卡住）
注意：innodb_deadlock_detect = ON 必须保持开启（默认就是），关掉它只会让锁等待变成无限期挂起，不是解决死锁，是掩盖问题。
容易被忽略的关键点
很多人以为“主从同步只读，不可能死锁”，但只要从库允许写、或用了并行复制、或同步语句本身带范围锁（如 DELETE FROM logs WHERE created_at < '2025-01-01'），死锁就真实存在。最隐蔽的坑是：同一个事务里混合了 UPDATE 和 INSERT ... SELECT，后者可能隐式扫描整张表并加间隙锁，而 SQL Thread 正在更新其中某几行 —— 这种组合在 SHOW ENGINE INNODB STATUS 里锁信息分散，极难一眼识别。
