Mysql 数据库死锁过程分析(select for update)(mysql数据库死锁产生的原因及解决方案)

编辑：rootadmin

推荐整理分享Mysql 数据库死锁过程分析(select for update)(mysql数据库死锁产生的原因及解决方案)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:mysql数据库死锁处理方法有哪些,mysql数据库死锁处理方法有哪些,mysql数据库死锁排查,mysql数据库死锁排查,mysql数据库死锁产生的原因及解决方案,mysql数据库死锁产生的原因,mysql数据库死锁捕获什么异常,mysql数据库死锁排查,内容如对您有帮助，希望把文章链接给更多的朋友！

近期有一个业务需求，多台机器需要同时从Mysql一个表里查询数据并做后续业务逻辑，为了防止多台机器同时拿到一样的数据，每台机器需要在获取时锁住获取数据的数据段，保证多台机器不拿到相同的数据。

我们Mysql的存储引擎是innodb，支持行锁。解决同时拿数据的方法有很多，为了更加简单，不增加其他表和服务的情况下，我们考虑采用select... for update的方式，这样X锁锁住查询的数据段，表里其他数据没有锁，其他业务逻辑还是可以操作。

这样一台服务器比如select .. for update limit 0,时，其他服务器执行同样sql语句会自动等待释放锁，等待前一台服务器锁释放后，该台服务器就能查询下一个条数据。如果要求更智能，oracle支持for update skip locked跳过锁区域，这样能不等待马上查询没有被锁住的下一个条记录。

下面说下mysql for update导致的死锁。

经过分析，mysql的innodb存储引擎实务锁虽然是锁行，但它内部是锁索引的，根据where条件和select的值是否只有主键或非主键索引来判断怎么锁，比如只有主键，则锁主键索引，如果只有非主键，则锁非主键索引，如果主键非主键都有，则内部会按照顺序锁。但同样的select .. for update语句怎么就死锁了呢？同样的sql语句查询条件和结果顺序都一致，按理不会导致一个锁了主键索引，等待锁非主键索引，另外一个锁了非主键索引，等待主键索引导致的死锁。

最后经过分析，我们项目里发现是for update的sql语句，和另外一个update非select数据的sql语句导致的死锁。

比如有条数据，select .. for update查询第-条数据，update在更新1-条数据，按照innodb存储引擎的行锁原理，应该不会导致不同行的锁导致的互相等待。开始以为是行锁在数据量较大情况下，会锁数据块。导致一个段的数据被锁住，但经过大量数据测试，发现感觉把整个表都锁住了，但实际不是。

下面举几个例子说明：

数据从id =的数据开始，IsSuccess和GetTime字段都为0，现在如果数据的IsSuccess为1了。执行下面两条sql.

　　第一条sql语句先不commit，则第二条sql语句将只能等待，因此第二条sql语句把IsSuccess修改为0，IsSuccess非主键索引锁了值为0的索引数据，第二条sql语句将无法把数据更新到被锁的行里。

再执行下面的sql语句

　　这样第二条sql语句将可以执行。因为IsSuccess=2的索引段没有被锁。

上面的例子知道了锁索引段后还比较容易看懂，下面就奇葩一点：

先把id =数据的GetTime修改为1，IsSuccess=0，然后一次执行sql：

第1个sql先不commit，按照道理只会锁这行记录，第二个sql执行，按照道理只能查询从记录的条记录，但第二个sql语句会阻塞等待。

原因是第一个sql语句还没有commit也没有rollback，因此它先锁主键索引，再锁IsSuccess的非主键索引，第二个sql语句由于where里要判断IsSuccess字段的值，由于这条数据以前的IsSuccess是0，现在更新为1还不确定，可能会回滚，因此sql2需要等待确定这条数据的IsSuccess是否被修改。sql2的sql语句因为判断了GetTime<1，实际这条记录已经不满足了，但按照锁索引的原理，所以sql2语句会被阻塞。