GRANT和REVOKE是落实最小权限原则的唯二核心操作，必须人工逐条确认账号权限范围、主机来源及业务需求；创建用户须显式限定host与强密码，禁用'%'通配，授予权限须精确到database.table级别，FLUSH PRIVILEGES仅在直接修改系统表后必需，且不影响已存在连接。
GRANT 和 REVOKE 是落实最小权限原则的唯二核心操作，不是靠“设置开关”或“启用插件”就能自动生效的。必须人工逐条确认每个账号的权限范围、主机来源和实际业务需求。
创建用户时必须显式限定 host 和密码强度
默认用 'user'@'%' 是最大安全隐患之一——它允许该账号从任意 IP 连接，一旦密码泄露或被撞库，攻击面直接扩大到整个网络。生产环境应严格按服务部署位置指定 host：
-
'app_user'@'10.1.2.3'：应用服务器固定内网 IP -
'backup_user'@'172.16.0.10'：备份服务器专用地址 -
'dev_user'@'192.168.5.%'：开发网段，不开放公网
同时启用 validate_password 插件，避免弱密码被绕过。执行前确认已加载：SELECT PLUGIN_NAME, PLUGIN_STATUS FROM information_schema.PLUGINS WHERE PLUGIN_NAME = 'validate_password';。未启用时需在配置文件中加入 plugin_load_add = validate_password.so 并重启。
授予权限必须精确到 database.table 级别
常见错误是写成 GRANT ALL PRIVILEGES ON *.* TO ... 或 GRANT SELECT ON *.* TO ...，这等于放弃最小权限控制。真实场景中：
- 订单服务只需
GRANT SELECT, INSERT, UPDATE ON shop_db.orders TO 'order_app'@'10.1.2.3'; - 报表系统只读，且仅限统计表：
GRANT SELECT ON report_db.daily_summary TO 'reporter'@'172.16.0.10'; - 绝不给应用账号
DROP、CREATE、ALTER权限，哪怕它跑的是 ORM
MySQL 8.0+ 可用角色简化管理，但角色本身也要遵循最小原则：CREATE ROLE 'order_rw'; GRANT SELECT, INSERT, UPDATE ON shop_db.orders TO 'order_rw'; GRANT 'order_rw' TO 'order_app'@'10.1.2.3';。注意：角色默认不激活，登录后需手动 SET ROLE 'order_rw'; 或设为默认角色。
FLUSH PRIVILEGES 不是万能同步指令
执行 GRANT 或 REVOKE 后，权限变更会立即生效——前提是操作的是当前 MySQL 实例的权限表。但如果你直接修改了 mysql.user 表（比如用 UPDATE 手动改密码或 host），才需要 FLUSH PRIVILEGES 刷新内存缓存。
更关键的是：权限变更对**已存在的连接不生效**。也就是说，一个正在运行的应用连接不会因为新 REVOKE 就立刻失去权限，它会维持到下次重连。所以权限回收后，要配合应用侧连接池重启或等待连接自然释放。
验证权限是否到位，别信记忆或文档，用：SHOW GRANTS FOR 'app_user'@'10.1.2.3'; —— 输出结果里不能出现 ON *.*，也不能有 WITH GRANT OPTION，除非你明确知道谁在用它、为什么需要它。
定期清理和审计不可跳过
权限不是配置一次就一劳永逸。每月至少执行一次检查：
- 查过期账号：
SELECT user, host, password_last_changed FROM mysql.user WHERE password_last_changed - 查无效 host：
SELECT user, host FROM mysql.user WHERE host NOT IN ('localhost', '10.1.2.3', '172.16.0.10'); - 查高危权限：
SELECT user, host FROM mysql.user WHERE Super_priv = 'Y' OR File_priv = 'Y' OR Shutdown_priv = 'Y';
发现异常账号，先 REVOKE 所有权限，再 DROP USER；注意 DROP USER 不会自动清空权限缓存，如果该用户仍有活跃连接，得等连接断开或重启 mysqld 才彻底失效。
真正难的不是写出那几行 GRANT，而是持续判断“这个权限现在还必要吗”——业务迭代、人员变动、临时调试都会让权限悄悄膨胀。没有审计机制的最小权限，只是幻觉。
