生产环境应为不同角色创建最小权限账号：后端服务、定时任务、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。
