GRANT 之后到底要不要执行 FLUSH PRIVILEGES？
绝大多数情况下——不需要。只要你是用 GRANT、REVOKE、CREATE USER 或 DROP USER 这类标准权限语句操作的，MySQL 会自动更新内存中的权限缓存，也同步写入磁盘的系统表（比如 mysql.user、mysql.db），此时再执行 FLUSH PRIVILEGES 是冗余的，没坏处但纯属多此一举。
真正需要它的场景只有一个：你绕过 SQL 接口，直接用 INSERT/UPDATE/DELETE 去改了 mysql 库下的权限表（比如手动 UPDATE mysql.user SET Host='%' WHERE User='root'）。这时候 MySQL 完全不知道磁盘上已经变了，必须靠 FLUSH PRIVILEGES 主动重载。
- 常见错误现象：改完
mysql.user表后，新Host不生效，连不上；或权限明明加了却报Access denied - 注意：即使执行了
FLUSH PRIVILEGES，已存在的连接仍沿用旧权限，只有新连接才用新规则 - 生产环境别手抖去直接 DML 改权限表——风险高、难审计、易锁表
为什么改了权限，客户端还是连不上或报错？
权限不生效，往往不是缓存没刷，而是权限粒度或连接上下文没对上。最典型的是 Host 匹配失败：MySQL 认证时会严格比对用户名 + 主机名（即 'user'@'host' 这个完整组合），而 'root'@'localhost' 和 'root'@'127.0.0.1' 在权限系统里是两个完全独立的账号。
- 常见错误现象：
GRANT ALL ON *.* TO 'root'@'%'后，本地用mysql -u root -h 127.0.0.1仍被拒绝 - 原因：客户端实际走的是 TCP 连接（匹配
'root'@'127.0.0.1'），但你只给了'root'@'%'权限，而 MySQL 默认不把%当作127.0.0.1的通配符（尤其在启用了skip-name-resolve时） - 实操建议：查当前连接用的到底是哪个 host：
SELECT USER(), CURRENT_USER();；前者是「你声称自己是谁」，后者才是「MySQL 认为你是谁」 - 安全提醒：
'root'@'%'在公网暴露极其危险，应限定具体 IP 段，如'root'@'192.168.1.%'
FLUSH PRIVILEGES 执行后还无效？检查这三件事
FLUSH PRIVILEGES 本身不会失败（只要用户有 RELOAD 权限），但如果执行后权限依然不生效，问题大概率出在别的地方。
- 确认执行命令的用户有
RELOAD权限：否则会报错ERROR 1227 (42501): Access denied; you need (at least one of) the RELOAD privilege(s) for this operation - 检查是否漏了
IDENTIFIED BY：比如GRANT ... TO 'u'@'h'但没设密码，而客户端连的时候带了密码，就会因认证失败被拒 - 验证权限是否真写进去了：
SELECT Host,User,authentication_string FROM mysql.user WHERE User='xxx';，别只信 GRANT 语句没报错就以为成功了
远程访问权限配置后连不上？别只盯 FLUSH
给用户开了 'user'@'%' 并 FLUSH PRIVILEGES，但依然连不上，大概率是网络或服务层拦住了，和权限缓存无关。
- 检查 MySQL 是否监听非本地地址：
netstat -tlnp | grep :3306，如果只显示127.0.0.1:3306，说明 bind-address 还是默认值，需在my.cnf中设为bind-address = 0.0.0.0或具体外网 IP - 确认防火墙放行：Linux 上
iptables或ufw，云服务器还要看安全组规则 - 确认 MySQL 用户 Host 允许该来源：比如你在内网用
10.0.1.5连，但只授权了'u'@'10.0.1.%'，那没问题；若只给了'u'@'10.0.0.%'，就匹配不上
权限变更的生效链条其实很短：SQL 语句 → 磁盘表更新 → （必要时）FLUSH PRIVILEGES → 新连接加载。卡住的地方，90% 都在「你以为的连接方式」和「MySQL 实际识别的连接方式」之间。
