下面是对于一个MySQL死锁场景实例的分析攻略。
MySQL中的死锁是指两个或多个事务互相占用对方所需要的资源，导致彼此等待释放资源而无法继续执行下去的现象。在这种情况下，MySQL会自动检测到死锁并打断其中一个事务，此时需要对出现死锁的代码进行调整。
以下假设有两个线程A和B，同时对一个MySQL数据库进行操作，其操作语句如下：
线程A：
BEGIN;
SELECT * FROM orders WHERE id=1 FOR UPDATE;
SELECT * FROM users WHERE id=1 FOR UPDATE;
UPDATE users SET balance = balance - 100 WHERE id = 1;
UPDATE orders SET amount_paid = 1 WHERE id = 1;
COMMIT;
线程B：
BEGIN;
SELECT * FROM users WHERE id=1 FOR UPDATE;
UPDATE users SET balance = balance + 100 WHERE id = 1;
COMMIT;
这里假设线程A先开始执行，并且先通过SELECT语句对orders表上的id=1的记录进行加锁，然后通过SELECT语句对users表上的id=1的记录进行加锁。接着线程A开始执行UPDATE语句，同时将对orders表的id=1的记录进行更新，以及对users表的id=1对应记录进行更新。
假设线程B在此时准备执行SELECT语句，但由于该记录已经被线程A加锁，因此它也需要加锁进行等待。同时线程A需要对users表的id=1对应记录进行更新，但此时这条记录已经被线程B加锁，线程A同样需要等待。
这样就形成了一个死锁的局面。MySQL会检测到这种死锁现象，其检测方式是通过等待超时来实现的。
通过为表格增加合适的索引可以降低死锁的发生率。
减少事务时间，如果一个事务被锁定的时间过长，那么就容易导致其他事务在等待过程中产生死锁。
对于不要求在同一事务内完成的SQL语句，采取分离执行的方式，减少锁竞争。
监控数据库的锁、事务等使用情况，及时发现可能发生死锁的现象。
以一个简单的死锁场景为例，假定有两个线程A和B，分别对表格test中的id为1的行进行操作：
线程A：
BEGIN;
SELECT * FROM test WHERE id=1 FOR UPDATE;
UPDATE test SET name='A' WHERE id=1;
COMMIT;
线程B：
BEGIN;
SELECT * FROM test WHERE id=1 FOR UPDATE;
UPDATE test SET name='B' WHERE id=1;
COMMIT;
以上两个线程同时执行，并且操作的行都是id为1的行，因此很容易导致死锁。
为了避免死锁，可以将线程A执行UPDATE操作的顺序改为先对test表进行更新，然后才对orders表进行更新，即：
线程A：
BEGIN;
SELECT * FROM test WHERE id=1 FOR UPDATE;
UPDATE test SET name='A' WHERE id=1;
SELECT * FROM orders WHERE id=1 FOR UPDATE;
UPDATE orders SET amount_paid = 1 WHERE id = 1;
COMMIT;
这样就可以避免死锁的发生。
本文链接：http://task.lmcjl.com/news/18292.html