mysql用户能否执行kill命令取决于process和connection_admin权限：无process权限则无法kill自身会话，无connection_admin则无法kill他人会话；super在8.0+中已不再控制kill能力。
MySQL用户能KILL谁，取决于PROCESS和CONNECTION_ADMIN权限
普通用户执行KILL命令的能力，不是由SELECT或UPDATE这类数据权限决定的，而是由两个管理类权限控制：PROCESS（查看线程）和CONNECTION_ADMIN（终止线程）。没有这两个权限，连自己的会话都杀不掉。
常见误解是“只要没给SUPER就能禁止KILL”，但MySQL 8.0+已弃用SUPER对KILL的控制，改用CONNECTION_ADMIN。如果用户仍能KILL，大概率是因为PROCESS权限没被撤销——它默认允许用户KILL自己创建的连接。
-
PROCESS权限存在时：用户可执行KILL <strong>自己的</strong> thread_id（哪怕只授予USAGE） -
CONNECTION_ADMIN权限存在时：用户可KILL任意线程（包括其他用户的） -
SUPER在8.0+中不再赋予KILL能力，仅保留部分旧兼容行为，不应依赖
彻底禁止KILL：必须显式REVOKE PROCESS权限
只删SUPER没用。真正起效的操作是明确回收PROCESS权限——这是用户能执行KILL的最小必要条件。
执行以下语句后，该用户将无法执行任何KILL命令，包括KILL CONNECTION <strong>self_id</strong>：
REVOKE PROCESS ON *.* FROM 'query'@'%';<br>FLUSH PRIVILEGES;
验证是否生效：
- 用该用户登录后执行
SHOW PROCESSLIST：只能看到自己的会话（前提是没开--skip-show-database） - 尝试
KILL <strong>self_thread_id</strong>：报错ERROR 1045 (28000): Access denied for user... - 查权限表：
SELECT Process_priv FROM mysql.user WHERE User='query' AND Host='%';返回N
MySQL 8.0+推荐方案：用CONNECTION_ADMIN精细授权
如果业务需要让某类用户（如DBA助理）能KILL他人会话，又不想给SUPER，就该用CONNECTION_ADMIN替代——它专为线程管理设计，不附带修改全局变量、停复制等危险能力。
授权示例（仅限8.0+）：
CREATE USER 'killer'@'localhost' IDENTIFIED BY 'pwd';<br>GRANT PROCESS, CONNECTION_ADMIN ON *.* TO 'killer'@'localhost';<br>FLUSH PRIVILEGES;
注意点：
-
PROCESS必须同时授予，否则SHOW PROCESSLIST都看不到线程，无法定位要KILL的目标 -
CONNECTION_ADMIN不能单独使用，它不包含PROCESS的读取能力 - 不要混用
SUPER和CONNECTION_ADMIN，后者已完全取代前者在KILL场景的功能
super_read_only模式不影响KILL命令执行
即使从库开启了super_read_only=ON，root或其他有CONNECTION_ADMIN权限的用户仍可执行KILL。因为KILL属于服务器管理操作，不改变数据，也不触发binlog写入，不在只读限制范围内。
这意味着：
-
super_read_only不能当作KILL权限的开关 - 想阻止KILL，必须回到权限系统本身，而不是靠只读模式
- 某些监控脚本误以为开启只读就能“锁死”所有变更，结果发现慢查询还在跑、KILL照常生效——根源就是没动
PROCESS权限
真正容易被忽略的是：权限回收必须FLUSH PRIVILEGES才实时生效，且PROCESS权限在mysql.user表里是独立字段（Process_priv），不像数据权限那样走db或tables_priv表链路——查漏补缺时容易漏掉这一列。
