不恰当的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更新。