如何在MySQL 8.0中授予用户KILL他人慢查询连接的权限-mysql教程-PHP中文网

mysql 8.0中kill其他用户连接无需super权限，应单独授予connection_admin（全局层级on .）并搭配process权限以查看线程；授后需重连生效，且必须确保current_user()与授权host完全匹配。

如何在mysql 8.0中授予用户kill他人慢查询连接的权限

直接给用户授予 KILL 权限，别碰 SUPER

MySQL 8.0 中，KILL 其他用户的连接（比如慢查询线程）不再需要 SUPER 权限——那是高危权限，会连带开放修改全局变量、停主从、刷日志等能力。正确做法是单独授予 CONNECTION_ADMIN 动态权限，它专管连接生命周期控制。

常见错误现象：执行 KILL 12345 报错 ERROR 1227 (42000): Access denied，但用户明明有 ALL PRIVILEGES——因为 ALL 不包含 CONNECTION_ADMIN，它属于新增的动态权限范畴。

CONNECTION_ADMIN 必须在全局层级授予：GRANT CONNECTION_ADMIN ON *.* TO 'devops'@'10.20.%'
不能写成 ON app_db.* 或 ON *.app_table，否则报 ERROR 1064 (42000)
授完需重连生效，FLUSH PRIVILEGES 不影响动态权限
若用户还需查看线程列表（如 SHOW PROCESSLIST），得额外加 PROCESS 权限：GRANT PROCESS ON *.* TO 'devops'@'10.20.%'

为什么只授 CONNECTION_ADMIN 还可能 KILL 失败？

即使 CONNECTION_ADMIN 已授予，KILL 仍可能静默失败或报错，原因常被忽略：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

目标线程所属用户必须与当前用户在同一 host 段匹配。例如，你用 'devops'@'10.20.%' 登录，但被 KILL 的线程来自 'app_user'@'192.168.5.%'，这没问题；但如果被 KILL 的是 'app_user'@'localhost'，而你没授 'devops'@'localhost'，就可能因 host 不匹配被拒绝
KILL 不支持跨认证插件类型操作。若被 KILL 的连接用的是 caching_sha2_password，而你的账号是 mysql_native_password，一般不影响；但若服务端启用了 require_secure_transport=ON，且目标连接走的是非加密通道，KILL 可能被拦截
某些中间件（如 ProxySQL、MaxScale）会拦截或重写 KILL 请求，需确认是否绕过代理直连 MySQL 实例

如何验证用户真能 KILL 而不是“看起来能”？

别只看 SHOW GRANTS 输出，要实测。最可靠方式是开两个会话：

会话 A（用被授权账号）：SELECT CONNECTION_ID(); 记下 ID，再执行一个长休眠：SELECT SLEEP(300);
会话 B（用待测账号）：SHOW PROCESSLIST; 找到 A 的线程 ID，执行 KILL [id];
立刻切回会话 A：如果返回 ERROR 2013 (HY000): Lost connection to MySQL server during query 或类似中断提示，说明成功；如果 A 仍在等待，说明 KILL 未生效
检查 performance_schema.threads 表中对应线程的 PROCESSLIST_STATE 是否变为 Idle 或消失，比 SHOW PROCESSLIST 更准

生产环境必须关掉的“便利陷阱”

为快速上线，有人会顺手加 WITH GRANT OPTION 或授 SYSTEM_VARIABLES_ADMIN，这很危险：

CONNECTION_ADMIN + SYSTEM_VARIABLES_ADMIN 组合 = 可改 wait_timeout、max_connections，间接导致连接池雪崩
别把 CONNECTION_ADMIN 给应用账号（如 'app'@'%'），它应只属于运维/DBA 类账号；业务侧如需自助终止查询，应走封装好的 API，而非直连执行 KILL
MySQL 8.0.16+ 支持 SET PERSIST 持久化动态权限，但 CONNECTION_ADMIN 无法用该方式设置——它只能靠 GRANT 授予，且不落盘到配置文件，重启后仍有效（因为存于 mysql.role_edges 和 mysql.default_roles）

真正容易被忽略的点：权限生效依赖 current_user() 返回值与 GRANT 对象完全一致。哪怕多一个空格、大小写不同、host 用 127.0.0.1 而不是 localhost，都会导致匹配失败。先查 SELECT user(), current_user();，再比对授权语句，省去一半排查时间。