Fork me on GitHub

不恰当的update语句使用主键和索引导致mysql死锁

 背景知识:

截至目前,MySQL一共向用户提供了包括DBD、HEAP、ISAM、MERGE、MyIAS、InnoDB以及Gemeni这7种Mysql表类型。其中DBD、InnoDB属于事务安全类表,而其他属于事务非安全类表。

 

DBD
    Berkeley DB(DBD)表是支持事务处理的表,由Sleepycat软件公司开发。它提供MySQL用户期待已久的功能--事务控制。事务控制在任何数据库系统中都是一个极有价值的功能,因为它们确保一组命令能成功地执行或回滚。

MyIASM

    MyIASM基于了IASM代码,应该可以说是IASM的衍生品,不过增加了不少有用的扩展。它是MySQL的默认数据表类型,基于了传统的ISAM类型,ISAM是Indexed Sequential Access Method(有索引的顺序访问方法)的缩写,一般来说,它是存储记录和文件的标准方法。与其他存储引擎比较,MyISAM具有检查和修复表格的大多数工具。ISAM表格可以被压缩,而且它们支持全文搜索,不过它们是事务不安全的,而且也不支持外键。如果事务回滚将会造成不完全回滚,从而不具备原子性。所以假如忽略事务以及访问并发性的话,并且需要执行大量的SELECT检索语句的话,MyISAM将是最好的选择。

InnoDB

    InnoDB是MySQL 4.0之后推出的一种比较新的数据表类型,这种类型是事务安全的。它与BDB类型具有相同的特性,它们还支持外键。InnoDB表格速度很快具有比BDB还丰富的特性,因此如果需要一个事务安全的存储引擎,建议使用它。如果你的数据执行大量的INSERT或UPDATE,出于性能方面的考虑,同样应该使用InnoDB表。对于支持事务的InnoDB类型的表来说,影响速度的主要原因是AUTOCOMMIT默认设置是打开的,而且程序没有显式调用BEGIN 开始事务,导致每插入一条都自动提交,严重影响了速度。可以在执行sql前调用begin,多条sql形成一个事物(即使autocommit打开也可以),将大大提高性能。

 

MySQL的数据表类型很多,其中比较重要的是MyISAM,InnoDB这两种。

 

同时,MySQL有三种锁的级别:页级、表级、行级。

MyISAM和MEMORY存储引擎采用的是表级锁(table-level locking);BDB存储引擎采用的是页面锁(page-level locking),但也支持表级锁;InnoDB存储引擎既支持行级锁(row-level locking),也支持表级锁,但默认情况下是采用行级锁。

 

MySQL这3种锁的特性可大致归纳如下:

 

表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。
行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。
页面锁:开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般。

行级锁并不是直接锁记录,而是锁索引,如果一条SQL语句用到了主键索引,mysql会锁住主键索引;如果一条语句操作了非主键索引,mysql会先锁住非主键索引,再锁定主键索引。

 

问题现象:

首先是数据库表结构如下:



 

 在执行

UPDATE ccvzb_room SET STATUS=1 WHERE begin_time<'2017-02-05 17:24:12'

 报错,报错信息为:

ERROR 1062 (23000): Duplicate entry '000e2619f0c5487880829e4165e714ff-0' for key 'PRIMARY'

 其实这条sql执行时,就产生了死锁,根据背景知识里的红色描述:如果用到了主键索引,mysql会锁定主键索引,如果用到了非主键索引,msyql会先锁定非主键索引,再锁定主键索引。如果两条sql执行间隔时间非常短的话就会出现资源争夺的情况,从而造成死锁。

解决办法:

解决办法一:

首先通过条件查询出符合条件的记录,然后根据查询出的结果的主键id再进行update操作。

UPDATE ccvzb_room a INNER JOIN ccvzb_room b ON a.room_id=b.room_id SET a.status=1 WHERE a.begin_time<'2017-02-05 17:24:12' AND a.status=0</span> 

 

 解决办法二:

UPDATE ccvzb_room SET STATUS=STATUS+1 WHERE begin_time<'2017-02-05 17:24:12' AND STATUS=0 ORDER BY STATUS

 

经验总结:

电商无论前台后台的程序,都不应该存在仅根据非主键的几个字段一查就要update/delete的场景。即使有,也应该改为先把要更新的记录查出来然后逐条按主键id更新。

posted @ 2017-02-08 01:26  阿森丶  阅读(1129)  评论(0编辑  收藏  举报