大约两个礼拜前有同学抛出这个图片问是怎么回事， 没有时间随即记下，有时间来处理。假期本来想懒懒，但答应人家的事情，是要做的。
实际上，上面的图是一个很经典的MYSQL的 record locks 的问题， 问题的起因应该是 testdb.a 这张表的某条记录，例如
select name from a where name = 'Jassica' for update;
在操作时，如果有其他语句在另一个session中也操作 name = 'Jassica' 这条记录，就可能会产生上面的情况。
官方的文档也是这样说的，但实际上估计有人会不大信服， 怎么能模拟出那个show engine innodb status 中出现的上述的锁信息。
下面我们就来做一做看看怎样的情况能出现上面的信息
1 请创建一个简单的表，具体有多简单，1 要有主键， 2 要有一个非主键的字段，例如varchar(30)， 然后输入一些信息，类似下面这样。
然后启动两个 sessions
1 session 1 begin;
2 session 1 update a set name = 'aaa' where name > 'PPP';
3 session 2 begin;
4 session 2 update a set name = 'PPP' where name > 'Jassica';
然后和上面同学给我的截图类似的锁的信息就有了。
这里有两个问题
1 name > 'PPP' 我们并不知道到底有几个记录被UPDATE
2 name > 'Jassica" 又有几条记录我们也不知道
问题1 有5条记录被更新, 符合name > 'PPP' 的有5条记录
问题2 > 'Jassica' 的
所以死锁信息中
的信息就是 sinomina , x_professor, x_man 四条记录。
与SESSION 2 中的要更新的 5条记录，有冲突。
以上均在MYSQL 8.019 RC 模式下。
到此出现错误的信息的原因大概是弄清了， 其实到这里我们今天的主题才刚刚开始，问题是如果在 update 语句之前事务中还有其他的udpate语句， 到底是回滚不回滚。
答案是： 不 不 不回滚
我们看一下是不是这样：
1 session 1 begin;
2 session 1 update a set name = 'aaa' where name > 'PPP';
3 session 2 begin;
4 session 2 update a set name = '111111' where name = 'PPP';
5 session 2 update a set name = 'PPP' where name > 'Jassica';
6 session 1 commit;
7 session 2 commit;
session 2 失败了， 到底 PPP 变成了 111111 吗？ 这就是今天关键，按照传统数据库来说， 当然是不能，应该全部回滚。
那你的MYSQL 这里一8.019 为例 ， 答案是什么。
答案：不出所料，如果你的失败的事务上面有其他的DML语句，一定会被执行
这就和SQL SERVER 默认的事务执行的方式一样， 如果事务错误，则上面执行的就不回 OMG， 我想着绝对和开发人员想的不大一样。
实际上MYSQL 和 SQL SERVER 一样，具体SQL SERVER 怎么做避免这个问题（请自行百度，或查找之前很久写过这样的文字）。
这里不管SQL SERVER ， MYSQL 实际上有一个参数默认是 disabled
我们需要打开， innodb_rollback_on_timeout = 1 这个参数。他的功能是，自动回滚不会发生InnoDB锁等待超时错误。并且这个参数需要关闭MYSQL 在配置文件中配置，在重启动生效。
session 2
session 1
所以，如果有开发反应数据库的数据不大对头的时候，那DB门是不是要关注这个参数是ENABLED OR DISABLED。
