必须显式回收非管理员用户的shutdown权限，因其属高危操作；需用revoke撤销、flush privileges生效，并通过select查询mysql.user表清理残留；read_only=on不能替代权限管控，自动化加固应在初始化或容器启动时执行update语句置shutdown_priv='n'。
直接禁用非管理员用户的 Shutdown_priv
MySQL 的 SHUTDOWN 命令属于高危操作，普通用户不应拥有该权限。默认安装下，部分旧版本（如 5.7）可能对 root 或空用户开放了该权限，必须显式回收。
执行以下语句撤销指定用户的关机权限：
REVOKE SHUTDOWN ON *.* FROM 'appuser'@'192.168.1.%';
-
SHUTDOWN权限只存在于全局级别（*.*），不能按库或表粒度授权 - 若用户是通过
'appuser'@'%'连接，需对应撤销该 host；通配符%不会自动覆盖localhost，后者需单独处理 - 撤销后必须执行
FLUSH PRIVILEGES;才生效，否则权限缓存仍保留旧状态
检查并清理残留的 Shutdown_priv 权限
权限可能隐藏在 mysql.user 表中，尤其当用户通过 INSERT 直接写入或迁移脚本遗留时，SHOW GRANTS 可能不直观显示。
用这条语句查所有带关机权的账号：
SELECT Host, User, Shutdown_priv FROM mysql.user WHERE Shutdown_priv = 'Y';
- 结果中若出现非
root用户（如backup、monitor），需立即REVOKE - MySQL 8.0+ 中字段名仍是
Shutdown_priv，但底层存储已转为 roles 模型，仍需通过 user 表校验 - 注意：某些监控工具（如 Zabbix 自定义脚本）会申请
SHUTDOWN权限用于“探活”，这是误用——应改用SELECT 1或PING协议检测
为什么 read_only=ON 不能替代权限管控
设置 SET GLOBAL read_only = ON 确实会让 SHUTDOWN 失败，但这是副作用，不是安全机制。
-
read_only是运行时变量，任何有SUPER或SYSTEM_VARIABLES_ADMIN权限的用户都能随时关闭它 -
SHUTDOWN命令本身不要求写权限，只要求Shutdown_priv；即使read_only=ON，有该权限的用户仍可执行成功（MySQL 5.7+ 已修复此逻辑，但兼容性不可依赖） - 生产环境开启
read_only通常只为从库保护，主库长期启用会导致业务异常，不能作为权限替代方案
自动化巡检和启动时加固
靠人工定期 REVOKE 容易遗漏，尤其在 CI/CD 频繁创建临时账号的场景。
- 在初始化 SQL 脚本末尾加一句：
UPDATE mysql.user SET Shutdown_priv='N' WHERE User NOT IN ('root', 'mysql.sys');，再FLUSH PRIVILEGES; - 若使用容器部署（如 Docker），把权限清理命令写进 entrypoint.sh，确保每次启动都重置
- 事件调度器（
event_scheduler）虽支持CREATE EVENT ... DO SHUTDOWN，但该功能本身依赖Shutdown_priv，开启即扩大攻击面，禁止用于生产
真正起作用的是权限表里的那个 'N' 字符——它不依赖配置文件、不随连接断开而失效、不被 read_only 开关影响。只要没被 GRANT 回去，就永远无效。
