错误。主从架构中死锁可能发生在从库，尤其在mysql 8.0+并行复制（多worker thread）且存在无主键表、锁序不一致或用户直连从库写入时，sql/worker线程与用户事务或彼此间可形成循环等待，触发innodb死锁。
主从环境里死锁只在从库不发生
MySQL 主从架构中，死锁几乎不可能在从库出现——因为从库的 SQL 线程是单线程（或按库并行）串行回放 relay log，不存在多个事务并发抢锁的条件。死锁必须依赖「至少两个并发事务相互等待」，而从库重放逻辑天然排除了这种并发性。你看到的死锁报错，100% 来自主库；从库即使卡住，也是 Waiting for table metadata lock 或 Slave_SQL_Running_State: Reading event from the relay log 这类单向阻塞，不是死锁。
主库死锁在从库无法复现的三个硬限制
主从数据同步存在三重不可逆偏差，直接导致主库能触发的死锁，在从库根本构造不出来：
- 事务提交顺序被打乱：主库上并发提交的事务，在 binlog 中按 commit 时间序写入；但从库 SQL 线程按 event 顺序回放，若主库有并行事务交叉更新同一行，从库会变成串行执行，消除了循环等待链
- 时间窗口消失：主库死锁常依赖微妙的竞态时序（如事务 A 持锁 50ms 后请求 B 的锁，事务 B 恰好在第 49ms 持锁并反向请求），从库没有这个毫秒级调度自由度
- 隔离级别实际失效：从库默认
read_only=ON，且 SQL 线程以SERIALIZABLE语义串行执行，不走 MVCC 并发路径，间隙锁、Next-Key Lock 等死锁温床机制被绕过
误以为“从库复现了死锁”的常见假象
以下现象常被当成从库死锁，实则是其他问题：
-
Deadlock found when trying to get lock; try restarting transaction报错只可能来自主库应用连接——从库客户端连的是只读实例，不会执行UPDATE/DELETE类写操作 - 从库延迟飙升 +
SHOW PROCESSLIST显示大量Waiting for table level lock：这是表级锁（如FLUSH TABLES WITH READ LOCK）或 DDL 阻塞，不是 InnoDB 行级死锁 - 监控显示 “Deadlocks/s” 指标非零：该指标来自
SHOW GLOBAL STATUS LIKE 'Innodb_deadlocks'，仅主库维护，从库该值恒为 0
真正需要盯紧的其实是主库 binlog 格式
如果你发现主库死锁频发，但切换到从库查问题时总“复现不了”，说明你正踩进一个典型误区：把从库当成了主库的镜像沙箱。实际上，binlog_format=STATEMENT 会让某些死锁在主库发生、从库直接报错中断；而 binlog_format=ROW 虽能保一致性，却掩盖了主库真实的锁竞争路径——因为从库回放的是变更后的行镜像，不是原始 SQL 的锁申请过程。最危险的是忽略这点，用从库 explain 执行计划去反推主库死锁原因。
