记录一次碰到的mysql update锁全表问题

[here-leslie-lau]

记录一次碰到的mysql update锁全表问题

[here-Leslie-Lau]

简单记录一次mysql update导致锁表问题

事发情况

当天晚上生产服务一直在告警，刚刚开始只是一个数据保存接口耗时过长，紧接着整个服务接口都耗时，对外表现为整个服务不可用。

于是优先排查宽带情况，其次看代码逻辑，看错误日志（无一例外都是接口耗时过长报警）。

接着看监控发现goroutine明显增多，依然没有头绪。于是想到重启服务。

重启服务过程中，弹出一个告警日志-db连接数过多，已经超过筏值。这个时候问题才确定。

问题原因

是最初的那个数据保存接口，逻辑很简单，接口拿到请求时，insert或者update进入db内。问题在于update时未对where的条件加上索引，导致数据量大时，会锁住全表，导致整个服务不可用。

该接口上线一个多月稳定，事发晚上数据量达到某一临界点，update时锁住全表，后面该接口的请求一直在等待前面的响应。随着请求数量不断增多，从而引发雪崩效应。

定位原因后排查日志，发现错误信息：

Lock wait timeout exceeded; try restarting transaction

为什么改表被锁会影响到服务其他业务响应

一个服务内有配置数据库的连接数上限，而这个接口因为锁表了，导致把连接数占光。从而影响服务其他正常业务的响应。

同时go中每个http请求底层都会new一个goroutine出来，当大量请求访问时，也就解释了为什么goroutine数量会暴涨。

反思

1. 先从排查方向来说，当时排查带宽时思路是错误的，如果带宽有问题那么其他服务应该也是异常的，而不只是这个服务。
2. 当一个服务不可用时，应当优先考虑重启该服务或者回滚到之前版本，而不是先分析错误原因。
3. mysql的存储引擎用的是innodb，update时基于next-key lock，如果不加上索引会锁住整张表进行操作，这是个大坑。之前本人没注意过该问题
4. 一些关键的地方开发时没有及时加上短信/邮件告警及时通知开发人员，导致这么久错误才被定位到，也浪费了大量的排查时间。

该问题更优解决方案

即使加了索引，但是mysql update时也有可能会锁住全表(可以通过explain查看)。以使用 force index([index_name]) 可以告诉优化器使用哪个索引，以此避免有几率锁全表带来的隐患。

面对这种频繁更新的需求，维护索引也是有很高的代价。最适合方案应该考虑非关系型数据库来做存储(如mongodb)