mysql权限配置常见错误有哪些_mysql安全避坑指南

来源：这里教程网时间：2026-02-28 20:48:50 作者：

GRANT 语句没加 WITH GRANT OPTION 却想授权给别人

很多人执行

GRANT SELECT ON db.* TO 'user'@'%'

后，发现这个 user 自己能连上，但无法把权限再转授给其他人——这很正常，因为 MySQL 默认不开启代理授权能力。只有显式加上

WITH GRANT OPTION

，该用户才拥有“授予权限的权限”。但要注意：

WITH GRANT OPTION

本身不是独立权限，不能单独回收，只能随同其他权限一起用

REVOKE

撤销。

错误写法：
GRANT SELECT ON db.* TO 'a'@'%' ;
→ a 无法再
GRANT
给 b 正确写法：
GRANT SELECT ON db.* TO 'a'@'%' WITH GRANT OPTION;
隐患：一旦授予，a 就可能绕过 DBA 控制链，尤其在多租户场景下容易失控

localhost 和 127.0.0.1 被当成两个不同 host 导致权限不生效

MySQL 的权限系统严格区分

'user'@'localhost'

和

'user'@'127.0.0.1'

，哪怕你本地用 mysql 客户端连

127.0.0.1

，匹配的也是后者，前者只响应 Unix socket 连接（即不走 TCP）。很多同学配完

'user'@'localhost'

权限后，在命令行用

mysql -h 127.0.0.1 -u user

死活连不上，就是卡在这儿。

验证方式：
SELECT USER(), CURRENT_USER();
—— 前者是客户端声明的身份，后者才是实际匹配的权限账户安全建议：如无特殊需求，统一用
'user'@'127.0.0.1'
或更严格的内网 IP 段，避免
'user'@'%'
注意：
localhost
是个特殊标记，不会被 DNS 解析，也不走网络栈；而
127.0.0.1
是标准 IPv4 地址，强制走 TCP

FLUSH PRIVILEGES 忘了执行或执行了也没用

直接改

mysql.user

表（比如用 UPDATE）后，必须执行

FLUSH PRIVILEGES;

才能让内存中的权限缓存刷新；但如果你是用

GRANT

CREATE USER

等 DCL 语句操作的，MySQL 会自动重载，此时再执行

FLUSH PRIVILEGES;

不仅多余，还可能掩盖误操作——比如你本想删用户却手抖写了

GRANT

，又立刻

FLUSH

，反而让错误权限立即生效。

需要手动 FLUSH 的场景：直连 mysql 库、UPDATE/INSERT/DELETE 权限表 不需要 FLUSH 的场景：
GRANT
、
REVOKE
、
DROP USER
、
ALTER USER
典型误操作：
UPDATE mysql.user SET authentication_string=... WHERE User='x'; FLUSH PRIVILEGES;
→ 密码字段名在 5.7+ 是
authentication_string
，8.0+ 又改回
password
？错，8.0 已移除 password 字段，必须用
ALTER USER

root@localhost 被禁用远程登录后，误删本地登录入口

有些运维为了“加固”，执行

DROP USER 'root'@'localhost';

或

DELETE FROM mysql.user WHERE User='root' AND Host='localhost';

，结果本地

sudo mysql

也登不进去了。MySQL 启动时如果找不到任何

root@localhost

（且未启用

--skip-grant-tables

），就真进不去了。

恢复手段极麻烦：需停库、加
--skip-grant-tables
启动、手工 INSERT 回 root 用户、再重启安全替代方案：保留
'root'@'localhost'
，仅限制其只能从本地 socket 登录；对远程管理，新建专用账号并限定 IP 段，如
'admin'@'192.168.10.%'
关键点：MySQL 5.7+ 默认 root 只有
'root'@'localhost'
，没有
'root'@'%'
，别一上来就 DROP

权限模型看着简单，但 host 匹配顺序、大小写敏感性、密码插件差异（