mysql 5.7 mts触发死锁是因为并行回放将主库串行执行的事务在从库并发执行，导致原本不会冲突的锁操作发生物理碰撞；典型原因是无主键表使writeset失效，多个worker并发更新同一行引发循环等待。
为什么MySQL 5.7 MTS会触发死锁，而不是单纯延迟
MTS本身不制造死锁，但会让原本在主库串行执行、不会撞上的锁，在从库并发回放时真实碰撞。典型场景是：两个事务更新同一张表的同一行（比如UPDATE t SET x=1 WHERE id=100），主库因组提交天然串行，但从库Worker A和Worker B拿到这两个事务后，并发尝试加行锁——一旦加锁顺序反了（A持锁等B释放，B持锁等A释放），InnoDB立刻报Deadlock found when trying to get lock。
这不是配置错了，而是MTS把主库“逻辑安全”的并发，暴露为从库“物理冲突”的现实。尤其当表没有主键或唯一键时，WRITESET失效，所有事务退化到按LOGICAL_CLOCK分组，但锁粒度仍落在同一索引页上，死锁概率陡增。
怎么确认死锁来自MTS Worker而非普通业务
只看Last_SQL_Error不够，必须交叉验证三处输出：
- 查
SHOW ENGINE INNODB STATUS\G，定位LATEST DETECTED DEADLOCK区块，重点看trx_mysql_thread_id：若值很小（如12、7），且trx_query含UPDATE或DELETE但没显式BEGIN，基本就是Worker线程 - 运行
SELECT * FROM performance_schema.replication_applier_status_by_worker\G，找LAST_ERROR_MESSAGE含Deadlock和具体表名的WORKER_ID - 如果
Last_SQL_Error有死锁但INNODB STATUS里找不到记录，说明日志被覆盖——立即执行SET GLOBAL innodb_print_all_deadlocks = ON，否则后续无法溯源
必须做的三件事：禁写 + 补索引 + 收紧并行策略
核心不是调参，是切断冲突源头：
- 从库设为真正只读：
SET GLOBAL read_only = ON，再补一句SET GLOBAL super_read_only = ON（否则SUPER权限用户仍可写） - 检查出问题的表是否有主键或非空唯一键：
SHOW CREATE TABLE dbtrade.ins_tquartzjob\G；若缺失，立刻加主键或唯一键，否则WRITESET无法生成写集，所有事务强制串行或随机并发，锁冲突不可控 - 临时降低
slave_parallel_workers值（比如从16降到2），并确保slave_parallel_type = 'LOGICAL_CLOCK'；改完必须STOP SLAVE; START SLAVE;，仅SET GLOBAL不生效
为什么开了WRITESET还是死锁，以及怎么避免
WRITESET只保证“修改不同主键值的事务可并行”，不保证“修改同一主键值的事务不冲突”。只要两个Worker同时更新id=100这行，就必然排队甚至死锁。所以：
- 大事务必须拆分：单个事务超过30秒或relay log超10MB，回放时长+锁持有时间叠加，极易卡住其他Worker
- 避免跨业务聚合更新：比如定时任务批量跑
UPDATE user SET status=1 WHERE region='CN'，应按ID范围分片执行 - 从库
innodb_lock_wait_timeout别设太小（默认50秒），否则短时等待直接中断复制；建议调到120秒以上，给锁自然释放留出窗口
最易被忽略的是：哪怕开了slave_preserve_commit_order = 1，它只保组内顺序，不防组间冲突；而真正要命的死锁，往往就发生在相邻两组事务之间。
