MySQL用户管理与权限控制实战：从GRANT语法到最小权限落地

做数据库运维这几年，我接手过不少MySQL实例，也处理过各种权限混乱引发的线上事故。比如曾经有个业务账号因为权限过大，误删了一张核心配置表，等发现时只能靠备份恢复，那一次直接让大家盯了半宿。后来我把用户管理和权限规划理顺之后，这类问题几乎销声匿迹。MySQL的用户管理不仅仅是create user和grant两句SQL那么简单，它背后是一整套访问控制模型，牵扯到连接阶段怎么校验身份、执行阶段怎么校验操作、远程主机怎么放开、SSL连接怎么配置、密码策略怎么落地。这篇文章我想把自己实际用下来的用户管理经验完整摊开来讲，包括权限表结构、授权语法、最小权限划分、经典坑位和排查思路，希望能帮你在第一次搭建或日常维护时少走弯路。

我默认你手头已经装好了MySQL 5.7或8.0，对基础SQL有概念，但还没系统梳理过用户权限这块。如果你连root密码都没搞定，可以参考后文第5章的应急恢复步骤；如果你正在为“授权了却连不上”“改完权限不生效”这类问题抓狂，可以直接跳到对应章节。全文内容来自我自己的实操经验，没有达标的官方文档翻译腔，遇到参数我会把计算和判断逻辑也讲清楚。

1. MySQL用户管理，到底在管什么？

很多人刚接触MySQL时，只知道用root账号一把梭，建库建表、查数据、删数据全都用同一个超级账号。这在本地测试环境没什么问题，但一到项目联调、生产部署、多人协作，就立刻暴露出风险：业务代码里不小心埋了删库语句，权限过大直接执行；同事之间共用root账号，出了事故根本分不清是谁做的；开发环境连接串泄露，攻击者拿到账密直接把整库拖走。

MySQL用户管理的核心，就是把“谁能在哪台主机上、用哪个账号、对哪些库表、执行哪些操作”这四件事严格定义下来。本质上它做的是访问控制的四个维度：

• 身份识别：确认连接者是不是合法用户，密码是否匹配，账号是否被锁定。
• 来源限定：限制该账号只能从某个IP段、某台服务器或者任意主机发起连接。
• 对象范围：限定用户只能访问指定的库、表，甚至某些列。
• 操作级别：区分只读、读写、建表、删表、管理权限等不同能力。

从运维角度讲，这套体系最大的价值不是“防止外部入侵”，而是“降低内部误操作和权限滥用的冲击半径”。一次误执行drop table，如果账号只有select权限，这条语句根本不会被服务器受理；攻击者即使拿到弱业务账号，也没法对全局配置做手脚。这就是最小权限原则的威力。

从架构演进角度来看，用户管理也是从单机软件走向多人协作、走向云化的必经门槛。你不管是自建机房里的MySQL，还是云RDS实例，这套模型都是一样的，只是控制台帮你封装了部分操作而已。把底层机制吃透，后面无论用什么端到端工具，都只是换了个界面而已。

2. 用户体系与权限模型拆解

2.1 用户账号到底存在哪里？

MySQL不是把用户信息放在某个神秘文件里，而是存在系统自带的mysql库里。你登录后执行这样一句就能看全：

SELECT user, host, plugin, authentication_string, password_lifetime, account_locked FROM mysql.user;

mysql.user表是用户管理的总账本，每一行代表一个“IP来源+账号名”的登录组合。注意这里host字段很多时候被忽略，但它恰恰是安全设计的关键。比如'dev'@'localhost'和'dev'@'%'是两个完全不同的账号，可以有不同的密码和不同的权限范围，即使user字段都叫dev。我见过有人新建了'myapp'@'%'，但真正连接时源IP走的是内网段，匹配的却是'myapp'@'10.0.0.%'，两边权限不一致，于是出现“有时候能连有时候不能连”的诡异现象。

