FLUSH PRIVILEGES执行成功≠当前连接权限生效，因已有连接权限快照在登录时已固化，必须QUIT后重连才生效；同时需确保User@Host精确匹配、phpMyAdmin前端手动刷新元数据。
FLUSH PRIVILEGES执行成功 ≠ 权限已对当前连接生效
这是最常被误解的一点：FLUSH PRIVILEGES 只是强制 MySQL 从磁盘重新加载权限表到内存，它不改变任何已有连接的权限快照。当前连接在建立时就固化了权限状态，后续无论你刷多少次、改多少次，该连接都继续用最初认证时拿到的权限。
验证方式很简单：在执行 FLUSH PRIVILEGES 后，用同一客户端执行 QUIT;，再重新 mysql -u u -p -h host 登录，然后测试操作（比如 SELECT 或 INSERT）——这才是真正检验权限是否生效的路径。
- 别信
SHOW GRANTS FOR 'u'@'h'的输出，它只说明语句执行成功，不代表当前会话能用 -
'u'@'localhost'和'u'@'127.0.0.1'是两个完全独立的账号，授权和连接必须严格匹配 - 如果用了
GRANT但没重连，也出现“不生效”，那不是缓存问题，而是会话生命周期限制
你根本没改对权限作用域或 host 匹配失败
执行 FLUSH PRIVILEGES 前，先确认你修改的是正确的记录行。MySQL 权限校验是按 User + Host 组合精确匹配的，多一个空格、少一个 %、IP 解析偏差，都会导致“改了等于没改”。
检查方法：
- 运行
SELECT Host, User, Select_priv, Insert_priv FROM mysql.user WHERE User = 'u';，确认Host字段值与你实际连接时用的 host 完全一致（例如远程连接用的是'u'@'192.168.1.100'，但你只授了'u'@'%'，而 MySQL 8.0+ 默认不把%当作通配符匹配 IPv4 地址，需显式写'u'@'192.168.1.%'） - 用
SELECT USER(), CURRENT_USER();查看当前连接实际匹配到的账号名，CURRENT_USER()才是权限系统真正查的标识 - 若应用通过中间件（如 ProxySQL）或容器网络连接，
Host可能是容器名或网关 IP，而非你本地localhost
MySQL 8.0+ 中 FLUSH PRIVILEGES 对某些修改无效
在 MySQL 8.0+，特别是启用了 caching_sha2_password 插件后，直接 UPDATE mysql.user 修改 authentication_string 字段极易出错：格式不对、加密方式不匹配、plugin 字段未同步更新，都会导致账号无法登录——此时 FLUSH PRIVILEGES 不会报错，但新权限（甚至账号本身）实际不可用。
更危险的是：如果你手动改了 plugin 或 account_locked 字段，FLUSH PRIVILEGES 不会校验合法性，也不会回滚，可能直接锁死账号。
- 优先用
ALTER USER 'u'@'h' IDENTIFIED WITH mysql_native_password BY 'pwd';替代手改表 - 改完后仍建议执行
FLUSH PRIVILEGES（部分旧版 8.0.x 中ALTER USER不自动刷新） - 托管环境（如阿里云 RDS、腾讯云 CDB）通常禁用
FLUSH PRIVILEGES，直接返回ERROR 1227 (42501)，这时只能走控制台或 API 授权
phpMyAdmin 界面权限状态未同步
即使 FLUSH PRIVILEGES 成功、你也重连了，phpMyAdmin 左侧导航栏仍可能显示旧权限状态（比如“编辑”图标灰掉），这不是 MySQL 的问题，而是 phpMyAdmin 自身元数据缓存未刷新。
必须手动触发前端刷新：
- 点击左侧顶部的 ↻ 刷新按钮（不是浏览器 F5）
- 或访问带
&reload=1参数的 URL，例如：/phpmyadmin/tbl_structure.php?db=test&table=users&reload=1 - 如果刚加了
UPDATE权限但编辑图标没出来，大概率就是这一步漏了
权限变更和前端元数据刷新是两个完全独立的动作，缺一不可；而很多人以为只要 SQL 执行成功，界面就会自动同步。
