生产环境应严格遵循最小权限原则：只授具体数据库权限，禁用ALL PRIVILEGES和.，按需分配SELECT/INSERT/UPDATE/DELETE等细粒度权限，优先使用角色管理，禁用FLUSH PRIVILEGES冗余操作，并确保host匹配精准、禁用DNS解析。
权限粒度要按需收缩，别直接 GRANT ALL ON *.*
给用户分配 ALL PRIVILEGES 且作用域为 *.* 是最常见也最危险的授权方式。它绕过所有精细化控制，一旦账号泄露或误操作，后果不可控。生产环境应严格遵循最小权限原则：
- 只授予具体数据库（如
myapp_db），而非*.*或myapp_%这类模糊匹配 - 避免使用
GRANT OPTION，除非明确需要该用户转授权限 - 对只读服务（如报表、监控）仅授予
SELECT；对定时任务账户，通常只需INSERT, UPDATE, DELETE，不给DROP或ALTER - 注意
USAGE权限看似“无权”，实为创建账号但不赋任何操作权限的占位符，适合预留账号
用角色（ROLE）管理权限组，别反复 GRANT/REVOKE 单个用户
MySQL 8.0+ 支持角色，这是提升授权效率的关键机制。直接对每个用户重复执行 GRANT 不仅易出错，还让权限状态难以审计。正确做法是：
- 先创建角色，如
CREATE ROLE 'app_writer'，再批量授权：GRANT INSERT, UPDATE, DELETE ON myapp_db.* TO 'app_writer' - 把角色赋予用户：
GRANT 'app_writer' TO 'svc_user'@'10.20.30.%' - 启用角色需显式调用：
SET ROLE 'app_writer'（会话级）或设为默认：SET DEFAULT ROLE 'app_writer' TO 'svc_user'@'10.20.30.%' - 权限变更只需改角色，所有绑定该角色的用户自动生效，无需遍历重授
避免频繁刷新权限，别在脚本里反复执行 FLUSH PRIVILEGES
FLUSH PRIVILEGES 并非授权必需步骤——只要用标准 GRANT/REVOKE 语句，MySQL 会自动重载权限缓存。手动执行它反而可能引发问题：
- 在高并发场景下，
FLUSH PRIVILEGES会锁住权限系统表，阻塞其他授权操作 - 若之前用
INSERT INTO mysql.user等直接写表方式改权限，才需要它；但这种操作本身已被官方弃用，极易破坏权限一致性 - 自动化部署脚本中硬编码
FLUSH PRIVILEGES属于冗余操作，删掉即可
注意 host 匹配顺序和 DNS 解析开销
MySQL 权限检查时按 user@host 匹配，且 host 部分支持通配符（%、_），但匹配顺序有优先级：越具体的 host 越靠前。例如 'user'@'10.20.30.40' 优先于 'user'@'10.20.30.%'，而后者又优先于 'user'@'%'。实际中容易忽略两点：
- 用
'user'@'%'虽方便，但若服务器启用了skip_name_resolve=OFF（默认），每次连接都会触发反向 DNS 查询，显著拖慢认证速度 - 推荐始终用 IP 段或具体 IP（如
'user'@'10.20.30.%'），并确保skip_name_resolve=ON，彻底禁用 DNS 查找 - 检查当前生效的 host 匹配结果，可用：
SELECT User, Host FROM mysql.user WHERE User = 'your_user';，确认没有冲突或冗余条目
权限策略真正难的不是语法，而是持续收敛——新服务上线时多给一点权限很常见，但旧权限往往没人清理。定期用 SELECT * FROM mysql.role_edges 和 mysql.role_tables_priv 扫描未使用的角色与孤立权限，比一开始设计得完美更重要。
