delete 会不会锁表_开发中那些事儿：为啥update会超时呢？

前一段时间,生产环境碰到一个异常,更新数据库的时候,提示锁等待超时(Lock wait timeout exceeded; try restarting transaction),超时时间是50秒,修改一条数据需要等待50秒+,我就有点纳闷了。异常如下：

第一时间没想太多，觉的是可能操作数据库太频繁了。代码中，一般的业务逻辑是，请求过来了，先数据入库，每次调用一个接口(不通的业务)就会修改一下数据库中数据的状态。最后被我优化为，所有的业务处理完毕，执行一次数据插入，接口部分加了try/catch,保证数据可以肯定会入库。我真的是太天真了，问题依然存在。

然后，就去查资料，网上有说可以把超时时间设置长一点。允许可以解决问题，但是并不能真正的解决问题，并且会影响正常的业务，比如对接接口超时，触发重试，数据就会有问题(已经出现这个问题了)。

咨询了我们的DBA，一般都是减少超时时间的，还是应该减少锁和资源的争用，说白了就是再去排查一下自己的sql。查询数据库锁超时时间如下:

其实，更新语句数据库会默认添加行级锁，可以整个业务流程(同步流程和异步流程)，操作这个表就只有一个插入数据，和两个更新语句，已经不能再优化了。

难道是表锁了？继续查询资料，查看数据库事务级别为已提交读(Read Committed)，网上说这种数据级别不会锁表，其实这种看法是错误的，误导了我很长一段时间。

在什么情况下会锁表呢?真实情况是，mysql的默认引擎是InnoDB，属于悲观锁，默认锁级别是:行锁。

加锁规则：

1、查询或者修改的where筛选条件中使用索引字段的，加的是行锁；不是使用索引字段筛选的，加的是表锁。

2、对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁(行锁)；

3、对于普通SELECT语句，InnoDB不会加任何锁。

我上面的是根据主键更新的，所以不可能锁表。经过排查，是因为同事批量更新数据库的where条件没有添加索引，造成数据表锁，然后锁锁超时。添加索引以后问题解决。

普及知识点：

一、事务的四大特性(ACID):

如果一个数据库声称支持事务的操作，那么该数据库必须要具备以下四个特性：

1、原子性(Atomicity):原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。

2、一致性(Consistency):一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。

3、隔离性(Isolation):隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。

4、持久性(Durability):持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

二、事务的隔离级别:

1、脏读:脏读是指在一个事务处理过程里读取了另一个未提交的事务中的数据。

2、不可重复读:不可重复读是指在对于数据库中的某个数据，一个事务范围内多次查询却返回了不同的数据值，这是由于在查询间隔，被另一个事务修改并提交了。

3、虚读(幻读):幻读是事务在操作过程中进行两次查询，第二次查询的结果包含了第一次查询中未出现的数据或者缺少了第一次查询中出现的数据。幻读和不可重复读都是读取了另一条已经提交的事务(这点就脏读不同)，所不同的是不可重复读查询的都是同一个数据项，而幻读针对的是一批数据整体(比如数据的个数)