MySQL 8创建不受限账号与授权全攻略：从GRANT到远程连接踩坑

1. 为什么MySQL 8的授权绕不开“版本差异”这道坎

MySQL 8刚发布那阵子，不少从5.7升过来的老玩家在添加用户和授权上集体踩坑。原因很简单：MySQL 8改了几处关键行为，网上大量教程还在用5.7时代的写法，照着抄自然翻车。

先明确“不受限版本”在这里的含义。它指的是创建MySQL账号时授予该账号最大的操作权限范围，通常包括全局权限（所有库、所有表）、授权权限（GRANT OPTION）以及允许从任意主机远程连接。这类账号多用于开发环境、内部运维系统或一次性数据迁移任务，目的是省去反复调整权限的麻烦，把精力集中在业务逻辑上。生产环境是否真要用“不受限”账号后面会单独说，但先学会怎么配置，才能在有需要时拿得出手，也能在不想用的时候知道怎么收回来。

MySQL 8.0相比5.7，用户体系层面有几个实质变化：

• 默认认证插件从mysql_native_password改成了caching_sha2_password。
• GRANT语句不再隐式创建用户。5.7里可以直接GRANT ALL ON *.* TO 'test'@'%'，MySQL 8会直接报错，必须先CREATE USER。
• GRANT之后不需要再执行FLUSH PRIVILEGES。很多人沿袭旧习惯，加完权限还非要刷一下，虽然无害，但没必要。密码或权限变更在内存中实时生效。
• PASSWORD()函数被移除。改密码用ALTER USER配合IDENTIFIED BY，旧语法SET PASSWORD = PASSWORD('xxx')直接不可用。

这几个差异是后续所有操作的底层逻辑。理解了它们，再看网上那些报错信息就不会慌。

看一个最简单的完整流程：

mysql -u root -p

进入命令行后依次执行：

CREATE USER 'dev'@'%' IDENTIFIED BY 'Dev@123456'; GRANT ALL PRIVILEGES ON *.* TO 'dev'@'%';

仅这两条，就完成了一个“不受限”账号的创建和授权。但为什么很多人照做之后还是连接失败？问题往往出在'%'的理解上，后面专门展开。

1.1 MySQL 8 与 5.7 在用户体系上的核心变化

MySQL 8.0把用户管理逻辑向更严格的方向收拢。最直观的一点是“先有用户，后有授权”。CREATE USER和GRANT被拆成两个独立动作，虽然命令本身不难，但改变了操作习惯。

GRANT不再隐式创建用户，意味着自动化脚本里如果直接执行授权语句，第一次跑一定会失败。这也是新手最常见的报错来源：

ERROR 1410 (42000): You are not allowed to create a user with GRANT

更让人困惑的是这个报错有时候不是马上出现。部分环境里因为root账号带有GRANT OPTION，MySQL 8在特定条件下可能给出不同的提示，总之想一条语句搞定用户和权限，在8.0里走不通。

另一个变化是密码插件。caching_sha2_password是MySQL 8的默认选择，它在安全性上确实更强，但对老客户端不友好。比如PHP 7.4之前的mysqli扩展、Python 3.6时代的某些连接器、或者Navicat老版本，都可能报Authentication plugin 'caching_sha2_password' cannot be loaded。解决方案一般有两种：升级客户端，或者把账号的认证插件改回mysql_native_password。

ALTER USER 'dev'@'%' IDENTIFIED WITH mysql_native_password BY 'Dev@123456';

这种修改只影响单个账号，不影响服务端全局配置。实际使用中很推荐这种方式，而不是去改my.cnf里的default_authentication_plugin，后者影响面太大，新账号全部受影响。

1.2 默认认证插件的连锁影响

caching_sha2_password带来的不只是客户端兼容问题，还涉及密码传输方式。第一次用远程连接时，如果连接没有走SSL，服务端会要求客户端先通过RSA公钥交换来获取密码摘要。很多客户端默认不开启这个交互，于是连接卡住。

MySQL 8.0.4之后，连接器通常支持serverPubKey参数。以命令行客户端为例：

mysql -u dev -h 192.168.1.20 -p --server-public-key-path=/path/to/server/public_key.pem

