grant后权限未生效，先查select user(), current_user()确认实际认证身份，再用show grants for current_user()验证权限是否包含所需操作及作用域，最后核对mysql.user等系统表中对应(user,host)记录是否存在且字段正确。
GRANT 之后权限为什么没变
MySQL 的 GRANT 语句本身会自动触发权限缓存重载——但仅限于「该语句成功执行且未被事务回滚」的情况。很多你以为“执行成功了”，其实因为语法错误、用户不存在、数据库名拼错、或当前会话处于事务中，导致 GRANT 实际没写入系统表。更常见的是：你用 GRANT 给 'user'@'127.0.0.1' 授权，但客户端连的是 'user'@'localhost'，压根没匹配到那条记录，自然没权限。
FLUSH PRIVILEGES 到底该不该用
FLUSH PRIVILEGES 不是给 GRANT “补救”的万能命令。它只做一件事：强制从磁盘的 mysql.user、mysql.db 等表重新加载权限到内存缓存。但它不会修复以下问题：
- 用户连接时匹配到了错误的
(user, host)记录（比如localhost和127.0.0.1是两条独立记录） - 你改了
mysql.user表但忘了FLUSH PRIVILEGES—— 这时才需要它 - 你用
DROP USER或CREATE USER，这些语句本身就会刷新缓存，再执行FLUSH PRIVILEGES是冗余的 - MySQL 8.0+ 中启用了角色（ROLE），而用户没
SET DEFAULT ROLE，权限也不会生效
排查权限是否真生效的三步验证
别猜，直接查：
- 先确认当前连接身份：
SELECT USER(), CURRENT_USER();—— 前者是“你声称是谁”，后者才是 MySQL 实际认证成功的user@host - 再查真实权限：
SHOW GRANTS FOR CURRENT_USER();或SHOW GRANTS FOR 'user'@'host';，看输出里有没有你要的权限和对应作用域（比如ON mydb.*而不是ON *.*） - 最后核对底层数据：
SELECT host, user, select_priv, insert_priv FROM mysql.user WHERE user = 'xxx';，注意select_priv是全局级，数据库级权限在mysql.db表里，得联合查
容易被忽略的 host 匹配陷阱
MySQL 的 host 匹配不是模糊搜索，而是精确匹配 + 通配符规则：
-
'user'@'localhost'只匹配 socket 连接，不接受 TCP 的127.0.0.1 -
'user'@'%'匹配任意非 localhost 的 IP，但明确不匹配localhost - 带下划线
_或百分号%的通配符只在字符串匹配时生效，DNS 解析失败时可能 fallback 到 IP，导致实际匹配的host和你预期不同 - 容器或云环境里，客户端 IP 经常动态变化，用
%要谨慎；更稳妥的是明确授权到具体子网，如'user'@'10.0.2.%'
真正卡住人的往往不是权限没加，而是加给了一个 MySQL 根本没用上的 (user, host) 组合。每次怀疑权限失效，先跑一遍 CURRENT_USER() 和 SHOW GRANTS，比反复 FLUSH 有用得多。
