17370845950

MySQL权限管理四大陷阱：①转发权限需显式加WITH GRANT OPTION；②'localhost'与'127.0.0.1'是不同账号，权限不互通；③REVOKE后活跃连接权限仍有效，需KILL CONNECTION生效；④MySQL 8.0默认认证插件不兼容旧客户端，需指定IDENTIFIED WITH。

GRANT 语句没加 WITH GRANT OPTION 却想转发权限

很多人执行 GRANT SELECT ON db.* TO 'user'@'%' 后，以为该用户能帮别人授权，结果 GRANT SELECT ON db.tbl TO 'other'@'localhost' 直接报错 ERROR 1045 (28000): Access denied for user。MySQL 默认禁止权限转授，必须显式加上 WITH GRANT OPTION 才行。

实操建议：

• 只在真正需要代理授权的账号上加 WITH GRANT OPTION，比如 DBA 助理账号
• 加完记得刷新：执行 FLUSH PRIVILEGES（虽然多数情况自动生效，但旧版本或特殊部署下仍需手动刷）
• 注意：拥有 WITH GRANT OPTION 的用户，也能把自己没有的权限（比如 CREATE USER）转授出去——只要其上级授予了该权限并带此选项

Host 匹配规则被忽略导致连接失败

'user'@'localhost' 和 'user'@'127.0.0.1' 在 MySQL 里是两个完全不同的账号，权限互不影响。本地用 mysql 客户端默认走 socket 连接（匹配 localhost），而用 IP 连接（如 mysql -h 127.0.0.1）则匹配 127.0.0.1 ——如果只给前者授了权，后者就会报 Access denied。

常见误区：

• 测试时用 localhost 成功，上线用容器或代理连 127.0.0.1 就失败
• 误以为 'user'@'%' 能覆盖所有地址，其实它不匹配 localhost（Unix socket 场景优先级更高）
• 防火墙或云厂商安全组放行了端口，但 MySQL 没开远程 host 权限，白忙一场

REVOKE 后权限没立即失效

执行 REVOKE DELETE ON db.* FROM 'user'@'%' 后，已建立的连接仍保有旧权限，直到断开重连。这不是 bug，是 MySQL 的设计：权限检查发生在命令执行时，但权限缓存存在于连接会话中。

关键点：

• 活跃连接不会因 REVOKE 或 DROP USER 立即中断，也不会丢权限
• 要立刻生效，只能杀掉连接：KILL CONNECTION （查 SHOW PROCESSLIST 获取 ID）
• FLUSH PRIVILEGES 对 REVOKE 无效——它只重载 mysql.user 表，而 REVOKE 已直接修改了权限表

创建用户时没指定 IDENTIFIED WITH 导致认证失败

MySQL 8.0+ 默认认证插件是 caching_sha2_password，但很多老客户端（如某些 Python MySQLdb、旧版 Navicat、PHP 5.x mysqli）不支持。如果建用户时没显式指定 IDENTIFIED WITH mysql_native_password，就可能连得上但执行任何语句都报 ERROR 1045 或卡在握手阶段。

正确写法示例：

CREATE USER 'app'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd123';
GRANT SELECT, INSERT ON mydb.* TO 'app'@'%';

补充说明：

• MySQL 5.7 及更早版本默认用 mysql_native_password，升级到 8.0 后新建用户行为变了
• 也可以全局降级：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'xxx';，但不推荐长期这么做
• 用 SELECT plugin FROM mysql.user WHERE User='xxx'; 查当前用户的认证插件

权限配置最麻烦的地方不在语法，而在“谁在什么上下文里以什么方式连接”。同一个用户名，localhost vs 127.0.0.1 vs 192.168.1.100 是三套权限体系；同一个 GRANT 语句，在 MySQL 5.7 和 8.0 下生效逻辑也可能不同。动手前先确认版本、连接方式、客户端能力，比反复试错快得多。