MySQL 权限管理不是安全的“附加项”，而是数据库安全的第一道、也是最核心的防线——权限配错，等于把钥匙直接塞进攻击者手里。
为什么 GRANT
写错一行就可能引发数据泄露？
MySQL 的权限是分层叠加且“最小匹配优先”的：用户
'reporter'@'192.168.5.%'和
'reporter'@'%'是两个完全独立的账户，哪怕只漏掉一个 IP 段，就可能让 BI 工具连上高权限账号；更危险的是，
GRANT SELECT ON *.*这种全局只读，实际会暴露
mysql.user表结构（含密码哈希）、所有数据库名、甚至存储过程逻辑——这正是不少内部数据爬取事件的起点。 真实踩坑：用
CREATE USER 'app'@'%' IDENTIFIED BY '123';创建后没
GRANT，结果应用报
Access denied for user 'app'@'x.x.x.x'——不是密码错，是根本没权限连库（连
USAGE都没给） 安全红线：永远别对生产账号用
GRANT ALL PRIVILEGES ON *.*，哪怕临时调试。替代方案是明确指定库：
GRANT SELECT, INSERT ON finance_db.*主机名陷阱：
'user'@'localhost'和
'user'@'127.0.0.1'在 MySQL 里不等价——前者走 Unix socket，后者走 TCP，权限表里是两条记录
DROP USER
真的能彻底清理权限吗？
能，但仅限于通过
CREATE USER或
GRANT创建的用户。如果曾手动往
mysql.user表里
INSERT过记录，或者用老版本 MySQL（DROP USER 可能漏掉
mysql.db或
mysql.tables_priv里的残留权限行，导致“用户删了，权限还在”。 验证是否清干净：
SELECT host,user,authentication_string FROM mysql.user WHERE user='xxx';结果为空才算真删除 生产建议：删用户前先
REVOKE ALL PRIVILEGES ON *.* FROM 'xxx'@'host';，再
DROP USER，双保险 注意：MySQL 8.0+ 默认启用
caching_sha2_password插件，
DROP USER后若同名用户重建，旧密码可能因插件缓存仍可登录（需
FLUSH PRIVILEGES强制刷新）
权限变更后，应用为啥还连不上？常见延迟与缓存误区
绝大多数情况下，
GRANT/
REVOKE执行完立刻生效，**不需要**
FLUSH PRIVILEGES。这条命令只在你绕过 SQL 接口、直接
UPDATE mysql.user后才需要——而这种操作本身就不该出现在生产环境。 连不上真正原因往往是：客户端复用旧连接（长连接未断开），或中间件（如 ProxySQL、ShardingSphere）缓存了权限元数据 验证权限是否生效：
SHOW GRANTS FOR 'user'@'host';，别信应用日志里的模糊错误 BI 工具常连错账号：比如 Tableau 默认用
root@localhost，但你只给
reporter@'10.10.%.%'授了权，结果查不到数据——得看工具实际连的是哪个
user@host
权限配置里最隐蔽的漏洞，往往不在“给了什么权限”，而在“没收回什么权限”：一个被遗忘的
WITH GRANT OPTION账号，可能已悄悄把
SELECT权限转授给测试库的临时用户，而那个测试库恰好同步了生产脱敏表——安全链条断裂，常常始于一次没被审计的授权。