随着MySQL 8.0的普及，mysql.user里的authentication_string存的是哈希后的凭证，而不是明文密码。不同插件对密码的处理方式也不同，caching_sha2_password是8.0默认插件，比5.7时代的mysql_native_password要安全，但老客户端不兼容。你在处理“为什么新版MySQL连不上”的问题时，第一嫌疑就是认证插件不兼容。

除了mysql.user，还有一组配套的授权表。mysql.db记录库级别权限，mysql.tables_priv记录表级别权限，mysql.columns_priv记录列级别权限，mysql.procs_priv记录存储过程和函数权限。这么多张表共同构成了一个层层收窄的权限漏斗。简单说，一个用户的最终权限，就是全局、库、表、列这四级权限的并集，但具体执行时按“从具体到全局”的优先级判断。

2.2 权限类型与权限层级

MySQL的权限按管理范围从小到大可以分成四层，这在分配时非常重要：

• 全局层级：作用在整个MySQL实例，比如CREATE USER、PROCESS、SUPER、SHUTDOWN、SELECT（如果授权在*.*上就是针对所有库所有表）。这类权限存储在mysql.user表。
• 库层级：作用于指定数据库内所有表，比如对某个库的所有表进行SELECT、INSERT、UPDATE、DELETE。存储在mysql.db表。
• 表层级：作用于指定表，比如只能查询订单表，不能动用户表。存储在mysql.tables_priv表。
• 列层级：作用于表的指定列，比如只能查看员工的姓名列，不能查看薪资列。存储在mysql.columns_priv表。

日常用得最多的是全局和库级别。表级别偶尔用于敏感表隔离，列级别在业务库中确实用得少，但你可以通过它实现“部分字段脱敏”效果，比如财务表中只允许业务账号读非金额字段。

从权限动作来看，常见权限大致可以分三组：

• 数据操作权限：SELECT、INSERT、UPDATE、DELETE，这四件套是DML的基本盘。
• 结构操作权限：CREATE、ALTER、DROP、INDEX、CREATE VIEW、ALTER ROUTINE等，这类权限影响表结构和存储逻辑，一般只给开发负责人或DBA。
• 管理权限：CREATE USER、GRANT OPTION、SUPER、PROCESS、RELOAD、SHUTDOWN，这类权限直接威胁整个实例安全，绝不轻易下发。

你如果抓到一把ALL PRIVILEGES授权，要明白它不是“所有权限”，而是“除GRANT OPTION之外当前层级的所有权限”。ALL PRIVILEGES只有在*.*上才意味着接近超级管理员，在某个库上授权则只对该库生效。这个区别常被误解，也常被滥用。

2.3 权限生效机制：为什么改了不生效？

很多人第一次执行grant之后发现权限没立刻生效，第一反应是重启MySQL。其实MySQL的授权表不是每执行一条SQL就去底层读取一遍的，它有一层内存缓存。常规的grant、revoke语句会显式刷新权限缓存，所以不需要额外处理。但是，如果你绕过grant/revoke，直接执行UPDATE/INSERT/DELETE操作mysql.user这些系统表来改权限，那就必须手动执行FLUSH PRIVILEGES，否则缓存里的旧权限会一直赖着不走。

另外有个细节：新建立的连接在连接握手阶段就已经完成权限判定，之后执行中不会再动态检查账号是否新增了权限。如果你在会话A中给会话B所用的账号授权，B要等到下一次重新连接才会真正拿到新权限。同理，在线程池或连接池场景里，如果连接一直被复用，权限变更可能要等连接释放重建后才生效。排查“我明明授权了，为什么还是报错？”时，先问一句：这条会话是授权之前建立的还是之后建立的？

具体到权限校验流程，MySQL对一条语句的验证顺序大致是：先看全局表，如果全局权限满足就直接放行；如果不满足，再看库级、表级、列级。这个先后顺序意味着全局层的DENY并不能阻挡库层级的ALLOW。所以当你把一个用户从全局删掉所有权限，但忘记回收库级权限时，他依然可以访问那个库的数据。清理账号权限时，要一层层全部撤干净。

