FLUSH PRIVILEGES单独执行无效，因其仅刷新权限缓存，无法解决user表中缺失匹配host记录或认证插件不兼容等根本问题；必须先创建/修正'user'@'host'条目并指定正确plugin，再执行FLUSH PRIVILEGES才生效。
navicat连接mysql 8.x报“access denied”或“host not allowed”时，仅执行flush privileges几乎从不解决问题——它只是刷新内存中的权限缓存，而真正被拒绝的原因通常在用户定义本身。
为什么FLUSH PRIVILEGES单独执行无效
MySQL在执行GRANT或ALTER USER后，会自动将权限写入磁盘并加载到内存，FLUSH PRIVILEGES仅在你**直接修改mysql.user表（不推荐）**后才需要。绝大多数“拒绝访问”问题根源是：user表里根本没有匹配的host记录，或认证插件不兼容。盲目刷权限只会掩盖真实配置缺陷。
- 执行
SELECT User, Host FROM mysql.user WHERE User = 'root';，确认输出中是否存在'root'@'127.0.0.1'或'root'@'%'这类允许当前连接来源的行 - 若只有
'root'@'localhost'，而Navicat用的是127.0.0.1（TCP）而非localhost（socket），就会因host不匹配被拒 -
FLUSH PRIVILEGES无法凭空生成缺失的host条目，也不能改变已存在的plugin字段值
必须先修正用户记录再考虑是否刷新
当确认需新增或更新用户权限时，应按顺序操作，FLUSH PRIVILEGES仅作为收尾动作：
- 若要允许本地Navicat通过TCP连接：执行
CREATE USER 'root'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY 'your_password';，再GRANT ALL ON *.* TO 'root'@'127.0.0.1' WITH GRANT OPTION; - 若已存在
'root'@'127.0.0.1'但认证插件是caching_sha2_password：执行ALTER USER 'root'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY 'your_password'; - 执行
FLUSH PRIVILEGES;——此时才有意义，确保新配置立即生效 - 重启MySQL服务不是必须步骤，除非你修改了
my.cnf中的bind-address或default_authentication_plugin
Navicat连接时host字段匹配的隐含规则
MySQL的host匹配是严格字符串比对，不是IP解析或通配符模糊匹配。常见陷阱：
-
localhost≠127.0.0.1：前者走Unix socket，后者走TCP；Navicat默认用TCP，填localhost可能触发socket fallback失败 -
%不匹配localhost：MySQL规定%通配符不覆盖localhost这个特殊字面量，必须显式创建'user'@'localhost' - IPv6环境下，
::1是独立host值，需单独授权，%也不覆盖它 - Navicat连接测试失败后，不要只看错误文字——用
SELECT host,user,plugin FROM mysql.user;查实际生效的记录，比猜更可靠
真正卡住人的从来不是FLUSH PRIVILEGES要不要执行，而是没意识到MySQL拒绝连接的第一道关卡永远是user表里有没有那条精确匹配的host + user + plugin三元组。补全它，再刷新，才是闭环。
