17370845950

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，某些查询会被拒绝，误以为是权限问题