如何排查MySQL中GRANT语句执行成功但权限不生效的问题？-mysql教程-PHP中文网

grant后权限不生效，首要确认实际连接的(user,host)与授权目标一致，并断开重连；表级权限执行对应sql即生效，库级需use，全局权限仅新连接有效；mysql 8.0+需激活角色并确保认证插件兼容。

如何排查mysql中grant语句执行成功但权限不生效的问题？

先确认你连的是哪个账号、哪个实例

执行 GRANT 后权限不生效，最常踩的坑是：你以为改了 'u'@'localhost'，但客户端实际连的是 'u'@'127.0.0.1'；或者你在 Docker 容器里执行了授权，却从宿主机用 mysql -u u -p 连到了系统自带的 MySQL 实例。

立刻验证当前会话身份：
SELECT USER(), CURRENT_USER();
前者是你“声称”的身份（登录时指定的），后者才是 MySQL 实际认证成功的 (user, host) 组合。如果两者不一致，说明 host 匹配失败——比如你授权给了 'u'@'%'，但 DNS 解析失败后 fallback 到 IP，结果匹配到 'u'@'10.0.2.15' 这条不存在的记录。

查具体实例监听地址：ss -tln | grep :3306，确认输出含 *:3306 或 0.0.0.0:3306，而非仅 127.0.0.1:3306
检查配置文件中 bind-address 是否为 127.0.0.1（需注释或改为 0.0.0.0 并重启服务）
云环境务必同步检查安全组是否放行 3306 入方向

别只信 SHOW GRANTS，要真跑一句 SQL 验证

SHOW GRANTS FOR 'u'@'h'; 只显示声明过的权限，不代表它在当前连接上下文里可用。例如你授了 SELECT ON mydb.*，但还没执行 USE mydb;，此时直接 SELECT * FROM t; 仍会报错。

不同粒度权限生效时机完全不同：

表级权限（如 GRANT SELECT ON mydb.t TO 'u'@'h';）：下次查询该表即生效，无需重连
库级权限（如 GRANT SELECT ON mydb.* TO 'u'@'h';）：必须先 USE mydb; 才能触发权限加载
全局权限（如 GRANT SELECT ON *.* TO 'u'@'h';）：只对新连接生效，当前会话无论怎么 USE 都无效

验证时直接执行目标操作：SELECT * FROM mydb.t LIMIT 1;，比看权限语句更可靠。

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

MySQL 8.0+ 角色和认证插件容易被忽略

如果你用的是 MySQL 8.0+，GRANT 成功但权限不生效，大概率是这两类问题之一：

角色没激活：GRANT 'reader' TO 'u'@'h'; 只建立绑定，不启用权限。必须补上 SET DEFAULT ROLE 'reader' TO 'u'@'h';，否则登录后 CURRENT_ROLE() 返回 NULL
认证插件不兼容：用户 plugin 字段是 caching_sha2_password，但客户端（如旧版 Navicat、PHP 7.3 或 JDBC 8.0 以下驱动）不支持，导致握手静默失败——表现为能登录，但一执行 SHOW DATABASES 就断开或报 Access denied

查插件：SELECT user, host, plugin FROM mysql.user WHERE user = 'u';
临时修复（仅针对出问题的用户）：ALTER USER 'u'@'h' IDENTIFIED WITH mysql_native_password BY 'pwd';

FLUSH PRIVILEGES 不是万能解药，反而可能掩盖问题

FLUSH PRIVILEGES; 只在你绕过授权语法、直接 UPDATE mysql.user 或 INSERT INTO mysql.db 修改系统表时才真正需要。标准 GRANT / REVOKE 在 MySQL 5.7+ 和 8.0+ 中会自动重载缓存，加了 FLUSH PRIVILEGES; 属于冗余操作。

如果加了它才“看起来生效”，说明你很可能：