mysql权限修改不生效主因是未重建连接、host匹配错误或权限粒度差异；grant后自动刷新缓存，无需flush privileges，旧连接仍用权限快照，必须quit后重连，且'u'@'localhost'与'u'@'127.0.0.1'为不同账号。
权限修改不生效，不是“没刷缓存”，而是权限没真正“上身”——它卡在连接、匹配或校验环节里了。Token Refresh 的思路其实很相似：不靠硬刷，而是用一次“换新凭证”的动作，让系统重新加载最新状态。
MySQL 权限要“重连”，就像 Token 要“换新”
MySQL 的权限只在连接建立时检查一次。改完 GRANT 后旧连接仍用老快照，就像 access token 过期后还硬发请求，结果必然是 Access denied。
- 必须执行 QUIT; 再重新登录，相当于前端拿到新 access token 后重发请求
- 别只看
SHOW GRANTS成功就以为生效了——得真跑一句SELECT或USE验证 - 注意
'u'@'localhost'和'u'@'127.0.0.1'是两个账号，连错 host 就像传错 token，一切白搭
不推荐 FLUSH PRIVILEGES，就像不该手动改 JWT payload
GRANT/REVOKE 自动刷新内存缓存，加 FLUSH PRIVILEGES 就像绕过认证服务直接篡改 token 内容——语法上可行，但掩盖真实问题，还可能引发锁竞争或策略失效。
GitHub Token
下载
使用个人访问令牌与GitHub交互，安全、用户可控的访问方式，无需OAuth或完整账户权限。支持克隆、推送、分支、PR、Issue等操作。适用于需要操作GitHub仓库的场景。
- 只有直接
UPDATE mysql.user才需要它，这属于“底层手术”，非常规操作 - 托管环境（如阿里云 RDS）通常禁用该命令，执行直接报错
- MySQL 8.0+ 中字段结构变化大，手动改表极易出错，
FLUSH也救不回来
不同粒度，生效节奏不同——和 Token 权限同步逻辑一致
权限不是“全有或全无”，它分层生效，就像 refresh token 换出的新 access token 必须包含用户当前最新角色和权限。
-
表级权限（如
GRANT SELECT ON db.t1）：下次查这张表就生效，无需重连 —— 类似局部权限热更新 -
数据库级权限（如
GRANT SELECT ON db.*）：执行USE db后才加载 —— 类似切换上下文触发重载 -
全局权限（如
GRANT SUPER ON *.*）：只对新连接有效 —— 必须“换新凭证”，无法热更
排查优先级：先确认“是否真的变了”
很多“不生效”根本不是权限问题，而是变更没落地。
- 查是否连错实例：
mysql -h 127.0.0.1 -P 3307和默认 socket 连的不是同一个 MySQL - 查认证插件兼容性：MySQL 8.0 默认用
caching_sha2_password，老客户端可能静默降级失败 - 确认没启用
--skip-grant-tables：此时所有权限校验被跳过，改什么都没用 - 升级后记得跑
mysqld --upgrade=FORCE，否则 5.7 → 8.0 表结构缺失会导致 GRANT 失效
