<p>REVOKE SHUTDOWN ON . 是唯一有效语法，因SHUTDOWN权限仅在全局作用域生效，其他形式均报错；需查mysql.user表Shutdown_priv字段、解绑角色继承、清理空用户权限，并KILL残留连接。</p>
REVOKE SHUTDOWN ON *.* 是唯一有效语法
SHUTDOWN 权限只能在全局作用域撤销，写成 REVOKE SHUTDOWN ON mydb.* 或 REVOKE SHUTDOWN FROM 'u'@'h' 都会报错——MySQL 严格要求必须是 *.*。这是因为关机操作影响整个实例，不绑定任何库或表。
常见错误包括：
- 漏写
ON *.*，导致语句静默失败（无报错但权限仍在） - 用通配符
%撤销时，没处理localhost实例（'u'@'%'≠'u'@'localhost'） - 对已迁移或脚本创建的用户，误以为
SHOW GRANTS能看到所有权限（实际Shutdown_priv字段可能直存于mysql.user）
必须查并 UPDATE mysql.user 表里的 Shutdown_priv 字段
REVOKE SHUTDOWN ON *.* FROM 'u'@'h' 只清理 GRANT/REVOKE 流程中的显式授权，但 MySQL 会把 Shutdown_priv 作为布尔字段直接存在 mysql.user 表里。旧版安装、复制导入或手动 INSERT 都可能导致该字段为 'Y' 却不体现在 SHOW GRANTS 中。
执行这两步确认并清理：
- 查所有带关机权的账号：
SELECT Host, User, Shutdown_priv FROM mysql.user WHERE Shutdown_priv = 'Y'; - 逐个置为
'N'：UPDATE mysql.user SET Shutdown_priv = 'N' WHERE User = 'u' AND Host = 'h'; - 必须跟
FLUSH PRIVILEGES;—— 这次不能省，因为绕过了权限系统缓存机制
别忽略角色继承和空用户隐式权限
即使用户自身没显式获得 SHUTDOWN，也可能通过角色间接拥有。比如 GRANT SHUTDOWN ON *.* TO 'ops_role'; GRANT 'ops_role' TO 'monitor'@'%';，此时只对 monitor 执行 REVOKE 没用。
检查并解绑：
- 查角色关系：
SELECT FROM_HOST, FROM_USER FROM mysql.role_edges WHERE TO_USER = 'monitor' AND TO_HOST = '%'; - 解绑角色：
REVOKE 'ops_role' FROM 'monitor'@'%'; - 空用户（
''@''）默认有information_schema的SELECT权限，虽不直接影响SHUTDOWN，但它是权限模型中常被遗忘的“底座”，建议一并回收：REVOKE SELECT ON information_schema.* FROM ''@'';
回收后仍能执行 SHUTDOWN？检查连接残留和监控误用
已建立的连接不会自动丢弃旧权限。你执行完所有命令，SHOW GRANTS FOR 'u'@'h' 看起来干净了，但应用还在用老连接发 SHUTDOWN。
必须做：
- 查活跃会话：
SELECT ID, USER, HOST, COMMAND, TIME FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER = 'u'; - 主动
KILL CONNECTION [ID];或让应用重启连接池 - 排查监控脚本（如 Zabbix 自定义 check）是否错误申请了
SHUTDOWN权限——它应该用SELECT 1或 MySQL 客户端PING协议探活
最易被跳过的点：USAGE 权限无法撤销，且所有用户默认拥有；它允许登录但不做任何事，但它会让 REVOKE ALL PRIVILEGES 看起来“没效果”，其实只是权限清空后还能连上而已。
