什么时候必须用 FLUSH PRIVILEGES
只有在**直接修改 mysql 系统库的权限表（如 user、db、tables_priv）后**，才需要手动执行 FLUSH PRIVILEGES。MySQL 启动时会加载一次权限表到内存，之后所有权限检查都走内存副本——改表不刷新，新配置就永远不生效。
常见错误现象：CREATE USER 或 GRANT 成功，但用户仍连不上、报 Access denied；或者改了 user.Host 字段却没效果。
- 用
INSERT INTO mysql.user手动加账号？→ 必须FLUSH PRIVILEGES - 用
UPDATE mysql.user SET authentication_string = ...改密码？→ 必须FLUSH PRIVILEGES - 用
GRANT SELECT ON db.* TO 'u'@'%'？→ 不用，GRANT自带刷新 - 用
DROP USER或REVOKE？→ 不用，这些语句也自动刷新
FLUSH PRIVILEGES 为什么有时像“没用”
不是命令失效，而是你根本没改对地方。MySQL 8.0+ 默认启用 caching_sha2_password 插件，而旧版客户端或应用可能只支持 mysql_native_password。这时即使权限表改对了、也刷了，连接仍失败，错误信息通常是：Plugin caching_sha2_password could not be loaded 或 Access denied for user 但用户名密码没错。
- 检查当前用户认证插件：
SELECT Host, User, plugin FROM mysql.user WHERE User = 'your_user'; - 如果插件是
caching_sha2_password且环境不兼容，得显式切回：ALTER USER 'your_user'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd'; - 改完仍要
FLUSH PRIVILEGES（因为ALTER USER在某些旧版本中不自动刷新）
权限修复操作顺序不能错
直接 UPDATE 权限表 + FLUSH 是高危操作，顺序一乱就锁死自己。最稳妥路径是：先确保有另一个高权限账号能登进来，再操作主账号。
- 别在 root 账号里执行
UPDATE mysql.user SET Host='localhost' WHERE User='root'后立刻FLUSH—— 如果你正通过远程连接，这一步会让 root 失去所有远程访问能力，且无法回退 - 改
Host或plugin前，先用INSERT INTO mysql.user加一个临时管理员账号（比如'admin'@'localhost'），确认能登录后再动主账号 -
FLUSH PRIVILEGES不会校验 SQL 语法或字段值是否合法，填错authentication_string格式会导致该账号永久不可用
替代方案：优先用 GRANT/REVOKE，而不是手改表
95% 的权限调整根本不需要碰 mysql.user 表。GRANT 和 REVOKE 是安全封装，自带校验、事务保护和自动刷新，还能生成审计日志。
- 开放某个 IP 段访问：
CREATE USER 'app'@'192.168.1.%' IDENTIFIED BY 'x'; GRANT SELECT ON sales.* TO 'app'@'192.168.1.%'; - 回收某库写权限：
REVOKE INSERT, UPDATE, DELETE ON prod.* FROM 'dev'@'%'; - 想批量授权？写个脚本生成
GRANT语句，别写 UPDATE 循环
手改系统表只该出现在两种场景：MySQL 完全无法启动（需离线修复）、或调试权限机制本身。其他时候，它就是个容易踩空的坑。