2.4 默认账号与初始安全策略

MySQL安装完成后，默认一定有一个root账号，但它的host通常是localhost，也就是说只能从本机登录。很多人问“为什么远程连不上root”，答案多半是root只在localhost，或者被bind-address限制了监听地址。这个默认行为在MySQL 8.0里更严格：安装时初始化日志里会生成一个临时密码，如果你用的是Linux的rpm方式安装，临时密码一般记在/var/log/mysqld.log里。第一次登录它要求你立刻改密码，否则无法执行任何语句。

除了root，MySQL 8.0里默认还可能存在mysql.infoschema、mysql.session、mysql.sys等系统账号，这些是内部组件使用的，正常情况下不需要也不应该动它们。我在检查用户列表时，发现有的人误删了这些系统账号，导致实例状态异常，需要通过初始化重建。安全建议是：定期审计mysql.user表，清掉那些长期不用的历史账号，锁定可疑的匿名账号。你可以在登录后执行这条看看到底有哪些“看起来不太对劲”的账号：

SELECT user, host, account_locked FROM mysql.user WHERE account_locked='N';

3. 用户管理实操：创建、授权、改密、删除

3.1 创建用户的基础语法和参数

创建用户最标准的姿势是CREATE USER，不推荐直接往mysql.user表里INSERT。官方语法看起来长，但核心结构并没有想象中复杂：

CREATE USER 'app_user'@'192.168.1.%' IDENTIFIED BY 'StrongPass@123' PASSWORD EXPIRE INTERVAL 90 DAY ACCOUNT UNLOCK;

这段SQL做了四件事：指定账号叫app_user，限定来源网段是192.168.1.0/24，设置初始密码且要求每90天更换一次，保证账号默认不锁定。其中IDENTIFIED BY后面不跟PASSWORD关键字，直接写明文即可，MySQL会把密码经过哈希后存入mysql.user，不会明文落库。

密码策略在MySQL 8.0里默认是强制校验的，validate_password组件会让弱密码直接报错，这既是保护也是折磨。遇到“密码明明很复杂还是报错”的情况，多半是长度或大小写组合没达到组件要求。可以先执行SHOW VARIABLES LIKE 'validate_password%';查看当前策略，再按需调整。

创建用户之后，他还什么都干不了，连登录后看个库列表都无权限。很多人在这就会疑惑，其实逻辑很简单：CREATE USER只负责创建身份，不负责分配能力，能力需要授权语句来赋予。

3.2 授权语句与权限细化

授权用GRANT。实际工作中，我习惯把授权分成三个层次来写：

• 只读账号：只给SELECT。
• 读写账号：给SELECT、INSERT、UPDATE、DELETE，偶尔加EXECUTE。
• 结构变更账号：在读写基础上加CREATE、ALTER、DROP、INDEX，但只在具体业务库上授权。

比如给业务只读账号授权：

GRANT SELECT ON order_db.* TO 'report_user'@'192.168.1.%';

给某特定表开读写权限：

GRANT SELECT, INSERT, UPDATE, DELETE ON order_db.t_order TO 'write_user'@'192.168.1.%';

给负责DDL的账号授权：

GRANT ALL PRIVILEGES ON order_db.* TO 'dba_user'@'localhost';

这里的order_db.*就是指这个数据库下所有表，不会影响其他库。授权后不需要FLUSH PRIVILEGES，GRANT语句会自动刷新权限缓存。但要注意，GRANT OPTION权限不要随便给。一旦账号拥有了GRANT OPTION，它就能把自己拥有的权限再转授给别人，等于把权限扩散的主动权交给了业务方，这在生产环境是非常危险的一件事。

还有一种更精细的授权方式：授权时可以同时指定WITH MAX_QUERIES_PER_HOUR之类限制，例如：

