MySQL主从复制本身不会引发死锁，死锁仅发生在主库单机事务并发执行时；从库SQL线程或并行worker回放relay log是串行或逻辑有序的，不产生行级锁竞争，因此从库不会发生死锁。所谓“延迟引发死锁”实为误判，真正原因是延迟暴露了主库已存在的死锁，或从库被外部写入、MDL锁、自增锁争用等干扰导致锁等待。
MySQL主从复制本身不会引发死锁——死锁只发生在主库单机事务并发执行时；从库SQL线程（或并行worker）回放relay log是串行或逻辑有序的，不产生行级锁竞争，因此从库不会发生死锁。所谓“延迟引发死锁”，其实是误判，真正的问题是：延迟暴露了主库已存在的死锁，或延迟期间从库被其他操作干扰导致锁等待，进而掩盖了真实根因。
为什么SHOW SLAVE STATUS报Deadlock found when trying to get lock？
这是最典型的误导场景。错误不是从库自己死锁，而是主库事务在提交前触发了死锁，被innodb_deadlock_detect选中回滚，但该事务的部分binlog（如部分event）已发送到从库。从库SQL线程回放时，尝试执行一个已被主库回滚的变更，可能因约束冲突、锁等待超时或缺失前置状态而失败。
- 主库死锁回滚后，
binlog里仍会记录该事务的GTID和部分event（取决于binlog_format和写入时机），从库无法感知“这个事务被跳过了” - 若主库用
STATEMENT格式，且死锁事务含不确定函数（如NOW()、RAND()），从库执行时行为不一致，更容易报错 -
Last_SQL_Error显示死锁，只是SQL线程在重试过程中碰到了锁冲突，并非它参与了死锁环
延迟期间从库Waiting for table metadata lock是怎么回事？
这不是死锁，但常被当成死锁。当从库SQL线程正准备执行一条DDL（如ALTER TABLE），而此时有另一个客户端（比如备份脚本、DBA手动FLUSH TABLES WITH READ LOCK、甚至慢查询持有MDL）占着同一张表的metadata lock，SQL线程就会卡在Waiting for table metadata lock状态——它没在等行锁，是在等表结构定义锁。
- 现象：Seconds_Behind_Master持续上涨，但
SHOW PROCESSLIST里SQL线程状态固定，CPU/IO无压力 - 验证命令：
SELECT * FROM performance_schema.metadata_locks WHERE LOCK_STATUS = 'PENDING'，看OWNER_THREAD_ID是否匹配SQL线程ID - 根本原因不是复制机制，而是从库被外部操作污染：禁止在从库运行
mysqldump不加--single-transaction，禁用所有FLUSH类命令
为什么innodb_autoinc_lock_mode=1 + 并行复制会看起来像死锁？
这属于自增锁争用，不是InnoDB行级死锁，但表现高度相似：多个applier worker同时对同一张表执行INSERT SELECT，互相卡在setting auto-inc lock和waiting for lock之间，SHOW ENGINE INNODB STATUS\G里能看到循环等待链。
- 必须满足三个条件才会触发：从库开启并行复制（
slave_parallel_workers > 0）、innodb_autoinc_lock_mode = 1、且存在INSERT SELECT或批量插入语句在从库被执行（通常是误连应用或监控脚本） - 修复不是调参，而是切断源头：
SET GLOBAL super_read_only = ON+ 把innodb_autoinc_lock_mode设为2（要求binlog_format = ROW） - 注意：
innodb_autoinc_lock_mode = 2在主库也需同步设置，否则主库生成的binlog可能不兼容从库的交错模式
真正容易被忽略的是：所有看似“从库死锁”的现象，背后都指向一个事实——从库不该承担任何写负载。哪怕是一条INSERT INTO monitor_log VALUES (...)，都可能和SQL线程抢锁、抢MDL、抢自增锁。延迟只是放大镜，照出了本不该存在的写入路径。
