绝大多数情况下不用执行flush privileges；标准grant/revoke语句会自动重载权限缓存，仅在直接修改mysql系统表时才需手动刷新。
GRANT后还要不要执行FLUSH PRIVILEGES？
绝大多数情况下——不用。只要你用的是标准 GRANT 或 REVOKE 语句，MySQL（5.7+ 及 8.0）会自动重载权限缓存，新连接立刻生效。FLUSH PRIVILEGES; 加了不报错，但属于“多此一举”，还容易让你误以为“不刷就不生效”，从而忽略真正的问题根源。
- 唯一必须执行
FLUSH PRIVILEGES;的场景：你绕过授权语法，直接UPDATE mysql.user或INSERT INTO mysql.db修改了系统表 - 如果不确定自己是否用了标准语句，可以查操作历史：
select * FROM mysql.general_log WHERE argument LIKE '%GRANT%' OR argument LIKE '%REVOKE%' ORDER BY event_time DESC LIMIT 5; - 注意：MySQL 8.0.16+ 在
mysqld --upgrade过程中也会自动刷新，此时手动刷反而可能干扰升级流程
为什么刚授权的用户还是 access denied？
最常见原因不是权限没给对，而是你还在用旧连接——MySQL 权限检查只发生在连接建立那一刻，已存在的连接不会动态更新权限。
- 必须断开重连：
QUIT;后再重新执行mysql -u user -p，否则永远卡在旧权限里 -
'user'@'localhost'和'user'@'127.0.0.1'是两个完全不同的账号：前者走 unix socket，后者走 TCP/IP；连错一个就匹配不上 - 检查是否多打了空格，比如
'user '@'localhost'（末尾有空格）→ 实际存的是带空格的用户名，根本查不到 - MySQL 8.0+ 默认认证插件是
caching_sha2_password，老版本客户端（如某些 JDBC 8.0 以下驱动）可能静默降级失败，表现为“能连上但权限不生效”
不同粒度权限，什么时候才真正起作用？
不是所有权限改完都要重连，生效时机取决于你授的是哪一级权限，这点官网文档写得模糊，实测结果更可靠：
- 表级或列级权限（如
GRANT SELECT ON mydb.t1 TO 'u'@'h';）：下次执行SELECT * FROM t1;就生效，当前连接内即可 - 数据库级权限（如
GRANT SELECT ON mydb.* TO 'u'@'h';）：执行USE mydb;后立即生效，不用重连 - 全局权限（如
GRANT SELECT ON *.* TO 'u'@'h';）：仅对新连接生效，当前连接无论怎么USE都没用
验证是否生效，别只信 SHOW GRANTS for 'u'@'h';，要真跑一句 SELECT 或 INSERT 看报错。
权限表改了但死活不生效？先确认是不是跳过了权限校验
如果你确认改了 mysql.user 表、也执行了 FLUSH PRIVILEGES;，但还是不行，就要怀疑更底层的问题：
- MySQL 是不是用
--skip-grant-tables启动的？这种模式下所有权限校验被跳过，GRANT语句根本不会写入表，任何刷新都无效 - 字段大小写是否一致？linux 下
'ROOT'@'localhost'≠'root'@'localhost'，查表时用错大小写就看不到数据 - 密码字段填错没？5.7+ 已弃用
Password字段，该填authentication_string；误更新成空值会导致账号变“无密码”或认证失败 - 有没有连错实例？本地同时跑 docker、Homebrew、系统自带 MySQL，
mysql -u root默认连的是 socket，而你改权限的可能是mysql -h 127.0.0.1 -P 3307的另一个实例
权限问题从来不是“改完就完”，它卡在连接、匹配、加载、校验四个环节中的任意一环；排查时别急着刷缓存，先问自己：我连的是谁？用的是哪个主机名？权限到底加到哪张表里了？