但这要求你能拿到服务端的公钥文件，实际操作起来多一层麻烦。更省心的方式是确保客户端库版本足够新。以Python为例，使用pymysql需要1.0.2以上版本才完美支持caching_sha2_password，否则也要走老插件兼容路线。

实际项目里我的建议是：如果所有客户端都能升级，就保持默认插件；如果团队里有人用老工具，舒舒服服给单个账号降级为mysql_native_password即可。风险可控，操作简单，不影响全局。

2. 创号授权前，先理清这套权限模型

很多教程上来就让你敲命令，但遇到权限不生效、修改错位、误删数据时，根本原因还是对权限模型理解不够。MySQL的权限体系本质上是一张多层映射表，搞懂层级，才能精准控制账号能做什么、不能做什么。

MySQL权限记录在系统库mysql里的几张表中：

授权命令执行时，MySQL会把这些记录分散写入对应表。查看一个账号的权限时，实际上就是在查询这些表的联合信息。

2.1 权限粒度的四个层级

从大到小排列：

• 全局层：*.*，作用于所有数据库的所有对象。
• 数据库层：dbname.*，只作用于某个库。
• 表层：dbname.tablename，精确到单张表。
• 列层：dbname.tablename(column_name)，精确到字段。

“不受限版本”对应的就是全局层的ALL PRIVILEGES加GRANT OPTION。

权限匹配规则是从小到大叠加判断。简单说，MySQL试图在每一层都查找匹配记录，最后合并成有效权限集。需要注意的一点：REVOKE某些权限时，如果同时存在多层记录，结果可能不像预想那样“删干净”。比如你在全局层给了ALL，又在某个库上REVOKE DELETE，实际效果取决于权限记录的存储方式，执行前最好用SHOW GRANTS确认。

实战中，我发现很多问题出在“我以为只给了库权限，结果全局权限还在”。这是历史遗留权限叠加的结果。所以每次创建账号前，养成先查看已有权限的习惯：

SHOW GRANTS FOR 'dev'@'%';

2.2 权限类型与授权命令的本质

MySQL 8里的权限类型很多，常用的大概分几组：

数据操作类

• SELECT、INSERT、UPDATE、DELETE
• CREATE、DROP、ALTER、INDEX
• REFERENCES

管理操作类

• GRANT OPTION：允许把自己拥有的权限授予其他用户
• SUPER：管理类操作，如CHANGE MASTER TO、KILL线程
• PROCESS：查看其他用户线程信息
• RELOAD：执行FLUSH操作
• REPLICATION SLAVE、REPLICATION CLIENT：复制相关
• SHOW DATABASES：即使是空库也能在SHOW DATABASES中看到

MySQL 8新增/调整的权限

• BACKUP_ADMIN：备份管理
• SYSTEM_USER：系统用户，用于区分普通用户和系统账户
• CONNECTION_ADMIN、SET_USER_ID等

执行GRANT ALL PRIVILEGES ON *.* TO 'dev'@'%'时，MySQL会授予除GRANT OPTION以外的所有全局权限。所以想要“完全不受限”，还需要单独加上WITH GRANT OPTION：

GRANT ALL PRIVILEGES ON *.* TO 'dev'@'%' WITH GRANT OPTION;

顺带一提，ALL PRIVILEGES并不包含SUPER在早期版本里的全部语义。MySQL 8里部分管理操作被拆成更细的权限，所以严格意义上不存在“一个字面上的全权限”，但ALL PRIVILEGES WITH GRANT OPTION已经覆盖了日常开发运维的几乎全部需求。

3. 一步步实操：从建号到“不受限”授权

这里不搞抽象，给出一套可以直接照抄的完整命令，按顺序执行即可。假设你的MySQL 8跑在Linux服务器上，root账号能登录。

3.1 创建用户的正确姿势

CREATE USER 'dev'@'%' IDENTIFIED BY 'Dev@123456';

这行命令创建了一个允许从任意主机登录、密码为Dev@123456的用户。注意几个细节：

第一，'%'不代表“所有来源IP”。MySQL匹配用户时会先看精确IP再看通配符，'dev'@'192.168.1.%'优先级高于'dev'@'%'。如果你的系统里同时存在这两个账号，客户端IP来自192.168.1.x时匹配的是前者，来自其他IP才匹配后者。这会导致一种诡异现象：明明授权了'dev'@'%'，但从某台机器连接时权限像没生效一样，其实是被更精确的账号规则拦截了。

