sql thread会被innodb判定为死锁参与者，因其在从库重放主库事务时执行真实dml，与用户事务平等竞争锁；当从库可写、缺失索引、非唯一条件更新或并行复制协调不当，易因加锁顺序不一致触发死锁四要素，导致innodb回滚其事务。
从库SQL Thread为什么会被InnoDB判定为死锁参与者
因为MySQL主从同步不是“复制锁”，而是把主库事务原样在从库重放——SQL Thread（或MySQL 8.0+的Worker Thread）执行的是一条真实DML，它和用户连接发起的事务、甚至其他Worker线程，在InnoDB层完全平等。只要满足死锁四要素（互斥、持有并等待、不可剥夺、循环等待），InnoDB就会检测并回滚其中一个，而被选中的很可能就是SQL Thread的事务。
常见触发场景：从库写入 + 索引缺失 + 非唯一条件更新
当从库被允许写入（比如只读没设死、或应用误连从库），又恰好执行了类似UPDATE t SET x=1 WHERE status = 'pending'这种无索引或非唯一条件的语句时：
- 该语句可能走全表扫描，触发大量行锁甚至升级为间隙锁（
Gap Lock） -
SQL Thread正在回放一条更新同一张表的事务，也按相同索引路径加锁 - 两者加锁顺序不一致（例如一个从左到右扫描，一个从右到左），形成循环等待链
- MySQL 8.0+启用
slave_parallel_workers > 0后，多个Worker Thread之间若未严格按WRITESET或COMMIT_ORDER协调，也会相互死锁
如何确认是SQL Thread卷入了死锁
不能只看SHOW SLAVE STATUS里Seconds_Behind_Master突增或Slave_SQL_Running_State卡在executing——必须交叉验证：
- 查错误日志：
grep -i "deadlock" /var/log/mysql/error.log，确认是否有Deadlock found when trying to get lock - 立刻执行
SHOW ENGINE INNODB STATUS\G，定位LATEST DETECTED DEADLOCK段，看其中TRANSACTION是否包含thread_id对应SQL Thread（通常trx_mysql_thread_id在information_schema.INNODB_TRX中可查） - 检查
Slave_SQL_Running_State是否变成Waiting for slave mutex或Has read all relay log但Seconds_Behind_Master不归零——这可能是回滚后重试失败卡住
真正有效的缓解动作不是调参，而是切掉干扰源
很多团队试图通过增大innodb_lock_wait_timeout或降低slave_parallel_workers来“绕过”问题，但治标不治本：
- 从库必须设为只读：
SET GLOBAL super_read_only = ON（MySQL 5.7+），且确保read_only = ON已生效；否则任何用户连接都可能成为死锁一环 - 补全缺失索引：对所有在从库被
UPDATE/DELETE的WHERE字段建索引，尤其注意status、type这类低基数列，联合索引比单列更稳妥 - 禁用从库并行复制（临时）：
SET GLOBAL slave_parallel_workers = 0，观察是否还复现；若消失，说明是Worker间锁序冲突，需检查slave_parallel_type是否为LOGICAL_CLOCK且主库binlog格式为ROW - 避免在从库执行
SELECT ... FOR UPDATE或任何显式加锁查询——哪怕只是调试也不行
最常被忽略的一点：死锁日志里显示的SQL Thread事务，往往不是它自己写的SQL，而是主库发来的；你无法修改主库逻辑，但你能彻底切断从库上一切并发写入路径——这才是让SQL Thread回归“单线程安全执行者”身份的唯一可靠方式。