GRANT SELECT ON order_db.* TO 'limited_user'@'%' WITH MAX_QUERIES_PER_HOUR 600;

这类资源限制参数在共享机房或对外API场景中挺好用，但普通业务库很少用，写在这里是提醒你确实有这层手段。

3.3 查看权限与核对授权

想看某个账号都有哪些权限，用SHOW GRANTS：

SHOW GRANTS FOR 'app_user'@'192.168.1.%';

这条命令会把该账号在所有层级上的授权逐条列出来。我做权限审计时，会批量跑一段组合查询，把user、db、tables_priv、columns_priv四张关键表联表摸一遍底：

SELECT u.user, u.host, IFNULL(d.db, '*') AS db, IFNULL(t.table_name, '*') AS tbl, IFNULL(c.column_name, '*') AS col FROM mysql.user u LEFT JOIN mysql.db d ON d.user = u.user AND d.host = u.host LEFT JOIN mysql.tables_priv t ON t.user = u.user AND t.host = u.host LEFT JOIN mysql.columns_priv c ON c.user = u.user AND c.host = u.host WHERE u.user NOT LIKE 'mysql.%';

这只是一个粗糙版扫描，实际字段比上面复杂，但方向就是这样：从总账到明细，一层一层核对，确保没有越权授权。权限核对我一般放在每次版本上线前和日常巡检中，十分钟就能跑完，收益非常高。

3.4 撤销权限与删除用户

权限发出去简单，收回来就要细心了。收回权限用REVOKE，语法和GRANT基本对称：

REVOKE SELECT, INSERT ON order_db.* FROM 'app_user'@'192.168.1.%';

想收得干干净净，需要把全局、库、表、列各级权限挨个清一遍。如果嫌麻烦，更果断的做法是直接删账号：

DROP USER 'app_user'@'192.168.1.%';

DROP USER执行后，mysql.user里对应记录就没了，mysql.db、mysql.tables_priv等关联权限记录一般也会一并清理，但前提是你用账号全称，包括host部分。我只写'app_user'不写host也可以删，但如果同时存在'app_user'@'localhost'和'app_user'@'%'，只写前半截可能会报错或只删一个。稳妥起见，每次操作都带上host。生产环境删账号之前务必备份mysql.user全表或至少导出该账号的SHOW GRANTS记录，防止后续业务发现还有依赖时无据可查。

3.5 修改密码与密码过期策略

改密码有三种常见方式，比较容易混：

• SET PASSWORD FOR '账号'@'host' = '新密码'，这是最直观的写法，8.0里还可以配合IDENTIFIED BY。
• ALTER USER '账号'@'host' IDENTIFIED BY '新密码'，这是8.0推荐写法，支持更多附加选项，比如锁定状态、密码过期时间。
• 直接UPDATE mysql.user，不推荐，容易出缓存不一致问题，必须FLUSH。

我的日常推荐是ALTER USER，因为它在同一个语句里能一并管理密码、过期策略和账号状态：

ALTER USER 'app_user'@'192.168.1.%' IDENTIFIED BY 'NewStrongPass@456' PASSWORD EXPIRE INTERVAL 90 DAY;

MySQL 8.0默认密码过期策略由default_password_lifetime控制，默认值可能是0，表示不过期。如果你想全局强制90天改一次密码，可以设置：

SET PERSIST default_password_lifetime = 90;

这里SET PERSIST既改运行时变量，又写入mysqld-auto.cnf，重启后依然生效。注意，如果你开启密码过期策略，业务方会突然收到“Your password has expired”报错，这不是故障，而是策略生效。要允许用户通过ALTER USER重新设定新密码，通常连接后执行一条修改密码语句即可恢复。

4. 实战场景：远程访问、最小权限、只读用户

4.1 远程访问的正确配置

