最近维护项目发现的一个有意思的问题，写篇文章记录一下。
项目的问题是数据库发生了死锁，在盘查的所有的业务代码后我认为是“单条”批量update语句需要锁表而引发的问题
项目是基于spring的webservice，采用mysql数据库innodb引擎，问题涉及的主要业务如下：
业务1：系统会定期盘点数据（以下称为自动盘点），盘点中一个必要的数据不是存放在本地，需要通过http请求远程服务器，所以会导致服务层的一个方法运行缓慢（大约需要5小时）
业务2：管理员可以对某些数据进行手动盘点，手动盘点也需要通过http请求远程服务器，但是由于手动盘点数据一般较少，所以手动盘点只需要执行数分钟。
我查看了一下spring的配置，发现原先开发的时候为了省事，直接采用spring自动管理事务方式，代理了service层的所有方法。我们知道update事务需要获取mysql的写锁，由于数据库引擎采用的是innodb，在有索引的情况下会使用行锁，这样只要更新完立即释放锁，理论上就可以避免死锁了。
在咨询了老员工，发现某条数据更新失败不会影响整体的数据完整性，于是我将自动盘点更改为手动事务，获取到数据之后立即写入数据库，但是还是会与手动盘点冲突，问题还是存在。我查看了一下mybatis的更新语句，发现手动盘点有一条这样的语句：
update `A` set 省略 where id in(select id from `B` where 省略)id在A表中为主键，检查发现update查询会锁住A表。
这样问题就明了了，手动盘点需要锁住整个表，但是自动判断锁住了某条记录，这样手动盘点就会因为获取锁超时而失败。
于是我想当然的把sql改成下面这样
update `A` set 省略 where id in(1,2,3,4,5....)发现在in查询中条件不多的情况下（我机器上市小于3）会锁住需要操作的行，条件多则锁表
我又改成了这样
update `A` set 省略 where id = 1 or id=2 or id=3 ......执行查询计划和in查询一样，在条件不多锁行，条件多了依旧锁表
将批量的update语句改为多条update后，问题暂时没有复现。
最后我做了一个如下实验，有兴趣的朋友可以自己做一下，环境为mysql5.6，innodb引擎
创建表语句：
CREATE TABLE `update_table` (
`id` int(11) NOT NULL,
`num` int(11) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;执行如下查询计划，结果如下：
EXPLAIN UPDATE `update_table` SET `num`='1' WHERE id =1 or id=2 or id=3;
这里重点关注下type和rows，可以发现是锁行的
接着把条件增多，执行查询计划：
EXPLAIN UPDATE `update_table` SET `num`='1' WHERE id =1 or id=2 or id=3 or id=4 or id=5;
发现type变成了index，行数等于整个表的行数，表被锁
使用in和or一样，条件少锁行，多锁表
最后我建议若业务对高并发比较敏感，使用单条多次update语句，以免将这个表锁住，就像下面这样，当然前提是where能用到索引，不然依旧会锁表
EXPLAIN UPDATE `update_table` SET `num`='1' WHERE id =1
EXPLAIN UPDATE `update_table` SET `num`='1' WHERE id =2
EXPLAIN UPDATE `update_table` SET `num`='1' WHERE id =3
....