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的另一个实例
权限问题从来不是“改完就完”，它卡在连接、匹配、加载、校验四个环节中的任意一环；排查时别急着刷缓存，先问自己：我连的是谁？用的是哪个主机名？权限到底加到哪张表里了？