远程访问是用户管理需求里出现频率最高的场景。多数人遇到“远程连不上”的第一反应是防火墙或网络不通，实际排查顺序应该是：先确认MySQL实例有没有监听外部地址，再确认用户host是否允许远程来源，最后才是防火墙和安全组。

MySQL默认的bind-address如果是127.0.0.1，那它只监听本地回环地址，外部机器根本连不到3306端口。要允许远程访问，需要把bind-address改成0.0.0.0或者具体的内网IP，然后重启实例。这一步改了之后不等于就能连上，因为MySQL的访问控制还要求用户表里的host允许对应来源。比如：

CREATE USER 'remote_user'@'192.168.8.%' IDENTIFIED BY 'RemotePass@123'; GRANT SELECT ON order_db.* TO 'remote_user'@'192.168.8.%';

这样的话，只有192.168.8.x网段的机器能连。这种按网段收口的方式比开放'%'要安全得多。如果非要开放任意主机，我建议不要直接用root或拥有高权限的账号，而是新开一个低权限账号，并且确保只开放必要端口。

远程访问还有一个和用户管理强相关内容：认证插件兼容性。MySQL 8.0默认的caching_sha2_password在旧版Navicat、老版本JDBC驱动下可能报Authentication plugin不支持，报错是“Authentication plugin 'caching_sha2_password' cannot be loaded”。遇到这种情况，有两个可选方案：一是给该用户改成mysql_native_password插件，兼容性最好：

ALTER USER 'remote_user'@'192.168.8.%' IDENTIFIED WITH mysql_native_password BY 'RemotePass@123';

二是升级客户端驱动到支持caching_sha2_password的版本。我比较推荐第二条，因为native_password插件在8.0里已被标记为废弃，长期看还是要迁移到新插件。但如果手头有旧系统实在迁不动，临时的native方案也能跑，只是要记得以后找机会升级。

4.2 只读账号与最小权限落地

最小权限原则说起来容易，落地时最常踩的坑是“先给ALL，后发现问题再回收”，实际已经晚了。正确的做法是在账号创建之初就把权限边界定死。比如给数据分析师建只读账号：

CREATE USER 'bi_user'@'%' IDENTIFIED BY 'BiRead@123'; GRANT SELECT ON warehouse_db.* TO 'bi_user'@'%';

这样他只能查询warehouse_db下所有表，不能插入、更新、删除，更不能建表改表。如果某些报表库还有存储过程，他会遇到调用存储过程时权限不足，这时可以单独授权EXECUTE：

GRANT EXECUTE ON warehouse_db.* TO 'bi_user'@'%';

只读账号在8.0里还有一层坑：如果不加说明，有些工具在打开表结构时会尝试获取元数据锁，一旦账号缺乏LOCK TABLES权限，部分老版本客户端会报错。多数情况下SELECT权限够用了，不用额外给LOCK TABLES。如果特定报表工具非要加锁能力，再加也不迟，但尽量不要给“所有库的LOCK TABLES”。

另外，最容易被忽略的是information_schema和performance_schema。即使账号没有这些库的授权，MySQL允许所有用户查看部分元数据，这是正常机制。如果担心库名泄露，只能靠数据库层面隔离，不能靠用户管理堵死。

4.3 多环境权限划分实战

我维护的项目通常有dev、test、prod三套环境。dev环境大家都能连，账号放宽一点；test环境只给自动化测试用的专用账号；prod环境账号必须走审批，权限收得非常紧。这套流程的背后就是用户管理在支撑。

比如开发环境的建库建表权限可以这样给：

CREATE USER 'dev_leader'@'10.0.0.%' IDENTIFIED BY 'DevPass@123'; GRANT ALL PRIVILEGES ON dev_db.* TO 'dev_leader'@'10.0.0.%';

测试账号给读写权限，但去掉DROP，防止测试脚本误删表：

CREATE USER 'tester'@'10.0.1.%' IDENTIFIED BY 'TestPass@123'; GRANT SELECT, INSERT, UPDATE, DELETE ON test_db.* TO 'tester'@'10.0.1.%';