第二，密码不要用弱口令。MySQL 8默认开了validate_password插件的话，过于简单的密码会直接报错。如果只是临时环境想关掉这个校验，可以：

UNINSTALL COMPONENT 'file://component_validate_password';

但这个操作要谨慎，正式环境不建议关闭。更优雅的做法是设定一个达标的密码，比如大小写字母加数字加特殊字符、长度不低于8位。

第三，如果只想让用户从本机登录，'localhost'是更安全的选择；只有明确需要远程访问再用'%'或特定网段。

3.2 授权命令的完整用法

创建完用户后授权：

GRANT ALL PRIVILEGES ON *.* TO 'dev'@'%' WITH GRANT OPTION;

如果只想让某个库不受限，把*.*改成库名加.*：

GRANT ALL PRIVILEGES ON mydb.* TO 'dev'@'%';

如果想限制某些表或某些操作，可以精确到表名或列名：

GRANT SELECT, INSERT, UPDATE ON mydb.users TO 'dev'@'%'; GRANT SELECT (name, email) ON mydb.users TO 'dev'@'%';

最后那一句用在只需要读取特定字段的场景，减少不必要的数据暴露。“不受限版本”虽然用不上这种精细控制，但了解这些写法能帮你理解授权命令的通用结构，关键时刻能派上用场。

3.3 让授权立即生效与验证

在MySQL 8里，GRANT之后不需要FLUSH PRIVILEGES，权限已经实时生效。但有一个例外：如果你直接修改了mysql.user表里的记录（比如用UPDATE mysql.user SET ...），才需要FLUSH PRIVILEGES来刷新权限缓存。官方明确建议不要直接操作系统表，所有权限变更都走GRANT/REVOKE。

验证权限是否到位：

SHOW GRANTS FOR 'dev'@'%';

输出里能看到GRANT ALL PRIVILEGES ON *.* TO 'dev'@'%' WITH GRANT OPTION字样，代表全局高权限已生效。

再验证远程连接是否可用。在另一台机器上执行：

mysql -u dev -p -h 192.168.1.20

如果连接成功，说明账号、权限、网络、监听四项全部正常。

4. 想真正“不受限”，这几个隐藏关卡必须打通

MySQL层面把用户和权限建好，只完成了30%的工作。现实中我接过不少求助帖，标题都是“MySQL授权了还是连不上”，排查到最后，问题都出在MySQL服务监听地址、系统防火墙、云安全组，甚至是客户端工具的SSL设置上。

这一节汇总四个最容易挡路的隐藏关卡。

4.1 bind-address 与监听地址

MySQL默认只监听127.0.0.1，也就是只能本机连接。这种情况下，无论你的MySQL账号授权多么“不受限”，远程依然连不上。

检查监听地址：

netstat -tlnp | grep 3306

如果看到的是127.0.0.1:3306，说明服务只监听本地回环地址。修改方式是在/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf里的[mysqld]段下：

[mysqld] bind-address = 0.0.0.0

改完重启服务：

systemctl restart mysql

再查看监听地址，应该变成0.0.0.0:3306，表示服务已监听所有网卡。需要注意，bind-address = 0.0.0.0等于把MySQL暴露在网络上，配合强密码和安全组限制才有意义。如果不希望全部暴露，指定内网IP更稳妥，比如：

bind-address = 192.168.1.20

4.2 防火墙与安全组

服务监听改好之后，系统的防火墙可能是下一道坎。Linux上常见的是firewalld或ufw。

firewalld放行3306端口：

firewall-cmd --zone=public --add-port=3306/tcp --permanent firewall-cmd --reload

ufw放行：

ufw allow 3306/tcp

如果你用的是云服务器，还需要检查云安全组规则，而且这里有个顺序问题：云厂商的安全策略是独立于操作系统防火墙存在的，两者都得放行，缺一不可。

一个常用的排查思路：在客户端机器上用telnet测试端口是否可达。

telnet 192.168.1.20 3306

