MySQL权限管理是数据安全第一道闸门，65%数据库安全事件源于权限配置不当；全局权限如FILE、SUPER、GRANT OPTION易突破最小权限原则；权限匹配按user→db→tables_priv顺序先命中者胜；host='%'不匹配localhost；删除用户后残留权限需手动清理；字段级权限和视图可模拟行级控制；权限变更须FLUSH PRIVILEGES生效。
MySQL权限管理不是安全的“附加项”，而是数据不出事的第一道闸门。65% 的数据库安全事件直接源于权限配置不当——这不是统计偏差，是大量生产事故倒推出来的铁律。
为什么GRANT ALL ON *.*等于给黑客递钥匙
全局权限（如 SUPER、FILE、PROCESS）一旦被普通用户持有，就突破了最小权限边界：
-
FILE权限允许用户读写服务器任意文件，比如通过SELECT ... INTO OUTFILE导出/etc/shadow，或用LOAD DATA INFILE注入恶意配置 -
SUPER可绕过只读模式、杀掉任意线程、修改运行时变量，攻击者能关闭审计日志、禁用SSL、甚至伪造主从同步 -
GRANT OPTION若未加限制，会让用户把自己权限转授他人，形成权限扩散链
真实案例：某金融后台账号被钓鱼后，因拥有 FILE + SELECT 权限，10分钟内导出全部用户加密凭证并上传至境外服务器。
user、db、tables_priv 三张表的匹配顺序决定权限是否生效
MySQL在验证权限时严格按 user → db → tables_priv → columns_priv 顺序逐层匹配，**先命中者胜，不叠加、不合并**。这意味着：
- 即使
user表中Select_priv='N'，只要db表对某库设了Select_priv='Y'，该用户对该库仍有查询权 -
host字段值为'%'并不等价于所有IP——它不匹配 localhost（Unix socket 连接走的是'localhost'而非'%'），容易造成“明明授权了却连不上”的错觉 - 删除用户后，
db或tables_priv表中残留的记录不会自动清除，形成“僵尸权限”
SELECT host, user, Select_priv, Insert_priv FROM mysql.user WHERE user = 'dev'; SELECT host, db, Select_priv, Update_priv FROM mysql.db WHERE user = 'dev';
字段级权限和行级权限：不是“高级功能”，而是合规刚需
当业务涉及身份证、手机号、健康信息等敏感字段时，仅靠表级 SELECT 权限已无法满足《数据安全法》或 HIPAA 要求：
-
GRANT SELECT(id, name) ON app.users TO 'analyst'@'%'—— 精确控制可见列，避免误查id_card字段 - MySQL 原生不支持行级权限（RLS），但可通过视图 + 权限组合模拟：
CREATE VIEW users_dept_a AS SELECT * FROM users WHERE dept_id = 1;，再对视图授SELECT - 注意：视图权限不继承基表权限，必须显式授予；且若用户有基表
SELECT，仍可绕过视图直接查
最容易被忽略的一点：权限变更不会实时刷新——MySQL 启动时将权限表载入内存，后续 GRANT/REVOKE 会触发重载，但直接 UPDATE mysql.* 表不会生效，必须手动执行 FLUSH PRIVILEGES。而很多自动化脚本忘了这一步，导致“以为授了权，其实没生效”。
