生产环境应为不同角色创建最小权限账号：后端服务、定时任务、DBA工具、只读报表系统须分账号、分库、分表授权，如app_rw@'10.20.%'仅限业务库DML，report_ro@'192.168.%'仅限SELECT且禁用LOCK TABLES，backup_user@'localhost'仅授备份所需权限；GRANT后无需FLUSH PRIVILEGES；host匹配需注意localhost与127.0.0.1差异及通配符规则；MySQL 8.0角色非银弹，ORM兼容性差，中小团队建议沿用传统账号管理。
如何为不同角色创建最小权限账号
生产环境绝不能用 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。
