结论与实战策略：防范死锁的核心是统一加锁顺序、缩短事务时长、使用超时机制和乐观锁。例题详解：事务A先锁表1再表2，事务B反之，导致死锁。解决：所有事务按表ID升序加锁，如先锁ID小的表。代码示例：BEGIN; SELECT * FROM table1 WHERE id=1 FOR UPDATE; SELECT * FROM table2 WHERE id=2 FOR UPDATE; COMMIT; 实战：MySQL innodb_lock_wait_timeout=10，应用层重试逻辑。

例题详解

假设有两个事务：事务A执行 UPDATE accounts SET balance = balance - 100 WHERE account_id = 1; UPDATE accounts SET balance = balance + 100 WHERE account_id = 2; 事务B执行 UPDATE accounts SET balance = balance - 100 WHERE account_id = 2; UPDATE accounts SET balance = balance + 100 WHERE account_id = 1; 这就是经典死锁，A持有account_id=1锁等待account_id=2，B持有account_id=2等待account_id=1。

权威解析一

死锁的四个必要条件：互斥、持有并等待、不可抢占、环路等待。打破环路等待是关键策略。通过定义全局加锁顺序，例如按主键ID排序，确保所有事务以相同顺序获取资源。

实战策略二

在MySQL中使用SELECT ... FOR UPDATE时，按固定顺序锁定行：先锁定account_id小的行。例如，事务总是先处理小ID再大ID。代码：LOCK IN SHARE MODE 或 FOR UPDATE 时排序。

来源三内容

缩短事务粒度：将长事务拆分成小事务，减少锁持有时间。使用索引避免表锁。设置锁超时：SET SESSION innodb_lock_wait_timeout = 5; 应用层捕获错误1205并重试。

高级技巧四

引入版本号实现乐观并发：UPDATE table SET col=val, version=version+1 WHERE id=? AND version=?; 如果行数为0则重试，避免锁竞争。

监控与诊断五

用SHOW ENGINE INNODB STATUS 查看死锁日志，分析线程栈。工具：Percona Toolkit pt-deadlock-logger。

分布式死锁六

在Sharding环境下，使用分布式锁如ZooKeeper，或业务层两阶段提交加锁顺序。

FAQ
Q: 死锁如何检测？
A: 数据库自动检测，如InnoDB每秒检查一次，选一事务回滚。
Q: 预防死锁的最佳实践？
A: 统一锁顺序、短事务、索引优化。
Q: 死锁后怎么处理？
A: 捕获错误，重试事务，可能加随机延时。
Q: 读写锁会死锁吗？
A: 多个共享锁不冲突，但共享+排他可能。