生产环境的业务账号，通常只给某一个库的CRUD，而且这个库名在授权时直接写死：

CREATE USER 'prod_app'@'192.168.10.%' IDENTIFIED BY 'ProdPass@123'; GRANT SELECT, INSERT, UPDATE, DELETE ON prod_db.* TO 'prod_app'@'192.168.10.%';

这些账号分开建之后，还要配上连接串的区分管理。我在实际项目里见过最乱的场景，是开发环境拿着prod账号连接，一执行本地测试就把生产数据当成废数据清掉了。后来强制按环境建账号、按环境配置连接串，同时定期通过information_schema.processlist检查来源账号，才把这类事故几率压下去。

4.4 常见运维账号模板

除了业务账号和开发账号，日常运维可能还需要两类特殊账号：

• 只读监控账号：给监控系统用的，只需要全局SELECT和SHOW DATABASES，大概授权长这样：

CREATE USER 'monitor'@'127.0.0.1' IDENTIFIED BY 'Monitor@123'; GRANT SELECT, SHOW DATABASES, PROCESS ON *.* TO 'monitor'@'127.0.0.1';

PROCESS权限可以让监控工具看到所有线程的SQL语句，方便排查慢查询和阻塞，又不会给过于危险的SUPER权限。监控账号建议限定为localhost或内网监控机IP，不要开放全网络。

• 备份操作账号：备份工具如mysqldump需要至少SELECT、SHOW VIEW、LOCK TABLES、RELOAD权限：

CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'Backup@123'; GRANT SELECT, SHOW VIEW, LOCK TABLES, RELOAD ON *.* TO 'backup_user'@'localhost';

RELOAD权限用于执行FLUSH TABLES WITH READ LOCK，让mysqldump获得一致性快照。少了RELOAD，逻辑备份在写入时可能拿不到全局读锁，出现备份不一致甚至报错。备份账号别乱加SUPER，备份不需要SUPER。

5. 常见问题与排查实录

5.1 root密码忘了怎么办

这是每个MySQL使用者都至少遇到一次的事。新版MySQL 5.7和8.0找回密码的逻辑基本相同，核心是跳过授权表启动，把权限校验临时关掉，然后进入实例重置密码。

具体步骤：

1. 停掉MySQL服务，注意不同系统命令不一样，systemd环境一般是systemctl stop mysqld。
2. 修改MySQL配置文件，比如/etc/my.cnf，在[mysqld]段里加上skip-grant-tables。
3. 启动MySQL服务，这时的MySQL不检查任何账号权限，任何人均可免密登录。
4. 执行mysql -u root进入命令行，然后执行：

FLUSH PRIVILEGES; ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewStrongPass@123';

5. 改完后把配置文件里的skip-grant-tables删掉，重启MySQL服务。

这里有一个很关键的小细节：在skip-grant-tables模式下，直接ALTER USER有时会报错，因为认证插件和权限系统没完全初始化。所以第一步先执行FLUSH PRIVILEGES让权限系统重新加载，再执行ALTER USER就顺畅多了。整个过程操作完，记得马上检查mysql.user表里root账号的host，如果是localhost就只能本机连，还要远程请再建一个专门远程账号。

极端情况下，如果连配置文件都改不了，还可以用init-file参数指定一个包含重置密码SQL的文件启动，但skip-grant-tables方案简单直接，适合多数场景。

5.2 权限修改后不生效，问题出在哪

我排查这类问题通常按三条线走：

第一线是缓存。如果权限是通过GRANT/REVOKE修改的，理论上自动生效，但连接池中的旧连接不感知新权限。遇到权限变更后业务还在用旧连接，要么等连接池回收，要么手动重连。第二线是host匹配。你授权给了'user'@'192.168.1.%'，但业务机器实际出口IP不在这个网段，MySQL会当作另一个未知账号拒绝连接或当作匿名用户处理。第三线是权限层级冲突。全局层没有权限，库层却给了权限，这类叠加容易造成“部分能访问部分不能”的错觉。

