<p>用户能否执行KILL取决于PROCESS权限,而非SELECT;撤销PROCESS权限即可禁止KILL操作,需执行REVOKE PROCESS ON . FROM 'username'@'host'; FLUSH PRIVILEGES; 并验证生效。</p>
不能只靠授予 SELECT 权限来阻止用户执行 KILL,因为 KILL 的权限控制和 SELECT 无关——真正起作用的是 PROCESS 和 SUPER(或 MySQL 8.0+ 的 CONNECTION_ADMIN)等系统级权限。
很多“能 KILL”的用户其实并不知道自己被悄悄授予了 PROCESS 权限。先查清楚:
SHOW GRANTS FOR 'username'@'host'; —— 看显式授权里有没有 PROCESS、SUPER、CONNECTION_ADMIN
SELECT Process_priv FROM mysql.user WHERE User='username' AND Host='host'; —— 直接查 mysql.user 表,Y 表示有 PROCESS 权限注意:即使没在 GRANTS 里看到,也可能通过角色(MySQL 8.0+)间接继承了权限,需用 SHOW ROLE GRANTS FOR 'username'@'host'; 追查。
只要用户没有 PROCESS 权限,就无法执行任何 KILL(包括 KILL QUERY 和 KILL CONNECTION),哪怕只是杀自己的会话也不行。所以核心动作只有两步:
REVOKE PROCESS ON *.* FROM 'username'@'host';FLUSH PRIVILEGES;不需要动 SUPER 或 CONNECTION_ADMIN —— 它们本身不直接控制 KILL,而是影响更广的系统操作;但如果你已授过 SUPER,也建议一并收回,避免权限膨胀。
8.0 引入了 CONNECTION_ADMIN,它替代了 SUPER 中关于连接管理的部分功能,但 CONNECTION_ADMIN 本身 不赋予 KILL 权限 —— 它只允许执行 KILL 的前提是用户同时拥有 PROCESS。所以:
CONNECTION_ADMIN + 撤销 PROCESS → 用户仍不能 KILL
SYSTEM_USER 不会导致 KILL 能力,但它允许查看/操作系统账户,属于高危权限,别乱给SHOW PROCESSLIST 但又不能 KILL,保留 PROCESS 就不行;此时只能妥协:要么禁用 SHOW PROCESSLIST(REVOKE PROCESS 后该命令只显示自己会话),要么接受“能看到就能杀”的事实用目标用户登录后直接试:
SHOW PROCESSLIST; —— 如果返回空或仅自己会话,说明 PROCESS 已撤KILL QUERY 123; —— 应报错 ERROR 1045 (28000): Access denied for user... 或 ERROR 1227 (42000): Access denied; you need (at least one of) the PROCESS privilege(s) for this operation
特别注意:MySQL 重启或 FLUSH PRIVILEGES 后权限才生效,中间有缓存延迟;另外某些客户端(如某些 GUI 工具)会自动重连并复用旧连接状态,建议用命令行 mysql -u username -p 彻底验证。