mysql之死锁_MySQL

其实，看到“死锁”二字，不需要王二，就是我，来再废口舌，这两个字名如其意，已经可以透过现象看本质了。不过呢，我虽然长着一副程序猿的样子，但一直没有理解好mysql的死锁概念，为此还曾苦恼过，觉得自己有愧于程序猿的脸面。有幸第N次拜读《高性能mysql》，恍惚间觉得自己明白了一些，也就是有点对得起程序猿这三个字了。

死锁是指两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。

看看人家说得多好，可我王二愣是不能够发自于肺腑的理解，在这条路上走了很多弯路。

列个场景

回到洛阳后，我一直做的是大宗期货交易项目，既然是交易，肯定涉及到数据的多并发，大宗期货交易的模式很复杂，说实话，我维护了整个项目的正常运作，但对于“买涨”、“买跌”都有可能赚钱的路数，还是不清楚，只能怪自己太迟钝。所以只好举个简单的例子了。

我有两个好朋友，一个叫王一，一个叫王三，一个芳龄十八（本来想年方二八呢，一想这年龄好像未成年，觉得不合适），一个芳龄29，一个如花似玉，一个风韵犹存。王二，也就是我，作为一个屌丝男，能够交到这两个异性朋友，真是托了程序员的福。

那天王一很苦恼，她不知道怎么把win7操作系统升级到win10，小青年都挺喜欢接受新东西，于是找到了我，丢给我一句：“猿兄，帮我忙呗，升级个操作系统！”“当然好啊，大哥我巴不得啊”，我心里这样想，但是强装淡定，于是回了句“恩，稍等，哥忙着呢。”不过最终我成功帮她升级了操作系统，这妹的，崇拜我得不行，于是就成为了朋友。 关于王三，算了，我再这么无耻的yy下去，你肯定要来打醒我了，就这样吧。

场景就是，算了，还是上sql吧，我y不下去了。

START TRANSACTION;
update girl SET age=18 where id=2;
update girl set age=29 where id=1;
COMMIT;

START TRANSACTION;
UPDATE girl set age=19 where id=1;
update girl set age=30 where id=2;
commit;

如果凑巧，两个事务都执行了第一条update语句，分别修改了王一和王三的年纪，同时也锁定了改行语句，接着，每个事务都尝试执行第二条语句时，却发现该行已被对方锁定，然后两个事务都在等待对方释放锁，同时又持有对方需要的锁，则陷入死循环。

也就是说，逝水流年，王一和王三也逃不过时光的蹉跎，然而，在我心中，也就是王二的心中，却永远都不想他们老去，于是我和时光老人就干上了架，这会发生什么呢？

等待结局

时光老人	王二
[SQL]START TRANSACTION; 受影响的行: 0 时间: 0.000s [SQL]UPDATE girl set age=19 where id=1; 受影响的行: 0 时间: 0.001s	[SQL]START TRANSACTION; 受影响的行: 0 时间: 0.000s [SQL]update girl SET age=18 where id=2; 受影响的行: 1 时间: 0.001s
[SQL]update girl set age=30 where id=2;	[SQL]update girl set age=29 where id=1; [Err] 1213 - Deadlock found when trying to get lock; try restarting transaction

innodb存储引擎，能检测到死锁的循环依赖，并立即返回一个错误。

好吧，我还是干不过时光老人！

假如这样呢

故事到这里肯定是没有结束啊，我得想想办法，避免和时光老人发生冲突，于是就这样吧！

START TRANSACTION;
UPDATE girl set age=19 where id=1;
update girl set age=30 where id=2;
commit;

START TRANSACTION;
update girl SET age=18 where id=1;
update girl set age=29 where id=2;
COMMIT;

也就是说，在实战当中，假如我们遇到类似的问题，虽然innodb为我们做了错误的检测，但是我们还是要避免死锁的。

时光老人	王二
[SQL]START TRANSACTION; 受影响的行: 0 时间: 0.037s [SQL] UPDATE girl set age=19 where id=1; 受影响的行: 0 时间: 0.001s	[SQL]START TRANSACTION; 受影响的行: 0 时间: 0.001s [SQL] update girl SET age=18 where id=1;

也就是说，在有这样的update时，尽量按照顺序来执行，避免冲突。当然了，情况不同，你如果不想这样，那就请不要相信我的鬼话，哈哈哈！

好了，好了，mysql之死锁就这样结束吧！