我见过一个典型案例：业务反馈刚申请的只读账号连是能连上，但查询时提示没有权限。我一看SHOW GRANTS，确实给了SELECT，再一看mysql.db表，发现该账号还有一条对目标库的DELETE授权记录。原来历史遗留的旧授权没有回收干净，新授权和旧授权叠加后，客户端在尝试某个操作时反而触发了奇怪的权限判定。处理方式就是先把所有层级授权收干净，再按最小权限重新发放。

5.3 远程连接被拒绝，与host限制的纠缠

报错信息通常会写“Host 'x.x.x.x' is not allowed to connect to this MySQL server”。这句话的意思很明确，MySQL连接阶段就把这个来源IP挡掉了。解决办法不外乎两种：一是把这个IP段加进账号的允许host里，二是把账号host放宽。我建议用第一种，而且格式可以写得很细。比如访问方IP是192.168.8.15，可以创建账号时直接写死单个IP：

CREATE USER 'single_user'@'192.168.8.15' IDENTIFIED BY 'Single@123';

如果有多台机器要连，又不想逐个加，可以按网段放开：

CREATE USER 'segment_user'@'192.168.8.0/255.255.255.0' IDENTIFIED BY 'Segment@123';

注意MySQL的host匹配支持通配符%和_，也支持IP网段写法，但IP网段这里的掩码要写成完整形式，不是CIDR的/24简写。这是我踩过的坑，配置时写成'192.168.8.0/24'不会生效。

排查顺序我再强调一遍：先确认实例是不是只监听了localhost，再确认用户host允许范围，最后看防火墙和云安全组。很多人第一步都没查就跑去安全组折腾半小时，纯属浪费时间。

5.4 SSL连接错误与认证相关

热词里有一个“mysql ssl连接错误”，这个在用户管理话题里也常被提到。MySQL 8.0默认自动生成SSL证书，客户端和服务器握手时会协商是否启用TLS。如果你在授权语句里没指定REQUIRE SSL，用户默认可以用非SSL连接，也可以走SSL。报SSL错误最典型的原因有几种：

• 客户端连接串里写死了ssl-mode=REQUIRE或VERIFY_CA，但服务端证书链不受信任。
• 服务端SSL配置有问题，证书文件路径错误，导致TLS握手失败。
• 客户端驱动不支持服务端选用的SSL版本或密码套件。

从用户管理角度，你可以强制某账号必须使用SSL连接，比如：

CREATE USER 'secure_user'@'%' IDENTIFIED BY 'Secure@123' REQUIRE SSL;

如果这个账号尝试非SSL连接，会被直接拒绝，报错提示“Access denied for user ... using password: NO”或类似TLS相关的错误。反过来，如果你希望排查SSL握手异常，可以先临时取消REQUIRE SSL要求，确认是否是SSL层导致的问题：

ALTER USER 'secure_user'@'%' IDENTIFIED BY 'Secure@123';

这里把REQUIRE SSL去掉后，客户端可以用非SSL方式连接，方便定位网络或证书层问题。但生产环境如果要求传输加密，还是要保留REQUIRE SSL，并确保证书在客户端可信。

5.5 Navicat连接失败的若干原因

Navicat几乎是Windows环境里用得最多的MySQL图形客户端之一。连接失败时，Navicat报的错五花八门，最常见的几条我都遇到过：

• 报“Client does not support authentication protocol requested by server”。这就是前面提到的认证插件不兼容，8.0默认caching_sha2_password，老版本Navicat不认。解决办法就是ALTER USER换成mysql_native_password，或者升级Navicat到支持新插件的版本。
• 报“Access denied for user ...”。账号密码错误或者host不允许，按5.3的思路排查。
• 报“Can't connect to MySQL server on ... (10061)”。服务端端口没监听、防火墙拦截、bind-address限制。先确认mysql服务在跑，再确认监听地址是0.0.0.0而不是127.0.0.1。

