如何为不同角色创建最小权限账号
生产环境绝不能用
root或全库
ALL PRIVILEGES账号连接应用。真实项目里，后端服务、定时任务、DBA 工具、只读报表系统，必须分账号、分库、分表授权。
典型做法是按职责建账号，例如：
app_rw@'10.20.%'：只给业务库
myapp_prod的
SELECT,INSERT,UPDATE,DELETE，且仅限内网 IP 段
report_ro@'192.168.%'：只给
myapp_prod和
analytics库的
SELECT，显式禁用
LOCK TABLES防止阻塞写入
backup_user@'localhost'：仅授予
RELOAD,PROCESS,LOCK TABLES,REPLICATION CLIENT，不给任何库级 DML 权限
执行时务必加
WITH GRANT OPTION仅当真需要代理授权（极少见），否则留口子等于放行越权。
为什么 FLUSH PRIVILEGES 常被误用
新手常在
GRANT后手动执行
FLUSH PRIVILEGES，其实这是多余操作——
GRANT和
REVOKE语句本身就会自动重载权限缓存。只有直接修改
mysql.user等系统表后才需手动刷。
误用后果：不报错但多一次无谓的全局锁，高并发时可能短暂阻塞其他权限变更。更危险的是，有人把它当成“生效延迟”的补救手段，结果掩盖了真正问题（比如 host 匹配失败、大小写敏感、SSL 要求未满足）。
验证权限是否生效，直接用新账号连上执行：
SHOW GRANTS FOR 'app_rw'@'10.20.%';
host 字段匹配规则容易踩的坑
MySQL 权限判断顺序是：先按
User+
Host组合精确匹配，再按
Host通配符（
%、
_）最长前缀匹配。但注意：
%不匹配空 host，也不匹配 localhost —— 因为
localhost默认走 socket 连接，而
%只匹配 TCP/IP。
常见翻车点：
应用配置了host: 127.0.0.1，但账号只建了
'user'@'localhost'→ 连不上（socket vs TCP） 建了
'user'@'%'却忘了删掉同名的
'user'@'127.0.0.1'→ 实际生效的是更具体的那个，导致权限比预期小 用
'user'@'%.company.com'授权，但客户端解析出的 hostname 是
db01.internal.company.com→ 匹配成功；若解析成
db01→ 不匹配
建议统一用 IP 段（如
'user'@'10.20.%.%'）或 CIDR 式掩码（MySQL 8.0+ 支持
'user'@'10.20.0.0/255.255.0.0'），避免 hostname 解析不确定性。
MySQL 8.0 的角色（ROLE）不是银弹
虽然
CREATE ROLE+
GRANT role_name TO user看起来能简化管理，但实际项目中要谨慎启用： 角色不能跨实例复用，备份恢复后需重新创建； 应用连接时默认不激活角色，得显式执行
SET ROLE role_name或在
CREATE USER时指定
DEFAULT ROLE； ORM（如 Django、MyBatis）通常不支持连接后自动 set role，容易导致权限失效静默报错； 监控工具、慢查日志里的
USER()显示的是登录用户，不是当前激活角色，排查时易混淆。
中小团队建议仍用传统账号粒度管理；大型多租户平台可考虑角色，但必须配套自动化脚本同步角色定义，并在连接池初始化 SQL 中固化
SET DEFAULT ROLE。
权限这事，越早约束越省事。等线上出了一次越权删库，或者审计扫出二十个 root-like 账号，再回头收口，代价远不止改几条 SQL。
