直接授予CONNECTION_ADMIN权限即可KILL任意线程，无需PROCESS或SUPER；必须用KILL CONNECTION/QUERY语法，配合admin_port可实现连接满时的紧急干预。
直接授予 CONNECTION_ADMIN 权限即可 KILL 任意线程
MySQL 8.0+ 中，CONNECTION_ADMIN 是替代旧版 SUPER 中 KILL 能力的唯一必要权限。它不依赖 PROCESS、不需 SUPER、也不要求用户登录为 root——只要被授权，就能执行 KILL CONNECTION 或 KILL QUERY，且作用于所有线程（包括其他用户的）。
-
GRANT CONNECTION_ADMIN ON *.* TO 'monitor_user'@'10.20.%'; FLUSH PRIVILEGES;—— 这是最小、最安全的配置，无需叠加其他权限 - 注意：该权限从 MySQL 8.0.14 开始正式支持；低于此版本会报错
ERROR 3715或提示未知权限 - 验证是否生效：
SHOW GRANTS FOR 'monitor_user'@'10.20.%';，输出中必须明确含CONNECTION_ADMIN - 不要用
GRANT PROCESS ON *.*代替——它只能看到自己线程，KILL仍被拒绝
执行 KILL 时必须用 CONNECTION_ADMIN 对应的语法
授予权限只是前提，实际操作必须用 MySQL 8.0+ 推荐的显式连接标识方式，否则仍可能失败或误杀。
- 查目标线程：
SELECT id, user, host, command, time, state, info FROM performance_schema.threads WHERE type = 'FOREGROUND' AND time > 60;（推荐查performance_schema.threads，比SHOW PROCESSLIST更全、更准） - 断开连接：
KILL CONNECTION 12345;—— 必须带CONNECTION关键字，KILL 12345在严格模式下可能被拒绝 - 仅终止当前语句：
KILL QUERY 12345;—— 适用于不想断开客户端，只停掉慢查询的场景 - 不能对系统线程（如
system user、event_scheduler）执行KILL，会报ERROR 1095
为什么有时 KILL 了但线程还在？常见陷阱
权限和语法都对，线程却没立即消失，通常不是权限问题，而是状态卡在不可中断阶段。
- 线程处于
Writing to net、Sending data或Locked状态时，KILL会等待当前操作完成再退出，不是失效 - 如果线程正在执行 DDL（如
ALTER TABLE），尤其涉及大表重建，KILL可能要等数分钟才响应 - 检查是否被锁住：
SELECT * FROM performance_schema.data_locks WHERE THREAD_ID = 12345;，有记录说明正持锁等待 - 云环境要注意：某些托管服务（如阿里云 RDS、腾讯云 CDB）会拦截或延迟透传
KILL命令，需确认控制台是否提供“强制终止会话”开关
配合 admin_port 实现真正可靠的紧急干预
当 max_connections 被占满，普通端口连不上时，CONNECTION_ADMIN 权限本身也用不了——这时需要独立管理通道。
- 在
my.cnf中启用专用管理端口：[mysqld] admin_address = 127.0.0.1 admin_port = 33062
- 重启后，即使
3306拒绝新连接，只要本地能连33062，带CONNECTION_ADMIN的账号就能秒进并清理线程 - 注意：该端口默认只监听
admin_address（建议设为127.0.0.1），不对外暴露，避免安全风险 - 连接命令：
mysql -h 127.0.0.1 -P 33062 -u monitor_user -p
真正容易被忽略的是：权限、语法、状态、通道这四层必须全部对齐。少一层，KILL 就可能变成“看起来执行了，其实没效果”。
