MySQL 权限修改后不生效，主因是权限缓存在内存中未刷新或作用范围理解偏差；应优先用 GRANT/REVOKE 而非直接 UPDATE mysql.user 表，并显式执行 FLUSH PRIVILEGES;。
MySQL 权限修改后不生效，多数不是语法写错，而是权限加载机制没被触发或作用范围理解有偏差。核心在于：MySQL 把权限信息缓存在内存中，不是改完就立刻全局生效。
确认是否用了正确的授权方式
推荐始终用 GRANT / REVOKE 语句操作权限，而不是直接 UPDATE mysql.user 表。前者会自动触发权限重载（部分版本），后者必须手动执行 FLUSH PRIVILEGES; 才能生效。
- 正确示例：
GRANT SELECT ON mydb.* TO 'user1'@'localhost'; - 错误习惯：UPDATE mysql.user SET Select_priv=’Y’ WHERE User=’user1′; → 必须跟
FLUSH PRIVILEGES; - 注意：GRANT 后虽多数情况自动刷新，但为保险起见，仍建议显式执行一次
FLUSH PRIVILEGES;
区分权限级别，看生效时机
不同粒度的权限，生效时间点不同，不能一概而论“改完就该马上能用”：
- 表级或列级权限 （如
SELECT ON db.t1）：客户端下次发起相关请求时立即生效 - 数据库级权限 （如
SELECT ON db.*）：在客户端执行USE db;后即刻生效（实测如此，官网描述略有出入） - 全局权限 （如
SELECT ON *.*）：仅对新建立的连接生效，当前已连会话不受影响
验证权限是否真正加载成功
别只信自己执行了 GRANT，要查系统反馈：
- 查看目标用户的实际权限：
SHOW GRANTS FOR 'user1'@'localhost'; - 检查权限表是否同步更新：
SELECT Host,User,Select_priv,Insert_priv FROM mysql.user WHERE User='user1'; - 确认连接时用的账号和主机名完全匹配（
'user1'@'127.0.0.1'和'user1'@'localhost'是两个不同账户）
排除其他干扰因素
权限“看起来没变”，有时根本不是权限本身的问题：
- 客户端仍在使用旧连接：执行
KILL [connection_id];或直接断开重连 - MySQL 启动时加了
--skip-grant-tables：权限系统彻底失效，需停服务、去掉参数、重启 - 连接到了错误实例：比如本地有多个 MySQL（Docker、Homebrew、系统自带），确认
mysql -h 127.0.0.1 -P 3306连的是你改权限的那个 - SQL mode 或安全限制拦截操作：例如开启了
sql_mode=STRICT_TRANS_TABLES,ONLY_FULL_GROUP_BY，某些查询会被拒绝，误以为是权限问题
