云海天狼做MySQL运维这些年，我有个越来越强烈的感受：用户管理这块内容，看起来每个教程里都是一小章，真到生产环境里却是翻车重灾区。这篇文章就把我在实际项目中反复用到、也反复踩过的MySQL用户管理经验完整梳理一遍，含金量集中在用户与权限模型、账号生命周期操作、授权粒度设计，以及忘记密码、连接失败这些高频故障的真实排查过程。无论你是刚入门的学习者，还是在生产环境里维护数据库的开发和运维，都应该能从里面找到能直接落地的东西。
1. 用户管理的核心难点：账号概念不是你以为的那回事
1.1 MySQL里的“用户”，实际上是用户加来源主机
大多数人对数据库用户的最初理解，就是“一个用户名对应一套密码”。但MySQL的设计比这个多一个维度：登录身份由 user 和 host 共同组成，也就是 '用户名'@'主机'。同一个用户名，来源主机不同，就是完全不同的两个账号，甚至可以有完全不同的密码和权限。
我举个例子。服务器上有这两个账号：
sql复制'app'@'localhost'
'app'@'%'
localhost 那个可能是我本机登录用的管理员账号，% 那个是业务服务远程连接用的账号。要修改其中一个的密码，必须带着完整的 host 指定，只写 app 去改，命令可能直接报错，或者改到你不期望的那个账号上。新手最常见的困惑就在这里：为什么我明明给某个用户设置了新密码，但用旧密码还能登录？十有八九是存在两个同名但 host 不同的账号，你改的并不是业务实际连库时命中的那个。
这种设计从MySQL早期就存在，目的是便于针对不同来源主机做差异化授权。比如运维段内网可以放宽权限，公网来源就必须收紧。搞清楚了这层逻辑，后面所有的授权和管理操作才不容易糊。
1.2 用户和权限其实是两套独立体系
很多教程把用户管理和权限管理揉在一起讲，导致不少人对两者的边界不清晰。MySQL里账号体系归账号体系，授权体系归授权体系，它们可以分开操作。
账号本身只负责“能不能连上”，它包含用户名、来源主机、认证插件、密码、是否锁定、密码过期策略这些信息。而“能对哪些库表执行哪些SQL”，属于授权体系，由MySQL的权限系统单独管理。
这样的拆分带来了一个实际好处：你可以预先创建好一批账号，先不让它们登录任何业务库，等人来申请并审批通过后再单独授权，也能在账号保持不变的情况下，随时调整它的权限边界，做权限回收时不需要动账号本身。理解这一点，对后面设计权限申请流程很有帮助。
MySQL的权限范围按照从大到小可以分成：全局权限、库级权限、表级权限、列级权限，以及存储过程和函数级别的权限。每个层级对应不同的系统授权表：
| 权限范围 | 控制数据表 | 常见授权语法示例 |
|---|---|---|
| 全局 | mysql.user | GRANT SELECT ON . TO 'u'@'h' |
| 数据库 | mysql.db | GRANT SELECT ON db1.* TO 'u'@'h' |
| 表 | mysql.tables_priv | GRANT SELECT ON db1.t1 TO 'u'@'h' |
| 列 | mysql.columns_priv | GRANT SELECT(col1) ON db1.t1 TO 'u'@'h' |
| 存储过程/函数 | mysql.procs_priv | GRANT EXECUTE ON PROCEDURE db1.p1 TO 'u'@'h' |
权限是按范围“叠加生效”的。查询一条数据时，MySQL会先把全局权限、库级权限、表级权限全部整合起来，再判断你是否有权执行相应的操作。这带来的含义是：如果你在全局层面对某个用户赋予了太多权限，即使之后想在某个库里限制它，也很难收得住，因为全局权限的判断优先级通常会覆盖更细粒度的限制。所以生产环境里我强烈建议，能用库级或表级权限表达的，就尽量不要给全局的 . 权限。
1.3 MySQL 8.0之后，又多了一个认证插件的关卡
如果你所在的环境还是MySQL 5.7时代过来的，一定对 mysql_native_password 这个默认插件很熟悉。但从MySQL 8.0开始，默认认证插件改成了 caching_sha2_password。
这个改动的背景是安全升级，caching_sha2_password 比老的 native 插件在密码传输和存储上更安全。但随之而来的坑是：一些老版本的客户端、图形工具、旧驱动并不认识这个新插件，连接时会直接报类似下面这样的错误：
text复制Authentication plugin 'caching_sha2_password' cannot be loaded
或者：
text复制Client does not support authentication protocol requested by server
我之前排查过一个使用老版本JDBC驱动的Java服务，升级数据库到8.0后突然连不上，就是认证插件不兼容导致的。处理思路很明确：
- 最优先的方案是升级客户端、驱动或图形工具版本，让它们支持
caching_sha2_password； - 如果业务环境实在无法升级，可以单独为业务账号指定老插件，用类似下面的语法：
sql复制CREATE USER 'app'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password'; - 但不要因为某一个老客户端兼容不了，就把整个MySQL实例的默认认证插件改回老版本，那样等于让所有账号都承担不必要的安全风险。这个后面故障排查章节还会详细展开。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 账号生命周期操作清单：从创建到回收的标准动作
2.1 创建账号的标准姿势与参数细节
创建账号，官方标准语法是 CREATE USER。一个常规示例长这样：
sql复制CREATE USER 'report'@'192.168.%' IDENTIFIED BY 'Report@2024';
这条语句做的事情包括：在MySQL中创建用户、指定允许的来源网段为 192.168.%、设置认证插件为数据库默认值并写入密码。如果你希望这个账号用更高级的加密认证方式或者兼容老客户端，可以显式指定：
sql复制CREATE USER 'app'@'%' IDENTIFIED WITH caching_sha2_password BY 'App@2024';
很多MySQL初学教程会让你用 INSERT INTO mysql.user ... 这种粗暴方式创建账号，我在生产环