MySQL权限管理是数据库安全核心防线；权限分层叠加且最小匹配优先，'reporter'@'192.168.5.%'与'%'为独立账户；GRANT SELECT ON .会暴露敏感系统表；CREATE USER后须显式GRANT USAGE才可连接；严禁GRANT ALL PRIVILEGES ON .；'localhost'与'127.0.0.1'权限不等价；DROP USER仅清除正规创建的用户权限。
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 权限转授给测试库的临时用户，而那个测试库恰好同步了生产脱敏表——安全链条断裂，常常始于一次没被审计的授权。
