数据库连接未释放导致表被锁问题排查与处理

🚨 问题现象

  • 执行 UPDATE / DELETE / ALTER TABLE 等操作时 长时间无响应 或报错:

    复制代码
    Lock wait timeout exceeded; try restarting transaction

    或

    复制代码
    Table 'xxx' is locked
  • 应用写入/更新功能卡住,但读操作可能正常。

  • 怀疑有数据库连接未正确关闭,导致事务未提交或表级锁未释放。


🔍 问题原因分析

  • 某个应用程序(或调试脚本)开启了数据库事务但未提交或回滚;
  • 连接未被显式关闭,连接池未回收 ,导致:
    • 行锁 / 表锁持续持有;
    • 后续操作因等待锁而阻塞;
  • 常见于:
    • 开发环境手动执行 BEGIN; 后忘记 COMMIT/ROLLBACK;
    • 应用代码中异常路径未关闭连接(连接泄漏);
    • 长时间运行的查询未结束。

💡 关键点:在 InnoDB 中,未提交的事务会持有行锁;在 MyISAM 中,写操作会直接加表锁。


🛠️ 排查步骤(以 MySQL 为例)

1. 登录数据库(使用高权限账号)

复制代码
mysql -u root -p

即使连接池满,MySQL 通常仍允许一个 SUPER 用户登录。

2. 查看当前活跃连接和锁等待情况

复制代码
-- 查看所有连接
SHOW PROCESSLIST;

-- 更详细信息(推荐)
SELECT 
  id, user, host, db, command, time, state, info 
FROM information_schema.processlist 
ORDER BY time DESC;

重点关注:

  • Time:执行/空闲时长(秒)
  • State:如 Locked, Sending data, Sleep
  • Info:正在执行的 SQL(若为 NULL 且 Command=Sleep,说明是空闲连接)

3. 检查是否有未提交的事务(InnoDB)

复制代码
-- 查看 InnoDB 引擎状态(含锁信息)
SHOW ENGINE INNODB STATUS\G

在输出中查找 TRANSACTIONS 和 LOCKS WAITING 部分,可看到:

  • 哪些事务在等待锁;
  • 哪些事务持有锁;
  • 对应的连接 ID(thread ID)。

4. 定位"可疑"连接

例如,发现一条连接:

  • User: dev_user
  • Host: 192.168.1.100:54321
  • Time: 3600(已空闲1小时)
  • Info: NULL
  • Command: Sleep

→ 极可能是未关闭的调试连接,且可能持有未提交事务。


✅ 解决方法:终止无用连接

终止指定连接(释放锁)

复制代码
KILL <connection_id>;
-- 示例
KILL 12345;

⚠️ 使用 KILL(不是 KILL QUERY),确保整个连接断开,事务自动回滚,锁被释放。

批量清理(谨慎使用)

复制代码
-- 生成 kill 语句(先预览)
SELECT CONCAT('KILL ', id, ';') 
FROM information_schema.processlist 
WHERE user = 'dev_user' 
  AND command = 'Sleep' 
  AND time > 600;

复制结果,在新窗口执行。


✅ 验证是否恢复

  • 再次执行之前卡住的 SQL,确认能正常完成;
  • 检查 SHOW PROCESSLIST; 中不再有长时间空闲或锁定状态的连接。

🛡️ 预防措施

层面 措施
开发习惯 手动测试 SQL 时,避免只写 BEGIN; 而不提交;用完及时关闭客户端连接
应用代码 确保使用 try-finally 或连接池自动管理(如 HikariCP 的 close())
数据库配置 设置合理的超时: SET GLOBAL wait_timeout = 600; SET GLOBAL interactive_timeout = 600;
监控告警 监控 Threads_connected 和 Innodb_row_lock_waits 指标

💡 经验总结

  • 表锁/行锁问题往往源于"活着但无用"的连接,而非 SQL 本身性能问题;
  • SHOW PROCESSLIST + SHOW ENGINE INNODB STATUS 是排查锁问题的黄金组合;
  • KILL 连接是快速恢复业务的有效手段,但需定位准确,避免误杀;
  • 根本解决在于规范开发流程 + 健壮的连接管理。

📌 附:常用命令速查

复制代码
-- 查看连接
SHOW PROCESSLIST;

-- 查看 InnoDB 锁状态
SHOW ENGINE INNODB STATUS\G

-- 终止连接
KILL 12345;

-- 查看超时设置
SHOW VARIABLES LIKE '%timeout%';
相关推荐
李兆龙的博客12 小时前
问津集 #26:Lakebase——Postgres 的版本化页面存储、数据库分支与计算弹性
数据库
倔强的石头_14 小时前
聊聊金仓KFS:一款把数据同步软件做扎实的产品
数据库
闲云野鹤在人间14 小时前
MySQL|从理论、安装、备份到主从复制、MHA高可用详解
linux·运维·数据库·mysql·云计算
禾小西14 小时前
Redis:从两大维度和三大主线建立知识体系
数据库·redis·缓存
禾小西15 小时前
Redis 数据结构:快速的 Redis 有哪些慢操作?
数据结构·数据库·redis
数据库小学妹15 小时前
数据共享交换平台选型:交换方式对比与避坑指南
数据库·信创·数据同步·数据交换平台·政务数据共享·数据共享交换平台·数据库底座
loong_XL17 小时前
决策模型做内容安全检测:从踩坑到上线
数据库·安全·jev·决策模型
这个DBA有点耶17 小时前
数据库双轨并行实战:全量并行策略、增量延迟控制、双向回切与一致性校验
数据库·架构·dba
adinnet202618 小时前
保单、赔付与渠道问数:保险经营数据如何实现按需查询
大数据·数据库·人工智能
云贝贝贝18 小时前
PostgreSQL 分区表:从设计到运维,大表不再卡
运维·数据库·postgresql