mysql无法通过单一参数配置解决长事务死锁，需组合调优innodb_print_all_deadlocks、innodb_rollback_on_timeout、innodb_status_output_locks三个参数，并配合应用层改造：消除外部依赖、批量操作排序、捕获重试死锁异常，同时确保sql走索引以避免全表扫描加锁。
MySQL 本身无法“配置解决”长事务死锁，只能通过组合配置 + 应用层改造来压低发生概率和影响——关键不是调哪个参数就一劳永逸，而是让长事务不长、让锁不乱、让死锁可快速恢复。
为什么 innodb_lock_wait_timeout 不能直接“解决”长事务死锁
这个参数只控制「等待锁超时」，不是「事务超时」。设成 5 秒，只是让一个被阻塞的 UPDATE 卡住 5 秒后报错 Lock wait timeout exceeded，但它不会中断正在执行的长事务本身。而死锁是 MySQL 自动检测并回滚（报错 Deadlock found when trying to get lock），跟这个超时无关。盲目调小它，反而会让正常业务因短暂锁争用就被中断，掩盖真实问题。
- 它对已持有的锁无效：长事务 A 持有锁 30 秒，B 等它，
innodb_lock_wait_timeout只影响 B 的等待时长，不影响 A 继续持有 - 死锁检测是独立机制：
innodb_deadlock_detect=ON（默认）才触发自动回滚，和等待超时无关 - 调太小（如 1 秒）会导致高频误报，尤其在批量导入或报表场景下
真正该配的三个 InnoDB 参数
这些参数不“消灭”死锁，但能暴露问题、限制影响、辅助定位：
-
innodb_print_all_deadlocks = 1：写入错误日志所有死锁详情，不是只记最近一次。必须开，否则线上出问题你根本看不到完整上下文 -
innodb_rollback_on_timeout = OFF（默认）：确保锁等待超时只中断当前语句，不回滚整个事务——避免把部分成功状态也丢掉 -
innodb_status_output_locks = ON（MySQL 8.0+）：让SHOW ENGINE INNODB STATUS输出中包含当前锁信息，方便实时抓取锁等待链
注意：innodb_lock_wait_timeout 可按业务容忍度设为 10–30 秒（非默认 50），但仅作为兜底，不能替代事务优化。
应用层必须同步做的三件事
配置只是辅助，死锁根子在代码。以下动作缺一不可：
- 事务内禁止任何外部依赖：删掉事务里调 HTTP、发消息、读文件、sleep 等操作。扣库存后立刻 COMMIT，支付结果回调再单独处理
- 批量更新强制排序：
UPDATE t SET status=1 WHERE id IN (100, 50, 200)改成先ORDER BY id再执行，或应用层排序后拼 SQL，保证所有事务加锁顺序一致 - 捕获并重试死锁异常：应用层 catch 错误码
1213，最多重试 2 次，每次加rand(100, 500)ms延迟，防重试风暴
索引缺失才是长事务死锁的隐形推手
没有索引的 WHERE 条件，会让 UPDATE/DELETE 变成全表扫描，锁住成千上万行——这比事务长更致命。比如 UPDATE user SET state=1 WHERE phone='138...' AND deleted=0，若 phone 无索引，InnoDB 就得扫全表，和其他事务的任意更新极易交叉锁住。
- 用
EXPLAIN检查所有事务内 SQL 是否走了索引，特别关注 type=ALL 或 rows 很大 - 复合查询条件，优先建联合索引，而非单列索引；
deleted这类低基数字段别单独建索引 - RR 隔离级下，范围查询（
id > 100）会触发间隙锁，若业务允许，改用READ COMMITTED可彻底禁用间隙锁
最常被忽略的一点：ORM 自动生成的 SQL（如 MyBatis 动态 where）可能因参数为空导致条件缺失，意外退化为全表更新。上线前必须用真实参数跑一遍 EXPLAIN。
