MySQL权限配置出错通常表现为几种情况：账户突然无法连接、某个用户拥有了本不该有的库表权限、root只能在本机登录却误改成了远程可访问，或者执行了UPDATE mysql.user之后权限毫无变化。这些问题背后都指向同一个机制：权限表不会因为一条UPDATE语句就自动同步到内存中的权限缓存。
一、先理解权限表与权限缓存的关系
MySQL的权限信息主要存储在mysql系统库下的几张表中，例如mysql.user、mysql.db、mysql.tables_priv、mysql.columns_priv和mysql.procs_priv。连接认证阶段会读取mysql.user表判断Host、User、密码以及全局权限；连接建立后，语句执行阶段再根据库、表、列级别的权限表进行细粒度校验。
为了避免每条SQL都去查询这些系统表，MySQL在启动时会把权限表内容加载到内存中，形成权限缓存。后续的权限判断直接基于内存，而不是每次都去扫磁盘上的表。因此，如果你绕过GRANT语句直接写mysql.user表，虽然磁盘上的数据变了，但内存中仍是旧数据，自然会出现改了不生效的情况。
GRANT、REVOKE、CREATE USER、ALTER USER、DROP USER、SET PASSWORD这些账户管理语句在执行时会同时更新权限表并刷新内存缓存，所以它们不需要额外执行FLUSH PRIVILEGES。只有直接使用UPDATE、INSERT、DELETE修改权限表时，才需要手动让服务器重新读取权限表。
二、修复错误权限配置的具体步骤
先确认当前权限状态。对于一个已知账户，可以使用SHOW GRANTS查看其实际权限，例如：
SHOW GRANTS FOR 'app_user'@'%';
如果需要查看mysql.user表里所有账户的Host和User组合，可以执行：
SELECT User, Host FROM mysql.user ORDER BY User, Host;
误授权是最常见的场景。假设原本只想给app_user在order_db库上的读写权限，结果误用了GRANT ALL PRIVILEGES ON *.*，导致该账户拥有了所有库的全局权限。修复方式是先撤销错误权限，再重新授权：
REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'app_user'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE ON order_db.* TO 'app_user'@'%'; FLUSH PRIVILEGES;
上面这段最后加不加FLUSH PRIVILEGES其实都不影响结果，因为REVOKE和GRANT本身就会自动刷新权限。但如果你的修复动作是直接修改mysql.user表，那就必须在最后执行FLUSH PRIVILEGES。例如把root从允许远程登录改回仅允许本机登录：
UPDATE mysql.user SET Host = 'localhost' WHERE User = 'root' AND Host = '%'; FLUSH PRIVILEGES;
还有一种严重情况是root密码出错或者权限被完全破坏，导致无法登录数据库。此时需要以跳过授权表的方式启动MySQL，再修复权限。可以在MySQL配置文件my.cnf的[mysqld]段下添加skip-grant-tables，然后重启服务。启动后无需密码即可连接，但要立刻修改root密码并清理错误权限。需要注意，skip-grant-tables模式下权限校验被完全关闭，修复完成后必须去掉该参数并重启。修改密码推荐使用ALTER USER：
FLUSH PRIVILEGES; ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewStrongPass123'; FLUSH PRIVILEGES;
这里为什么第一次先执行FLUSH PRIVILEGES？因为进入skip-grant-tables模式后，虽然可以登录，但账户管理语句可能会因为权限系统处于特殊状态而报错。先执行FLUSH PRIVILEGES可以让权限系统恢复到可操作状态，再修改密码会更稳定。修改完成后务必检查my.cnf并移除skip-grant-tables，然后重启数据库验证。
三、FLUSH PRIVILEGES的作用与正确使用时机
FLUSH PRIVILEGES命令会让MySQL重新读取权限表并重建内存中的权限缓存。它不会修改任何权限数据，只是把磁盘上的表内容同步到内存。因此，如果你没有改权限表，执行它并不会产生新的效果；如果你改了权限表但不执行它，修改就无法立即生效。
需要手动执行FLUSH PRIVILEGES的典型场景包括：直接使用UPDATE、INSERT、DELETE修改mysql.user、mysql.db等权限表；通过导入SQL文件恢复了权限表的备份；手工往权限表里插入新账户。这些操作绕过了账户管理语句的自动刷新机制，必须手动执行FLUSH PRIVILEGES或重启MySQL服务。
不需要执行FLUSH PRIVILEGES的场景则包括：使用GRANT授权、REVOKE撤销权限、CREATE USER创建账户、ALTER USER修改密码或锁定账户、DROP USER删除账户、SET PASSWORD设置密码。这些语句内部已经完成权限刷新，再手动执行一次虽然不会出错，但没有必要。此外，FLUSH PRIVILEGES本身会提交当前事务，如果在事务中执行可能会造成隐式提交，需要留意。
在命令行环境中，也可以使用mysqladmin工具来完成同样的事情：
mysqladmin -u root -p flush-privileges
这条命令与登录MySQL后执行FLUSH PRIVILEGES等价，适合脚本化处理或无法进入交互式mysql客户端的情况。
四、修复后的验证与长期预防
修复权限后必须验证是否生效。可以重新使用目标账户连接，执行一条涉及目标库的查询，确认权限范围符合预期。也可以通过SHOW GRANTS再次查看：
SHOW GRANTS FOR 'app_user'@'%';
同时应检查mysql.user表中是否还有异常的Host与User组合。比如一个用户名同时存在localhost和%两行记录，MySQL在认证时可能优先匹配到更具体的Host，导致你以为的远程访问其实并没有生效。此时需要确认实际连接匹配的是哪一行，再决定修改哪条记录。
长期来看，权限配置应遵循最小权限原则。不要为了方便直接授予ALL PRIVILEGES ON *.*，尽量按库按表授予必要的SELECT、INSERT、UPDATE、DELETE权限。定期使用SHOW GRANTS审查账户权限，并及时清理不再使用的账户。对于权限表的重要变更，建议先备份mysql库里的权限表，例如使用mysqldump导出或直接复制表数据。这样即使误操作，也能快速恢复并执行FLUSH PRIVILEGES让恢复结果即时生效。
MySQL权限修复FLUSH PRIVILEGES权限表修改时间：2026-10-05 04:11:03