暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

MySQL数据库因锁等待导致业务阻塞故障问题

IT那活儿 2025-12-25
70
点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享,不管IT什么活儿,干就完了!!!  


问题描述

业务侧反馈有的网页在提交时出现超时问题,失败后提示系统超时。反馈到数据库侧后,登录数据库主机查看后台CPU及内存占用都正常,但业务确实存在超时问题。


问题分析

数据库可以正常登录,业务说提交界面还是一直超时,如果是数据库的问题,那就可能是连接数到达上限,或者有线程被锁了
查了连接数正常,再查是否存在元数据锁线程结果显示确实存在元数据,使用“show processlist”命令可以看到大量State为Waiting for table metadata lock的线程,和业务说的情况对上了。
检查出现元数据锁的线程,发现这些会话都在等待一条SQL的执行,执行的SQL是一条ALTER TABLE语句,这个表比较大,更改表结构会很慢,开发人员直接在业务高峰期给这张表加字段,导致业务人员的UPDATE操作和开发人员的ALTER TABLE操作出现了读写锁冲突,所有的读请求都卡在了写操作后面,才导致出现了大量的超时现象


处理方法

因为那条ALTER TABLE 语句是给表新增字段,和现在的UPADATE操作不冲突,所以可以直接把那个一直在执行的ALTER TABLE线程kill掉。
结束掉堵塞的ALTER TABLE线程后,其他线程状态都变成了Executing,说明已经恢复正常,业务反馈那边可以提交成功了
总结建议:
复盘时才知道这个表之前不常用,只是刚好在当天需要频繁读写。所以以后再有类似于对业务表进行表结构更改或者添加索引这种操作,禁止在高峰期进行。
有这方面的需求需要提前发公告,确保通知到位如非必要,一律在凌晨时业务低谷期对表进行操作。

END


本文作者:(上海新炬中北团队)

本文来源:“IT那活儿”公众号

文章转载自IT那活儿,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论