CONNECTION_ADMIN权限本身不赋予KILL能力，必须与PROCESS权限配合才能执行KILL CONNECTION或KILL QUERY；仅授CONNECTION_ADMIN会因无法查看线程而报错ERROR 1227，仅授PROCESS则只能看到自身线程且KILL仍失败。
CONNECTION_ADMIN 本身不“限制”连接管理，它只允许执行 KILL CONNECTION 和 KILL QUERY —— 想禁止某人杀线程，不能靠不给它，而要靠不给 PROCESS。
为什么只授 CONNECTION_ADMIN 还是 KILL 不了？
因为 MySQL 8.0 要求同时拥有 PROCESS（才能看见线程）和 CONNECTION_ADMIN（才能终止线程）两个权限。缺一不可：
- 只有
CONNECTION_ADMIN→ 执行KILL CONNECTION 123报错：ERROR 1227 (42501): Access denied - 只有
PROCESS→SHOW PROCESSLIST只显示自己会话，KILL仍报错 - 两者都有 → 成功 KILL 任意线程（包括其他用户发起的）
怎样真正限制某人执行 KILL？
核心思路是：撤掉 PROCESS，而非纠结 CONNECTION_ADMIN。因为 CONNECTION_ADMIN 单独存在时完全无效：
- 执行
REVOKE PROCESS ON *.* FROM 'dev'@'%'; FLUSH PRIVILEGES; - 该用户再执行
SHOW PROCESSLIST将只返回自己当前连接（ID 显示为NULL或空结果），且所有KILL命令均失败 - 无需回收
CONNECTION_ADMIN—— 它没PROCESS就是摆设 - 注意：如果之前误授过
SUPER，务必一并REVOKE SUPER，否则权限绕过
admin_port 和 CONNECTION_ADMIN 是什么关系？
完全无关。这是最常被混淆的一点：
-
admin_port（如33062）只是个独立监听端口，解决“连不上”的问题 - 即使走
admin_port登录，你面对的仍是同一套权限体系：没有CONNECTION_ADMIN+PROCESS，照样不能KILL -
admin_port登录成功 ≠ 权限提升；它只绕过max_connections限制，不绕过权限检查 - 启用
admin_port后，连接仍需满足：用户有SERVICE_CONNECTION_ADMIN或SUPER才能接入（注意不是CONNECTION_ADMIN）
容易被忽略的权限生效细节
权限变更后行为不稳定，往往不是逻辑错，而是环境没刷干净：
-
GRANT/REVOKE后建议显式执行FLUSH PRIVILEGES;，尤其在低版本或启用了 PAM 认证的实例上 - 验证权限是否生效，别只看
SHOW GRANTS输出，一定要用该账号重连后实测：SHOW PROCESSLIST;+KILL CONNECTION xxx; - 确认用户 host 匹配：授权
'monitor'@'localhost'，就不能用-h 127.0.0.1连（MySQL 视为不同 host） - MySQL 8.0 默认密码插件是
caching_sha2_password，旧客户端可能握手失败，测试时加--default-auth=mysql_native_password
真正难控的从来不是“怎么给权限”，而是“怎么确保它只在需要时有效、且撤得干净”。比如监控脚本里硬编码的账号一旦被 REVOKE PROCESS，SHOW PROCESSLIST 就静默失败，日志里只留一条空连接断开记录——这种无声失效，比报错更危险。
