怎样杀死阻塞其他会话的进程？

wen IT资讯 2026-06-03 237

本文目录导读：

怎样杀死阻塞其他会话的进程？

识别阻塞进程
终止阻塞进程
极端情况：无法访问数据库时的强制终止
重要注意事项
总结操作流程

在数据库管理中,处理阻塞其他会话的进程需要谨慎操作，以避免数据损坏或系统不稳定，以下是几种常见数据库系统中终止阻塞进程的方法（以 MySQL 和 SQL Server 为例），以及通用注意事项。

识别阻塞进程

首先需要找到导致阻塞的源头进程（SID/SPID）。

MySQL (InnoDB)

-- 查看当前正在运行的线程（包括锁等待）
SHOW FULL PROCESSLIST;
-- 或查找锁等待信息（需开启performance_schema）
SELECT * FROM sys.innodb_lock_waits;

重点关注 State 列为 Locked、Waiting for table metadata lock 或长时间未响应的线程。

SQL Server

-- 查找阻塞链
SELECT session_id AS blocked_session_id,
       blocking_session_id,
       wait_type,
       wait_time,
       wait_resource
FROM sys.dm_exec_requests
WHERE blocking_session_id > 0;
-- 或查看哪些SPID正在阻塞其他SPID
EXEC sp_who2 'active';

终止阻塞进程

MySQL

使用 KILL [CONNECTION | QUERY] <thread_id> 命令：

KILL 12345;   -- 直接终止该连接（包括所有正在执行的查询）
-- 或
KILL QUERY 12345; -- 只终止当前查询，不关闭连接

注意：

需要 PROCESS 和 SUPER 权限。
终止后,该连接会被立即断开，未提交的事务会自动回滚（可能导致长时间等待的回滚操作）。

SQL Server

使用 KILL <spid> 命令：

KILL 67;  -- 或 KILL 67 WITH STATUSONLY; 查看回滚进度

注意：

需要 sysadmin 或 processadmin 角色权限。
终止后,正在执行的事务会回滚，回滚时间取决于事务大小，可使用 KILL spid WITH STATUSONLY 监控回滚进度。

极端情况：无法访问数据库时的强制终止

MySQL

# 通过操作系统直接终止进程（Linux）
kill -9 `ps aux | grep 'mysql' | grep -v grep | awk '{print $2}'`  # 危险！会停掉整个MySQL服务

严重警告：这会硬杀掉 MySQL 进程，可能导致数据损坏或重启时长时间崩溃恢复。

SQL Server

无法通过操作系统直接杀掉 SQL Server 进程来“杀死单个会话”，只能通过 T-SQL KILL 命令（或使用 SSMS 的“活动监视器”右键终止）。
若 SQL Server 服务完全卡死，可在服务管理器中重启 MSSQLSERVER 服务，但同样会导致所有未完成事务回滚。

重要注意事项

确认阻塞原因
并非所有阻塞都是“无理由”的，阻塞可能由长事务、死锁检测（SQL Server 会自动杀掉死锁中的牺牲者）、索引缺失或大查询导致，直接杀掉进程只是治标。
事务回滚时间
如果被阻塞进程正在执行大事务（如批量更新数十亿行数据），杀掉它后数据库可能需要数小时甚至更久来回滚，此时应耐心等待，或考虑在低峰期操作。
权限与责任
生产环境终止他人会话前，最好先沟通确认，避免误杀重要业务进程。
预防而非补救
- 设置合理的锁超时（MySQL innodb_lock_wait_timeout，SQL Server SET LOCK_TIMEOUT）。
- 优化慢查询,减少事务持有锁的时间。
- 使用只读副本或读写分离减轻主库压力。

总结操作流程

查找：用 SHOW PROCESSLIST 或 sys.dm_exec_requests 定位阻塞会话。
确认：检查阻塞来源是否可安全终止（如无重要事务或已超出超时）。
执行：使用 KILL <spid> 终止。
监控：观察系统是否恢复正常，若仍阻塞则重复步骤1，或考虑重启数据库服务（仅作为最后手段）。

最后警告：不推荐直接通过 kill -9 杀死数据库进程或系统级强制中断，这可能导致数据损坏、系统表损坏甚至需重做数据库恢复，优先使用数据库内置的 KILL 命令。