1. 大多数数据库事故不是被"攻破"，而是被"顺手授权"
我在实际维护中见过太多类似场景：某天夜里线上库突然少了一张核心表，查操作记录发现是A同学在本地连生产库执行了一个脚本，脚本里那句 DROP TABLE 本来只是注释，结果因为换行问题被真正执行了。更麻烦的是，团队为了省事，所有人共用同一个 root 账号，连是谁执行的都定位不到。
这类事故发生后，大家第一反应往往是"备份呢？回滚呢？"，很少有人会去想：如果这个账号压根没有 DROP 权限，事故根本不会发生。权限管理就是这样——它不会出现在功能列表里，看起来也不产生业务价值，所以长期被当成"上线前的最后一步"甚至"没必要做的事"。但真到了出事那天，它就是那个唯一能让损失停在可控范围内的防线。
1.1 权限事故为什么总在"事后"才被发现
先给一个我自己经历过的典型案例。某团队接手了一个老项目，数据库账号密码写死在配置文件里，所有后端服务、定时任务、数据修复脚本，全用同一个账号。这个账号还是当初建库时顺手创建的，权限直接给了 ALL PRIVILEGES。后来开发新功能需要做一次批量更新，SQL 里不小心多写了一个 DELETE 条件，等发现的时候，订单表里已经少了三天的数据。
这件事的教训其实不复杂：权限越宽，事故的爆炸半径越大。你没法保证每个写 SQL 的人永远不犯错，也没法保证每个脚本每次都写得完美，但你可以保证一个账号就算出错了，也只能在它被允许的范围内出错。只读账号怎么误操作也删不了数据，没有 GRANT OPTION 的账号怎么折腾也影响不了其他账号，这就是最小权限原则存在的意义。
1.2 最小权限原则的三个追问
每次有人问我"这个账号该给什么权限"，我都会让他先回答三个问题：
- 这个账号是谁在用？是某个后端服务、某个数据报表平台、还是某个具体的人？服务账号和人用账号要分开。
- 它需要碰哪些数据？是整个实例所有库，还是某个业务库里的几张表？甚至只碰某几列？
- 它需要执行哪些操作？是只读还是可写？是否需要建表、删表？是否需要执行存储过程？能否授权给其他人？
把这三点想清楚，MySQL 里的授权语句基本就能直接写出来了。落到具体实现上，MySQL 把"谁能进来"和"进来能干什么"分成了两套完全独立的机制：user 表管认证，db 表、tables_priv 表这些管授权。这也是我接下来要重点拆的部分。
实际经验是：权限设计永远先于功能开发。新服务接入前先写清楚账号申请表，比事后追着开发补权限要省事得多。
2. MySQL 权限体系的底层骨架：user 表管登录，db 表管操作
很多人用 MySQL 好几年，权限相关操作还停留在"GRANT ALL 然后 FLUSH PRIVILEGES"这一步。真出了问题，比如为什么密码对了还连不上、为什么授权了存储过程还是不能执行，就完全没有排查思路。这种情况的根本原因，是对 MySQL 的权限存储结构没有概念。这一节我把底层机制掰开讲清楚。
2.1 权限表如何分工
MySQL 的权限不是一堆散落的配置，而是存在 mysql 库下的几张系统表里。不同的表管不同层级的权限，查询和修改也都是围绕这几张表展开：
| 系统表 | 作用层级 | 典型字段 |
|---|---|---|
| mysql.user | 全局，管连接认证和全局权限 | Host, User, authentication_string, Select_priv, Super_priv |
| mysql.db | 库级，管某个数据库的权限 | Host, Db, User, Select_priv, Insert_priv |
| mysql.tables_priv | 表级，管某个表的权限 | Host, Db, User, Table_name, Table_priv, Column_priv |
| mysql.columns_priv | 列级，管某张表里某些列的权限 | Host, Db, User, Table_name, Column_name, Column_priv |
| mysql.procs_priv | 例程级，管存储过程和函数的权限 | Host, Db, User, Routine_name, Routine_type, Proc_priv |
理解这张表，是理解权限系统的第一步。mysql.user 决定你能否连上数据库，其余几张表决定你连上之后能做什么。这两件事是分开判断的，所以才会出现"账号能连上，但执行 SQL 时无权限"这类的报错。
2.2 认证与授权是两套逻辑
MySQL 在验证一个连接时，走的流程大致是：
连接阶段，客户端发起连接请求，MySQL 根据客户端 IP 或主机名，从 mysql.user 表里找匹配的 Host+User 行。如果找不到，直接报ERROR 1045 (28000): Access denied；找到了，再校验密码，密码不对同样报 1045。这一步通过之后，连接才建立起来。
执行阶段，每一条 SQL 在执行前，MySQL 都会去查当前连接对应的权限。注意，这里的权限判断是叠加取并集的：一个用户只要有全局权限、库权限、表权限或列权限中的任意一个能满足当前操作，就能执行，不需要所有层级都有。比如用户在 db 表里有SELECT权限，就算 user 表里没有Select_priv，照样可以查那个库。
我们可以用生活里的场景来类比：user 表就是小区门口的门禁卡，卡里记录了你能不能进入小区；db 表、tables_priv 表则是小区里各套房间的钥匙。你进得了小区，不代表能打开每一扇门；但只要你手上有其中某一扇门的钥匙，那扇门你就是能开的。MySQL 的权限判断就是这种"有一票即可通行"的逻辑。
2.3 权限层级与 WITH GRANT OPTION
MySQL 的权限被划分成了五个层级，层级越低，影响范围越窄。我整理了一份常用权限对照：
| 层级 | 典型权限 | 作用范围 |
|---|---|---|
| 全局 | SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, SUPER | 整个实例上的所有对象 |
| 库级 | SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, EXECUTE | 指定数据库内的对象 |
| 表级 | SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, INDEX | 指定表 |
| 列级 | SELECT, INSERT, UPDATE | 指定表的指定列 |
| 例程级 | EXECUTE, ALTER ROUTINE, CREATE ROUTINE | 指定存储过程或函数 |
这里有个非常常见的误解：GRANT ALL PRIVILEGES并不等于"所有权限都给了"。ALL 的实际含义是"当前层级下支持的所有权限的总和"，全局的 ALL 和库级的 ALL 范围完全不同。更要注意的是，无论哪个层级的 ALL，都不会自动包含 GRANT OPTION。也就是说，拥有 ALL 的账号可以执行对应的所有操作，但它不能把权限再转授给别的账号，除非你显式加上WITH GRANT OPTION。
WITH GRANT OPTION这个选项要格外谨慎。它相当于把"发钥匙的权力"也交给了对方。一个只有两张表权限的账号，如果带上了 GRANT OPTION，它就能把这两张表的权限授给任意其他用户，等于权限链条失控了。所以我在生产环境的原则是：管理员账号可以有 GRANT OPTION，应用账号和服务账号一律不给。
3. 搭建一套"够用又不越权"的账号方案：从建用户到收权限
知道权限存在哪、怎么判断之后，就到了实际操作环节。这一节我会按最常见的生产场景，给出完整的建号、授权、收权操作，每个步骤都会讲清楚为什么这么写。
3.1 创建用户时就把边界定好
MySQL 里创建用户用CREATE USER，而不是INSERT INTO mysql.user。这句命令本身就支持把用户名、来源主机、密码、密码过期策略、锁定状态一起定好。
一个标准的示例：
CREATE USER 'app_rw'@'192.168.10.%' IDENTIFIED BY 'Str0ngPassw0rd!' PASSWORD EXPIRE INTERVAL 90 DAY FAILED_LOGIN_ATTEMPTS 4 PASSWORD_LOCK_TIME 1;这里有几个细节值得展开：
主机段'192.168.10.%'表示只允许来自 192.168.10 网段的客户端连接。把主机限定到网段或具体 IP，比'%'安全得多。'%'的意思是允许任意主机连接，相当于把数据库账号暴露在整个网络上，非常不建议在生产环境使用，除非你的网络隔离和防火墙做得足够严密。
PASSWORD EXPIRE INTERVAL 90 DAY让密码每 90 天强制过期。密码过期之后，应用连接会收到ERROR 1820，必须用ALTER USER重置密码才能继续执行语句。这个机制能防止密码长期不换导致泄露风险扩大，但对老应用不太友好，改之前要先确认驱动的行为。
FAILED_LOGIN_ATTEMPTS 4 PASSWORD_LOCK_TIME 1是 8.0.17 之后才有的登录失败锁定策略。连续输错 4 次密码，账号锁定 1 天。这个功能对于防止暴力破解非常实用，5.7 及更早版本没有这套机制，只能靠外部防护。
3.2 三种典型账号的授权写法
我按我的习惯，把生产环境常见的账号分成三类：只读账号、读写账号、管理账号。每种给一套可以直接抄的授权语句。
只读账号，一般是给报表平台、数据分析师、查询脚本用的：
CREATE USER 'analyst_ro'@'%' IDENTIFIED BY 'ReadOnlyPass1'; GRANT SELECT ON biz_db.* TO 'analyst_ro'@'%';只给SELECT，连SHOW VIEW、EXECUTE都不给，避免通过视图、存储过程间接读取更多数据。如果需要看表结构但不看数据，再单独加SHOW VIEW。
读写账号，给后端业务服务用：
CREATE USER 'app_rw'@'192.168.10.%' IDENTIFIED BY 'AppWritePass1'; GRANT SELECT, INSERT, UPDATE, DELETE ON biz_db.* TO 'app_rw'@'192.168.10.%';这里刻意没有给CREATE和DROP。业务服务在运行时只需要增删改查，建表和改表结构应该由迁移工具用独立的管理账号完成。为什么这么强调？因为很多时候误操作删表、改表，都是因为业务账号权限太宽，一个脚本 bug 就能把表结构搞崩。
管理账号，给 DBA 或运维人员日常维护用：
CREATE USER 'dba_ops'@'10.0.0.%' IDENTIFIED BY 'DbaOpsPass1'; GRANT ALL ON biz_db.* TO 'dba_ops'@'10.0.0.%'; GRANT SELECT ON mysql.user TO 'dba_ops'@'10.0.0.%'; GRANT SELECT ON mysql.db TO 'dba_ops'@'10.0.0.%';我一般不会让管理账号直接继承 root 的全部权限，而是给"业务库的所有权限 + 系统表的部分查询权限"。这样既能完成日常维护，又不会意外改动全局配置。生产环境的 root 账号应该只在本机使用，通过 socket 连接，绝不开放远程登录。
3.3 FLUSH PRIVILEGES 到底需不需要
这个话题几乎每个 MySQL 群里都会吵一轮。我的结论很明确：只要你是通过 GRANT、REVOKE、CREATE USER、ALTER USER、DROP USER 这些官方语句修改权限，就永远不需要执行 FLUSH PRIVILEGES。因为这些语句在执行时会同步修改系统表并刷新内存中的权限缓存，MySQL 已经替你做好了。
那 FLUSH PRIVILEGES 什么时候才有用？只有一种情况：你直接用INSERT、UPDATE、DELETE修改了 mysql.user、mysql.db 这些系统表。比如有人图快，直接UPDATE mysql.user SET Host='%' WHERE User='app';想改主机限制，这种操作不会自动生效，必须执行一次 FLUSH PRIVILEGES。
所以正确的顺口溜是：官方语句自动生效，手工改表才需要 FLUSH。我看到有些团队在部署脚本里习惯性写一句 FLUSH PRIVILEGES，这本身没什么危害，但它会给人一个错误暗示——"FLUSH 能让授权生效"。于是有人授权时漏了表权限，以为是没 FLUSH，实际上再 FLUSH 十次也没用，因为缺的权限根本不存在。
3.4 改密、锁定与删除账号
账号的生命周期管理同样重要。密码泄露要改密，人员离职要锁定或删除账号，这些都应该是常规操作。
ALTER USER 'app_rw'@'192.168.10.%' IDENTIFIED BY 'NewPassw0rd!'; ALTER USER 'leaver'@'%' ACCOUNT LOCK; DROP USER IF EXISTS 'leaver'@'%';我可以分享一个实际经验：删除账号前，先锁定再观察一段时间是更稳妥的做法。有些服务依赖的账号藏在配置文件里，直接删了会导致整套服务起不来，锁定了至少还能快速解锁恢复。另外，DROP USER会把该用户在所有权限表里的记录一并删除，不需要手动去清。
4. 权限问题排查实录：六类我踩过或帮别人踩过的坑
这一节是全文最实战的部分。我把这几年在线上遇到过、帮同事排查过的 MySQL 权限问题整理成六类，每一类都包含完整的排查链路。读的时候你可以把自己代入进去，下次遇到类似报错，直接按这个思路走。
4.1 密码明明是对的，却报 Access denied：localhost 与 % 的匹配顺序
某次帮一个开发排查问题，他非常确定密码没写错，因为从另一台机器用同一个账号连接是成功的，但就在本机执行mysql -uapp -p却报：
ERROR 1045 (28000): Access denied for user 'app'@'localhost'我让他先查了一遍用户列表：
SELECT user, host FROM mysql.user;查完就发现问题了。表里存在一个匿名用户''@'localhost'，同时存在'app'@'%'。这台机器 MySQL 刚装好的时候可能跑过某些初始化脚本，把匿名用户留了下来。
MySQL 在匹配连接时，会对 user 表按 Host 排序，越具体的 Host 越优先匹配。'localhost'比'%'更具体，所以客户端从本机连接时，MySQL 优先匹配到''@'localhost'这个匿名用户，而不是'app'@'%'。匿名用户当然没有密码，于是密码一校验就直接失败。
修复方案很简单：
DROP USER ''@'localhost';或者干脆给应用也建一个'app'@'localhost'的账号。这个坑的教训是：遇到 Access denied，第一件事永远是查mysql.user里有哪些 user 和 host 组合，不要急着去猜密码。很多看起来像密码错的问题，其实是匹配到了不该匹配的行。
4.2 授权后"不生效"，其实和 FLUSH 没关系
另一类高频问题是："我执行了 GRANT，客户端还是没权限，是不是要 FLUSH？"我会反问一句：你确定 GRANT 的目标和你连接时的身份完全一致吗？
举个例子。有人执行了：
GRANT SELECT ON biz_db.* TO 'reader'@'10.0.0.50';但报错的应用连接来源 IP 实际是10.0.0.60，MySQL 匹配不到这行授权，自然没有权限。这类问题不是权限缓存没刷新，而是授权对象和实际连接身份不匹配。
排查思路是查三个信息：当前连接用的用户和来源 IP、授权记录里的用户和主机、客户端实际连接时用的 IP。
-- 查看当前连接是谁 SELECT CURRENT_USER(), USER(), HOST(); -- 查看这个用户的授权情况 SHOW GRANTS FOR CURRENT_USER();我见过太多人在这类问题上绕圈子，最后发现是配置文件里旧库地址指向了另一个环境。所以排查权限问题时，第一优先确认"连接到的到底是哪个实例""以什么用户什么主机连接的"，这两点不搞清楚，后面全是无用功。
4.3 远程连不上：'%' 授权不等于端口可达
还有一次是某团队说数据库账号授权成了'app'@'%'，但应用服务器还是连不上，报：
ERROR 2003 (HY000): Can't connect to MySQL server on '...' (10060)注意，这个报错不是ACCESS DENIED，它是连接阶段的网络层错误。我排查时先检查了三件事：
- MySQL 的
bind-address配置。如果只绑定了127.0.0.1，那么任何外部 IP 都连不进来，这时候授权给%也没用。 - 操作系统防火墙和云安全组是否放开了 3306 端口。
- 客户端是否能 ping 通服务器 IP。
这里有个容易混淆的点：授权和网络可达是两回事。GRANT ... TO 'app'@'%'只是允许这个账号从任意主机发起连接，但如果网络层面根本到不了 MySQL 监听的端口，授权再宽也没用。很多新人一上来就去调权限，其实问题出在端口没开。
另外一个隐藏坑是skip-name-resolve。如果 MySQL 开启了skip_name_resolve，它就不会对客户端 IP 做反向 DNS 解析，授权表里的 Host 列就只能写 IP 或通配符。你如果写的是'app'@'web01'这种主机名，在开启该参数后是匹配不上的，因为 MySQL 已经不做主机名解析了。
4.4 表权限给了，存储过程和视图还是报权限不足
存储过程和视图是权限问题的高发区，因为很多人只盯着表权限，忽略了例程级权限和 DEFINER 机制。
先说存储过程。没有EXECUTE权限时，执行存储过程会报：
ERROR 1370 (42000): execute command denied to user 'app'@'%' for routine 'biz_db.sp_calc'明明用户对存储过程涉及的订单表有SELECT权限，为什么还是不行？这是因为执行存储过程本身就需要独立的EXECUTE权限，和过程内部的表权限是两套体系。授权方式：
GRANT EXECUTE ON PROCEDURE biz_db.sp_calc TO 'app'@'%';再说视图。用户在视图上有SHOW VIEW或SELECT权限，但视图底层引用的表没有SELECT权限，执行查询时会报：
ERROR 1356 (HY000): View 'biz_db.view_name' references invalid table(s) or column(s)MySQL 的视图权限检查会穿透到底层表。所以排查这类报错时，要顺着视图的定义一层层看它引用了哪些表，给这些表补上对应权限。
这里还要提醒一句：存储过程的 DEFINER 机制经常让人困惑。默认情况下存储过程的
SQL SECURITY是DEFINER，也就是调用者执行时用的是定义者的权限，而不是自己的。如果定义者权限被回收或账号被删，即使调用者自身权限足够，也会报错。排查时用SHOW PROCEDURE STATUS或查看过程定义，确认 DEFINER 账号还活着。
4.5 8.0 密码插件与老客户端不兼容
MySQL 8.0 把默认密码认证插件从mysql_native_password换成了caching_sha2_password。新客户端没问题，但一些老版本的驱动、旧版本命令行工具会直接报：
ERROR 2059 (HY000): Authentication plugin 'caching_sha2_password' cannot be loaded这种问题我曾经在一台跑着旧版本 PHP 应用的环境里遇到过，查了半天才发现是驱动太老，根本不认识新的认证插件。
解决方案有两个方向：
一是升级客户端驱动。这是最推荐的长期方案，因为新插件安全性更好，而且 MySQL 8.4 开始mysql_native_password默认不再启用，继续依赖老插件只会越来越难走。
二是临时兼容，把账号改回旧插件：
ALTER USER 'app'@'%' IDENTIFIED WITH mysql_native_password BY 'YourPass';但我要提醒：这是兼容手段，不是长久之计。如果团队里有老版本 MySQL 实例混用，跨版本迁移时这种密码格式的坑尤其多，建议把"升级驱动、统一认证插件"写进技术债清单里。
4.6 别动不动用 skip-grant-tables 救火
最后一个坑是关于skip-grant-tables的。这个参数的意思是跳过所有权限检查，启动后任何客户端连上来都不需要密码，直接就是最高权限。它设计出来的原始用途是"忘了 root 密码时应急恢复"，但很多人把它当成了万能钥匙。
我看到过最夸张的一次，某团队直接在配置文件里长期写上了skip-grant-tables，理由是"老是被权限问题卡住，这样省事"。等于把 MySQL 的整个权限体系彻底关掉了，公网可访问的实例裸奔在互联网上。这种方式的危险程度，比所有权限坑加起来都高。
如果真的忘记 root 密码，标准恢复流程应该是：
- 停止 MySQL。
- 以
--skip-grant-tables参数启动，注意同时加上--skip-networking，禁止远程 TCP 连接，只允许本机操作，最大限度缩小暴露面。 - 连接数据库，修改 root 密码。
- 正常重启 MySQL，去掉
--skip-grant-tables参数。
恢复完成的第一时间就要确认配置里没有残留该参数。这一条我建议写进团队的变更流程 checklist 里，防止有人临时加完忘记移除。
5. 生产环境的权限治理：从"能跑"到"管得住"
排查完单点问题，最后把视角拉高一点。单看每一句授权都不复杂，难的是让整套权限体系在一个团队里持续、稳定地运行下去。这一节分享我在生产环境里沉淀下来的账号规划、角色使用和审计方法。
5.1 一套可复用的账号矩阵
接手的项目多了之后，我习惯先画一张账号矩阵表。每次新增服务或人员，都先对着表看它应该属于哪一类，再决定给哪些权限。
| 账号类型 | 典型用途 | 权限范围 | 主机限定 |
|---|---|---|---|
| root | 本机安装维护 | 所有权限 | 仅 localhost |
| dba_admin | DBA/运维日常操作 | 业务库 ALL + 系统表 SELECT | 管理网段 |
| app_read | 报表、查询服务 | 指定库 SELECT | 应用网段 |
| app_rw | 业务服务 | 指定库 SELECT/INSERT/UPDATE/DELETE | 应用网段 |
| backup | 备份工具 | SELECT, SHOW VIEW, LOCK TABLES, EVENT, RELOAD | 备份服务器 |
| monitor | 监控组件 | PROCESS, REPLICATION CLIENT, SELECT | 监控网段 |
这套矩阵的核心思想就是**"一类身份，一套权限"**。人和服务的账号严格分离，即使是同一个开发，他在不同角色下也是不同的账号连接。这样一旦出了问题，可以快速从账号定位到使用方，而不会出现"所有人都用 root，谁也没法确认是谁"的尴尬。
5.2 用角色解决重复授权（8.0 及以上）
如果你管理的实例很多，比如有几十个业务库，每个库都要配一套只读账号和读写账号，逐个GRANT会非常繁琐。MySQL 8.0 的角色功能就是专门解决这个问题的。
角色可以理解为一个"权限包"，先给角色授权，再把角色授予用户：
CREATE ROLE 'role_biz_read'; GRANT SELECT ON biz_db.* TO 'role_biz_read'; -- 把角色授给两个用户 GRANT 'role_biz_read' TO 'analyst_ro1'@'%'; GRANT 'role_biz_read' TO 'analyst_ro2'@'%'; -- 让用户默认激活该角色 SET DEFAULT ROLE 'role_biz_read' TO 'analyst_ro1'@'%';角色的好处是权限变更只改一处。比如业务库从biz_db改名成biz_db_v2，只需要调整角色上的授权，所有挂了该角色的用户自动同步生效，不用逐个改。老版本 5.7 没有这个功能，只能靠脚本批量生成授权语句来模拟。
5.3 密码策略与账号生命周期
权限管住了，密码这块也不能放松。我建议至少做三件事：
第一，启用密码强度校验。MySQL 8.0 通过组件方式：
INSTALL COMPONENT 'file://component_validate_password'; SET GLOBAL validate_password.policy = 'MEDIUM';第二，强制密码过期和登录失败锁定。之前创建用户时已经写了示例，如果是存量账号，用ALTER USER补上：
ALTER USER 'app_rw'@'%' PASSWORD EXPIRE INTERVAL 90 DAY; ALTER USER 'app_rw'@'%' FAILED_LOGIN_ATTEMPTS 5 PASSWORD_LOCK_TIME 2;第三，把账号生命周期和人员的入离职流程绑定。有人离职，必须当天锁定或删除账号。这件事靠自觉不靠谱，要写成制度，最好配合自动化脚本定时扫描。
5.4 定期审计的几条实用 SQL
权限治理不是"配好就完事"，而是要定期检查。我最常跑的几个审计查询：
-- 找出允许从任意主机连接的账号 SELECT user, host FROM mysql.user WHERE host = '%'; -- 找出有 GRANT OPTION 的账号 SELECT user, host FROM mysql.user WHERE grant_priv = 'Y'; -- 找出所有账号及插件，排查空密码 SELECT user, host, plugin, authentication_string = '' AS empty_pwd FROM mysql.user;每季度跑一遍这些 SQL，把空密码账号、过期账号、可疑的宽主机账号清理掉。另外，我还会在mysql.user的备注字段或者USER_ATTRIBUTES里给每个账号标注负责人和用途。8.0.21 起支持：
ALTER USER 'app_rw'@'%' ATTRIBUTE '{"owner": "billing-team", "purpose": "order-service-rw"}';有标注的好处是半年后再看权限清单，不需要追着人问"这个账号是谁的"。
5.5 权限备份与迁移：别直接导 mysql.user 表
最后讲一个迁移场景。很多人做数据库迁移时，习惯性用mysqldump导出 mysql 库，想把用户和权限连同业务数据一起搬走。我强烈不建议这么做。系统表在不同版本之间字段差异很大，直接导入很容易把权限表搞坏，而且mysql.user表的密码哈希在不同版本、不同认证插件下不能通用。
更稳的做法是：用SHOW GRANTS收集所有账号的授权语句，在新环境里逐一执行重建。我自己会写一个简单的脚本循环遍历所有用户，把SHOW GRANTS FOR的输出汇总成一个 SQL 文件，迁移时直接执行。这样既保留了完整的权限定义，又能确保语句是用当前版本语法生成的，兼容性最好。
最后一件事：把权限管理当成持续收敛的过程
写了这么多，最后分享几句个人体会。权限管理这件事，最大的难点不是技术，而是"持续"。项目初期没有账号体系很正常，怕的是越到后面越觉得"反正一直这么用也没出事"。
我见过最有效的做法，是一个团队在新项目启动时就把账号清单做成了一页纸，写明每个账号的用途、负责人、权限范围和清理周期，贴在运维文档的首页。每次新服务接入都要走一遍这个流程，每季度再花半天时间过一遍mysql.user，清理掉不再使用的账号。这个习惯坚持下来以后，权限问题反而成了他们线上最少出问题的环节。
另外一个很实用的小技巧：排查权限问题的时候，先看报错属于哪个阶段。连接阶段的 1045、2003 问题先查网络和 user 表匹配，执行阶段的 1142、1370 问题再查授权层级和 DEFINER。按这个思路走，大多数问题十分钟内都能定位，比瞎试命令高效得多。
MySQL 权限管理说穿了就是"想清楚、配准确、管得住"这九个字。希望这篇梳理能帮你少踩几个坑。
