MySQL无MAINTENANCE权限，安全维护需显式授予PROCESS、RELOAD、SHOW DATABASES、LOCK TABLES、REPLICATION CLIENT，并禁用GRANT OPTION，绑定可信IP段，配密码过期与连接限制。
MySQL 没有内置的 MAINTENANCE 权限——这是常见误解，直接授 MAINTENANCE 会报错 ERROR 1064 (42000)。 真实场景中所谓“受限维护权限”，是指组合授予若干细粒度管理类权限，同时严格排除高危操作（如 DROP DATABASE、SHUTDOWN、CREATE USER），并绑定可信 IP 段。
MySQL 8.0+ 中哪些权限等价于“安全维护”
运维人员需执行 SHOW PROCESSLIST、查慢日志、重载配置、锁表备份等操作，但不能动业务数据或系统元数据。对应权限必须显式授予，不能靠 ALL PRIVILEGES 或过时的 SUPER：
-
PROCESS：查看当前连接与查询状态（SHOW PROCESSLIST） -
RELOAD：执行FLUSH LOGS、FLUSH PRIVILEGES、FLUSH TABLES WITH READ LOCK -
SHOW DATABASES：列出库名（否则SHOW DATABASES返回空） -
LOCK TABLES：配合备份脚本加表级读锁（mysqldump --single-transaction不需要它，但物理备份常依赖） -
REPLICATION CLIENT：查看主从状态（SHOW MASTER STATUS、SHOW SLAVE STATUS） - 禁用
GRANT OPTION：防止该账号再授权给他人
示例命令：
CREATE USER 'maint_user'@'10.0.20.%' IDENTIFIED BY 'MntP@ss2026'; GRANT PROCESS, RELOAD, SHOW DATABASES, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'maint_user'@'10.0.20.%'; FLUSH PRIVILEGES;
为什么不能用 SUPER 或 ALL PRIVILEGES ON *.*
授 SUPER 在 MySQL 8.0+ 已被标记为废弃，执行后 SHOW GRANTS 可能为空，且会导致：
-
SET GLOBAL max_connections = 200报错：Access denied; you need SYSTEM_VARIABLES_ADMIN privilege -
CHANGE MASTER TO失败，提示缺少REPLICATION_SLAVE_ADMIN - 服务重启时可能因权限校验异常而拒绝启动
而 GRANT ALL PRIVILEGES ON *.* 实际包含 DROP、CREATE USER、SHUTDOWN 等高危权限，一旦误操作或账号泄露，后果严重。
如何验证维护账号真有限制、不越权
登录后立刻测试边界行为，别只看 SHOW GRANTS 显示了什么：
- 执行
SELECT * FROM mysql.user;→ 应报错Access denied for table 'user'（没SELECT权限） - 执行
DROP DATABASE test;→ 应报错Access denied; you need DROP DATABASE privilege - 执行
CREATE USER 'test'@'localhost';→ 应报错Access denied; you need CREATE USER privilege - 但
SHOW PROCESSLIST;和FLUSH LOGS;必须成功
关键点：权限生效不是“写了就对”，而是“试了才信”。尤其注意 FLUSH PRIVILEGES; 后必须用新账号重连，否则仍沿用旧会话缓存的权限上下文。
容易被忽略的部署细节
权限本身只是半截链条，漏掉下面任一环，维护账号就会失效或失控：
- host 写成
'%'而非内网段（如'10.0.20.%'），等于把维护入口暴露在公网 - 没设密码过期策略：
ALTER USER 'maint_user'@'10.0.20.%' PASSWORD EXPIRE INTERVAL 90 DAY; - 账号被用于监控脚本但未配置
max_connections限制，突发大量连接拖垮实例 - 误删
mysql.db表中残留记录，导致权限检查跳过数据库级判断（极少见但难排查）
真正安全的维护权限，是权限组合 + IP 绑定 + 密码策略 + 连接限制四者缺一不可。少一个，就不叫“受限”。
