grant等规范语句修改权限后无需flush privileges，因其自动刷新内存缓存；仅直接update系统表时才必须执行该命令，且旧连接需重连才能生效新权限。
MySQL权限修改后通常不需要重启，也不需要手动执行 FLUSH PRIVILEGES —— 只要你是用 GRANT、REVOKE、CREATE USER 或 ALTER USER 操作的。
GRANT 后执行 FLUSH PRIVILEGES 是多余操作
MySQL 8.0+（以及 5.7 大多数场景）中，GRANT 语句本身会触发内存权限缓存的自动重载。执行 FLUSH PRIVILEGES 不报错，但不会带来任何额外效果，反而可能误导你去排查“刷新没成功”，而忽略真正的问题点。
- 新连接建立时，权限已按最新状态加载；旧连接仍保持原有权限上下文，这是设计使然，不是 bug
- 如果你刚
GRANT SELECT ON db1.* TO 'u'@'h'，用户下次执行USE db1才会触发该数据库级权限检查，不是立即全局生效 - 表级权限（如
GRANT SELECT ON db1.t1）在下一条对应SELECT语句执行时就生效，无需等待重连或刷新
必须用 FLUSH PRIVILEGES 的唯一常见场景
只有当你绕过授权语法，直接 UPDATE mysql.user 或 INSERT INTO mysql.db 修改系统表时，才必须执行 FLUSH PRIVILEGES。MySQL 不监听这些表变更，也不会自动同步到内存缓存。
- 直接
UPDATE前务必SELECT确认目标行，避免误改authentication_string或account_locked导致账号锁死 - MySQL 8.0+ 中
password_expired、password_last_changed等字段受内部逻辑保护，单纯UPDATE可能被忽略，应优先用ALTER USER - 主从架构下，
FLUSH PRIVILEGES只对当前实例生效，从库需单独执行（或确保主库 binlog 记录了授权语句）
连不上？先确认是不是权限根本没“上身”
报 Access denied for user 'xxx'@'%'，但你确定已 GRANT，大概率是权限没匹配上，而不是没生效。
- 已存在的连接不会动态更新权限：必须
QUIT后重连，不能指望“刚加的权限立刻在当前会话里起作用” -
'user'@'localhost'和'user'@'127.0.0.1'是两个独立账号，Unix socket 与 TCP/IP 路径不同，授权时 host 写错一个空格（如'user '）就完全不匹配 - MySQL 8.0+ 默认认证插件是
caching_sha2_password，老客户端（如旧版 Navicat、Python MySQLdb）可能静默降级失败：连接看似成功，实则权限验证跳过
升级后权限异常？先查系统表结构和插件
从 MySQL 5.7 升级到 8.0 后，若没运行 mysqld --upgrade=FORCE，mysql.user 表字段可能缺失（比如没有 authentication_string），导致 GRANT 实际写不进底层。
- 运行
DESC mysql.user，确认存在authentication_string、account_locked、plugin等 8.0 必需字段 - 检查关键用户插件：
SELECT User, Host, plugin FROM mysql.user，若为mysql_native_password且你用的是新客户端，可能需显式切换：ALTER USER 'u'@'h' IDENTIFIED WITH mysql_native_password BY 'pwd' - 权限表损坏或字符集不一致（如
mysql.user是utf8mb4，但客户端连接用latin1）也会导致FLUSH后部分权限加载异常
真正容易被忽略的点是：权限生效时机取决于粒度，而不是“改完就全量刷新”。表级权限热更新，数据库级要 USE，全局级必须重连——这不是缺陷，是 MySQL 权限系统的分层缓存机制决定的。