如果telnet能通但MySQL连不上，问题在MySQL权限或密码插件；如果telnet本身就超时，问题在网络层，和MySQL设置无关。

4.3 老客户端的密码插件兼容

这个问题前面提过，但值得单独拿一节来说，因为它在“不受限”授权场景里实在太常出现。

当你用Navicat 11、PHP 5.6的mysqli、或者某些Python老库连接MySQL 8时，会直接报：

Authentication plugin 'caching_sha2_password' cannot be loaded

应对手段有两种：

第一种，把单个用户的认证插件改成老格式：

ALTER USER 'dev'@'%' IDENTIFIED WITH mysql_native_password BY 'Dev@123456';

改完后登录立刻恢复正常，其他用户不受影响。

第二种，升级客户端。用最新版Navicat、最新版MySQL驱动、或者升级编程语言依赖库。推荐第二种，因为mysql_native_password虽然兼容性好，但在安全审计时可能被标记为弱认证。

我个人的习惯是开发环境直接改老插件省事，生产环境严格用新插件加新版客户端。如果你拿不准当前连接器版本支持情况，可以先执行STATUS命令查看版本，再对照官方文档判断。

4.4 时区、字符集与SSL的连带影响

还有一些隐蔽因素会让“授权成功但操作奇怪”。比如MySQL 8默认字符集是utf8mb4，如果客户端连接时指定了老字符集，某些中文数据会乱码。连接命令里可以显式指定：

mysql -u dev -p -h 192.168.1.20 --default-character-set=utf8mb4

再比如SSL连接问题。MySQL 8在部分发行版上默认开启了require_secure_transport，如果账号刚好也设置了REQUIRE SSL，客户端没走SSL就会连不上。查看账号的SSL要求：

SHOW CREATE USER 'dev'@'%';

输出里如果带REQUIRE SSL字样，而客户端又不想配SSL，可以去掉这个要求：

ALTER USER 'dev'@'%' REQUIRE NONE;

顺带说明，require_secure_transport系统变量和账号级的REQUIRE SSL是两个层面的东西，前者是服务端全局要求，后者是账号要求。如果不确定，优先在账号级别查看。

5. 撤销权限与删除用户：别让“不受限”变成永久权限

“不受限”配置一时爽，权限回收却需要清醒的头脑。开发环境里用完高权限账号，及时回收或删除应该是肌肉记忆。这一节把相关的操作细节讲透。

5.1 REVOKE 和 DROP USER 的用法

回收权限的基础语法：

REVOKE ALL PRIVILEGES ON *.* FROM 'dev'@'%'; REVOKE GRANT OPTION FROM 'dev'@'%';

第一条回收所有数据操作权限，第二条单独收回授权权限。两者结合才能把“高权限”完全抹掉。

如果不再需要这个账号：

DROP USER 'dev'@'%';

注意DROP USER会删掉账号及其权限记录，不可恢复，执行前务必确认。建议先查SHOW GRANTS，并确认没有业务连接正在使用该账号。

5.2 权限确认与遗留风险

回收权限后，用SHOW GRANTS确认结果：

SHOW GRANTS FOR 'dev'@'%';

如果账号还在但权限为空，输出会显示GRANT USAGE ON *.* TO ...，USAGE表示无特别权限。这一步容易被忽略，但恰恰是避免“回收失败”的关键验证。

另一个容易踩的坑是：REVOKE ALL ON *.*并不会删除mysql.db表里可能存在的库级记录。万一之前你在库级授权过，全局权限虽然回收了，库级权限可能依然残留。最稳妥的做法还是直接查SHOW GRANTS，而不是想当然。

5.3 误删用户后的紧急恢复

误删账号这种事，我一共遇到过两次。一次是自己手滑，一次是同事在生产库上执行了别人给的清理脚本。

恢复思路分三种：

• 如果开启了binlog且知道删除事务的大致时间，可以基于binlog反推恢复。
• 如果没有binlog，直接重建账号并重新授权。前提是你留存了该账号的授权清单，这就解释了为什么日常操作都要有记录。
• 如果授权清单丢失且账号关联的库比较复杂，可以从应用配置里反向推断它需要哪些权限。

最保险的做法是把这些账号信息记入运维文档，或者定期导出授权快照：

