flush privileges报错主因是权限不足、连接失败或服务未运行；需先确认当前用户拥有reload权限、mysql服务正常且已成功登录，再执行全大写带分号的正确命令。
FLUSH PRIVILEGES 报错，通常不是命令本身有问题，而是你没权限执行它、没连上库、或者 MySQL 服务根本没跑起来——直接查这三件事比反复重试更省时间。
执行 FLUSH PRIVILEGES 提示 “Access denied”
这是最常见的报错，错误信息类似：ERROR 1045 (28000): Access denied for user 'u1'@'localhost' (using password: YES) 或更具体的 ERROR 1227 (42000): Access denied; you need (at least one of) the RELOAD privilege(s) for this operation。
说明当前用户缺少 RELOAD 权限，而 FLUSH PRIVILEGES 必须由拥有该权限的账号执行。
- 用高权限账号（如
root）登录后检查：SHOW GRANTS FOR CURRENT_USER;，确认输出里包含RELOAD - 如果确实缺权限，管理员需执行：
GRANT RELOAD ON *.* TO 'u1'@'localhost';，再FLUSH PRIVILEGES;（注意：这里必须刷，因为GRANT语句本身不自动赋予RELOAD权限给当前会话） - 别用普通应用账号去执行这个命令——它本就不该出现在应用代码里
FLUSH PRIVILEGES 执行后无反应或报语法错
比如返回 ERROR 1064 (42000): You have an error in your SQL syntax，大概率是命令写错了。
- 确保命令是全大写、带分号、没有多余空格或不可见字符：
FLUSH PRIVILEGES;（不是flush privileges、FLUSHPRIVILEGES、FLUSH PRIVILEGES少分号） - 别在 shell 命令行里直接敲
mysql flush privileges—— 这是在系统层调用 mysql 客户端，但没进 SQL 模式；正确做法是先mysql -u root -p登录，再输入 SQL 命令 - 如果用脚本批量执行，注意换行和引号嵌套，例如 bash 中应写成：
mysql -u root -p -e "FLUSH PRIVILEGES;"
MySQL 服务未运行或连接失败导致 FLUSH PRIVILEGES 失效
命令根本没机会执行，常见于本地开发环境或 Docker 容器重启后。
- 先验证服务状态：
systemctl status mysql（Linux）或brew services list | grep mysql（macOS Homebrew） - 连接测试：
mysql -u root -p -e "SELECT 1;"，如果报Can't connect to local MySQL server，说明服务没起来 - Docker 用户注意：容器内 MySQL 启动可能延迟，
docker exec -it mysql-container mysql -u root -p -e "FLUSH PRIVILEGES;"可能因服务未就绪而失败，建议加sleep 2或用健康检查等待
改了权限表但 FLUSH PRIVILEGES 仍不生效
这时候报错未必出现，但新权限就是不起作用，典型症状是 Access denied 持续存在，哪怕 SELECT * FROM mysql.user 显示字段已更新。
- 确认你改的是正确的
User+Host组合，例如'app'@'192.168.1.%'和'app'@'%'是两个账户 - MySQL 8.0+ 默认用
caching_sha2_password插件，如果客户端不支持，会卡在认证阶段，看起来像权限问题；查插件：SELECT plugin FROM mysql.user WHERE User = 'your_user';，必要时切回：ALTER USER 'your_user'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd';，再FLUSH PRIVILEGES; - 已有连接不会重载权限，必须断开重连，或用
KILL CONNECTION xxx;主动终结旧会话
真正麻烦的不是命令本身，而是你以为它“刷新了权限”，其实只是把磁盘上的脏数据重新加载进内存——而那个内存快照，对已经建立的连接完全透明。
