权限粒度要按需收缩，别直接 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扫描未使用的角色与孤立权限，比一开始设计得完美更重要。