我习惯新建连接前，先在命令行用mysql客户端做一次连通性测试，绕开图形界面，能快速区分是网络问题还是账号权限问题。例如：

mysql -h 192.168.8.10 -P 3306 -u navicat_user -p

如果命令行能进，Navicat不行，问题大概率出在Navicat配置或驱动版本上。

5.6 账号列表中的异常用户与安全审计

数据库里的账号也可能像服务器上的僵尸账户一样，长时间不清理，慢慢堆积出一堆高危入口。我在做审计时重点关注三类账号：

• 空密码账号。grant语句写错或者创建时根本没指定密码，可能出现密码为空的账号。
• host='%'且拥有高权限的账号。这类账号对全网开放，是拖库风险的主要来源。
• 长期不用的历史账号。登录记录里几个月都没见过，也没人说得清是干什么用的，直接锁定或删除。

查询语句可以这样写：

SELECT user, host, authentication_string='' AS empty_password, account_locked FROM mysql.user;

发现空密码账号，立刻锁定：

ALTER USER 'legacy_user'@'%' ACCOUNT LOCK;

等确认没人使用再DROP USER。这种先锁定后删除的节奏，比直接删除更安全，避免误删后业务半夜打你电话。

顺便提一句，有些人在清理用户时会把mysql.user表里所有不认识的系统账号全删了，这是很危险的动作。mysql.sys、mysql.session这类账号是MySQL内部组件运行所依赖的，删掉后可能造成实例行为异常。审计时应该把系统内置账号排除在外，只处理自定义的业务账号。

5.7 问题速查表

我把高频问题按现象、原因、处理方式整理成一个速查表，方便你遇到事时快速定位：

这张表不能覆盖所有场景，但已经能解决日常八成以上的用户管理问题。遇到表里没有的，建议优先看MySQL错误日志，日志里通常记录了最底层的拒绝原因，比盲目试错高效得多。

6. 几个值得坚持的习惯

文章写到这里，用户管理的基础知识、实操步骤和常见坑位都过了一遍。最后分享几个我自己坚持很久的小习惯。

第一个习惯是每个账号都写好备注。MySQL的user表没有专门的备注字段，但CREATE USER时可以用COMMENT语法加注释。我在创建账号时总会顺手加一句这是给谁用的、用于什么环境：

CREATE USER 'report_user'@'192.168.8.%' IDENTIFIED BY 'Report@123' COMMENT 'data analysis read-only account, created 2025-01-10, owner: zhang';

这样一来，半年后翻mysql.user才不会看着一堆账号发懵。

第二个习惯是权限变更走固定流程。我不会因为“临时加个权限”就直接grant，而是先查SHOW GRANTS记录当前状态，再执行变更，最后再次SHOW GRANTS确认。如果是在生产环境，还会先把变更语句复制到变更记录里。这样出问题可以快速回滚，回滚的方式就是反方向执行一遍REVOKE。

第三个习惯是定期做权限审计。我一般每个月用脚本扫一遍mysql.user、mysql.db、mysql.tables_priv，把高权限账号清单发给对应的负责人确认，超过三个月没人认领的账号直接锁定。这套流程看起来不起眼，但真正出事时能救命的都是这些平时攒下来的规矩。

我在实际处理过几起权限事故之后，最大的体会是：MySQL用户管理不是DBA的专属工作，写SQL的人、管服务器的人、做数据分析的人，都应该对这套权限模型有基本认识。你未必需要记住每一条GRANT语法，但至少要明白“账号不等于权限”“host限定比密码更关键”“最小权限是保护自己的第一道防线”这几个底层逻辑。数据库权限这类事，平时多花十分钟做规划，比事后花一晚上做恢复划算太多。