1. 问题如图所示:
2.原因
根据日志中发现对某张表进行批量update操作时,发现如下错误,发生这种错误的原因有如下几点:
- 是这个批量update的SQL,将表或者行记录进行了加锁操作,然后执行时间较长,长时间不释放锁,导致其他事务超时。
- 该表中存在大量逻辑删除的记录,真实有用的数据占据小部分,然后进行批量更新操作时将delete=1的数据没有排除在外
- 该表中存储了base64类型的图片数据,导致单表数据占用内存较大
- 由于进行了多次的update和insert操作,导致该表碎片较多
- 对数据进行update的SQL条件没有增加索引
3. 解决
针对如上的原因,对该问题安装原因一一进行解决,解决方式如下:
- 删除deleted=1的冗余数据
- 该表不存储base64类型的图片数据,在进行列表查询或者update操作时,不对该数据进行操作
- 增加更新条件索引
进行如上三个操作后,发现查询该表依然存在性能问题,于是针对表碎片进行处理。
- 执行analyze table db_test查看表碎片大小,即data_free的大小
- 执行alter table db_test force或者opeimize table db_test语句对表碎片进行整理
在进行查询时发现性能问题不存在,由此解决性能问题。
针对原始lock的问题,使用show full processlist;
kill
掉出现问题的进程。 ps.有的时候通过processlist是看不出哪里有锁等待的,当两个事务都在commit阶段是无法体现在processlist上。