应严格遵循最小权限原则，按角色分账号并限定库表、禁用匿名用户、强制复杂密码与IP限制、定期审计清理账号、慎授sys/performance_schema权限，持续验证加固效果。
只给最小必要权限，别用 GRANT ALL PRIVILEGES
直接给用户 GRANT ALL PRIVILEGES 是最常见也最危险的操作，尤其在生产环境。它等同于把数据库的“管理员钥匙”交出去，哪怕只是临时排查问题，也可能被误操作或恶意利用。
实操建议：
- 按业务角色拆分账号：比如
app_readonly只有SELECT权限，app_writer仅限INSERT, UPDATE, DELETE，且限定到具体库表（如ON myapp.users TO 'app_writer'@'10.20.30.%'） - 避免使用
ON *.*，哪怕对监控账号也要限制到performance_schema或information_schema的特定视图 - 删除默认匿名用户：
DROP USER ''@'localhost'; DROP USER ''@'%';，它们常被忽略但可能被利用
密码策略和连接来源必须显式控制
MySQL 默认不强制复杂密码，也不校验连接 IP 的合法性，这就导致弱口令 + 任意 IP 登录 = 高危暴露面。
实操建议：
- 启用
validate_password插件并设最低要求：SET GLOBAL validate_password.policy = MEDIUM;，再检查validate_password.length和validate_password.mixed_case_count - 用户创建时务必指定 host：
CREATE USER 'backup_user'@'192.168.5.100' IDENTIFIED BY 'xxx';，禁止用'%'，除非有明确代理或跳板机需求 - 若必须远程访问，配合防火墙（如 iptables 或云安全组）二次限制源 IP 段，不要只依赖 MySQL 的 host 字段
定期清理不用账号和过期权限
权限不是“设一次就完事”。开发测试账号残留、离职人员未删、临时调试账号未回收——这些都会成为攻击入口。
实操建议：
- 每月执行一次审计：
SELECT user, host, account_locked FROM mysql.user WHERE account_locked = 'Y' OR password_last_changed - 用
SHOW GRANTS FOR 'old_dev'@'10.0.0.%';确认权限范围，再用DROP USER彻底删除，注意DROP USER不会自动回收权限缓存，需跟FLUSH PRIVILEGES; - 对长期不用但又不敢删的账号，先用
ALTER USER 'x'@'y' ACCOUNT LOCK;锁定，观察两周无异常再清理
mysql.sys 和 performance_schema 权限要特别小心
这两个库看似只读，但能暴露大量运行时信息：正在执行的 SQL、锁等待链、内存分配细节，甚至临时表内容。攻击者可借此定位敏感表或构造注入。
实操建议：
- 禁止普通应用账号访问
sys库：REVOKE SELECT ON sys.* FROM 'app_user'@'%';（默认 5.7+ 新建用户已无此权限，但升级或迁移后可能继承） - 如需性能监控，单独建只读账号，并限制到必要视图，例如：
GRANT SELECT ON performance_schema.events_statements_summary_by_digest TO 'monitor'@'127.0.0.1'; - 确认
performance_schema本身已启用（SELECT @@performance_schema;返回ON），否则部分权限控制无效
权限加固不是一次性配置，而是持续收敛的过程。最容易被忽略的是：权限变更后没验证实际效果（比如改了 host 却忘了重启应用连接池），以及低估 INFORMATION_SCHEMA 的信息泄露风险——它不需要显式授权就能被多数账号访问，里面藏着表结构、索引名甚至触发器定义。