mysql -u root -p -e "SHOW GRANTS FOR 'dev'@'%';" > dev_grants_$(date +%F).sql

6. 踩坑实录：这些报错和“灵异现象”我都遇到过

最后这部分，整理实际工作中反复出现的几类问题。每一条都对照“原因定位 + 解决方案”来写，希望能帮你少走弯路。

6.1 Access denied 的三种常见形态

第一种：密码错报

ERROR 1045 (28000): Access denied for user 'dev'@'localhost'

这种情况最常见的原因是密码确实不对。需要特别提醒的是，在MySQL 8里你无法直接查看明文密码，重置就行：

ALTER USER 'dev'@'%' IDENTIFIED BY 'NewPass@123';

第二种：用户不存在

ERROR 1045 (28000): Access denied for user 'dev'@'192.168.1.10'

MySQL会明确告诉你来源IP。如果提示的IP是localhost但你想从远程登录，多半是DNS反解析或客户端没指定-h参数。检查连接命令里有没有带正确主机名或IP。

第三种：host匹配不上

ERROR 1130 (HY000): Host '192.168.1.10' is not allowed to connect to this MySQL server

明确是主机不匹配。意味着该IP不在'dev'@'%'覆盖范围。原因可能是存在更精确的账号记录，或者skip_name_resolve设置导致匹配逻辑变化。确认方法：

SELECT user, host FROM mysql.user WHERE user = 'dev';

6.2 授权后连不上远程的完整排查链路

遇到“授权成功但远程连不上”，按顺序检查这四个环节：

1. 端口是否可达：telnet <ip> 3306。
2. MySQL是否监听外网地址：netstat -tlnp | grep 3306。
3. 账号host是否覆盖来源IP：SELECT user, host FROM mysql.user。
4. 密码插件是否兼容：尝试用mysql_native_password重置密码后重连。

这个排查顺序是我反复验证过的。很多人一开始就去改MySQL权限配置，其实大部分问题出在前两层网络配置上。有一次帮人排查了半天，最后发现是云安全组里根本没放行3306，MySQL权限改得再花都没用。

6.3 密码策略插件引发的连锁问题

MySQL 8默认可能开启密码校验组件。当你执行：

CREATE USER 'dev'@'%' IDENTIFIED BY '123456';

可能会报：

ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

处理方式不只是关掉插件，也可以调整策略等级：

SET GLOBAL validate_password.policy = LOW; SET GLOBAL validate_password.length = 6;

MySQL 8里组件名称带点号，和5.7的变量名写法不同。如果你习惯用validate_password_policy这种旧写法，会直接报变量不存在。

6.4 大小写、引号与分号：命令执行前的最后防线

SQL语句里用户名和数据库名在Linux上区分大小写。'DEV'和'dev'是两个不同用户。数据库名如果在创建时用了大写，授权时写小写就对应不上。建议统一用小写，避免文字游戏。

另外，MySQL命令行里字符串必须带引号，而且大多数情况下用单引号。如果你写：

GRANT ALL PRIVILEGES ON *.* TO dev@%;

不带引号会语法报错。人眼很难看出来，因为报错信息可能指向dev附近。这时候把语句拆成CREATE USER和GRANT分开执行，更容易定位。

最后再分享两个实操建议

创建“不受限”账号本身不难，难的是配套的规范意识。我个人的操作习惯是：每次创建账号后，立即把授权语句保存到项目文档里；每次回收权限后，顺手执行SHOW GRANTS验证结果。这样即使几个月后有人问“这个账号怎么来的”，也能三分钟讲清楚来龙去脉。

另外，用'%'做host要格外谨慎。开发环境图省事可以理解，但生产环境尽量精确到网段或具体IP。万一MySQL端口被扫描到，一个'%'加上强密码还能扛一扛，如果密码也弱，就是给别人留门。真需要跨环境的“不受限”账号，建议定期轮换密码，并配合云安全组限制来源IP，做到“账号权限最大、网络入口最小”的折中平衡。

MySQL 8的用户和权限体系整体比5.7干净，只要习惯“先建用户、再授权、后验证”这个节奏，就不会翻车。希望这篇能帮你在“不受限”和“安全可控”之间找到属于自己的操作套路。