创建维护用户必须指定host，不能只写用户名；漏写会导致默认@'%'而无法连接，且@'localhost'与@'%'权限不互通，应明确限定来源并分层授权，避免all privileges和flush privileges冗余操作。
创建维护用户必须指定 host，不能只写用户名
很多人执行 CREATE USER 'dba' IDENTIFIED BY 'pwd' 就以为完事了，结果连不上——因为 MySQL 用户是 'username'@'host' 二元组，漏掉 @'host' 会被默认设为 @'%'，而很多生产环境禁用了通配符远程登录。更糟的是，@'%' 和 @'localhost' 是两个完全独立的用户，权限不互通。
日常运维用户通常只在数据库服务器本机或跳板机操作，应明确限定来源：
-
CREATE USER 'maint'@'localhost' IDENTIFIED BY 'StrongPass2026!';—— 仅本机连接，最安全 -
CREATE USER 'maint'@'192.168.5.10' IDENTIFIED BY 'StrongPass2026!';—— 指定跳板机IP，避免暴露在公网 - 绝对避免
'maint'@'%'，哪怕测试环境也建议用'maint'@'192.168.0.%'替代
授予权限时别用 ALL PRIVILEGES ON *.*
运维用户不是 root，也不该拥有全局权限。真实运维场景只需要查状态、看慢日志、杀连接、备份前锁表、分析表等，对应的是特定系统库和命令权限，不是“所有库所有表全操作”。
正确做法是分层授权：
- 基础监控：
GRANT SELECT ON performance_schema.* TO 'maint'@'localhost'; - 连接管理：
GRANT PROCESS, REPLICATION CLIENT ON *.* TO 'maint'@'localhost';（用于SHOW PROCESSLIST和查主从状态） - 备份相关：
GRANT LOCK TABLES, RELOAD ON *.* TO 'maint'@'localhost';（mysqldump需要） - 日志查看：
GRANT SELECT ON mysql.general_log TO 'maint'@'localhost';（如已启用通用日志） - 禁止授予
DROP、CREATE USER、GRANT OPTION—— 这些属于 DBA 管理范畴，非必要不开放
FLUSH PRIVILEGES 不是每次都要执行
用 CREATE USER 和 GRANT 创建用户并授权时，MySQL 8.0+ 会自动刷新权限缓存，FLUSH PRIVILEGES 是多余的；只有直接修改 mysql.user 表（比如用 UPDATE 改密码字段）才需要它。
误加 FLUSH PRIVILEGES 不报错，但可能掩盖真正问题——比如你授权后仍连不上，大概率是 host 写错了，而不是权限没生效。
验证是否成功，直接用新用户登录测试：
mysql -u maint -p -h 127.0.0.1
如果提示 Access denied，优先检查 SELECT User, Host FROM mysql.user WHERE User = 'maint';，确认 host 值和你连接时用的 host 完全一致（注意 localhost 和 127.0.0.1 在 MySQL 中被视为不同 host）。
密码策略和过期设置不能忽略
运维账号一旦泄露，危害极大。MySQL 8.0 支持原生密码策略，建议强制启用：
- 设定期限：
ALTER USER 'maint'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY; - 限制重用：
ALTER USER 'maint'@'localhost' PASSWORD HISTORY 5;（最近5次密码不可重复） - 要求复杂度（需提前配置 validate_password 组件）：
SET GLOBAL validate_password.policy = 'STRONG';
这些设置不会立即生效于已有连接，但下次登录或改密时强制校验。别指望靠“提醒邮件”来管密码更新——MySQL 不发邮件，到期后用户直接被拒绝登录。
真正容易被忽略的点：host 名匹配是严格字符串比对，'maint'@'localhost' 无法用 127.0.0.1 连接，反之亦然；而 DNS 解析失败时，MySQL 可能将 IP 自动映射为 host_name，导致实际匹配的 host 和你预期的不同。调试时始终用 SELECT CURRENT_USER(); 确认登录身份。
