MySQL权限滥用核心风险是权限过大、账号复用与长期不审计；需用SHOW GRANTS查GRANT OPTION或ALL PRIVILEGES账号，收缩host范围，禁用GRANT ALL，强制SSL，限连数，8.0+可用角色但不可嵌套，GRANT/REVOKE后无需FLUSH PRIVILEGES。
MySQL 权限滥用的核心风险不在“没设权限”，而在“权限过大+账号复用+长期不审计”——最小权限原则必须落实到每个账号、每条 SQL、每次连接。
如何用 SHOW GRANTS 快速发现高危账号
直接查出谁有 GRANT OPTION 或全库 ALL PRIVILEGES，这类账号等于拥有“发权限的权限”，极易被横向提权：
SELECT user, host FROM mysql.user WHERE Grant_priv = 'Y' OR Super_priv = 'Y';
再对每个可疑账号执行：
SHOW GRANTS FOR 'admin'@'%';
- 重点看是否含
WITH GRANT OPTION—— 除非是 DBA 主账号，否则一律删掉 - 检查是否授予了
ON *.*（全实例权限）或ON database.*（整库权限），而实际只需操作某张表 - 注意
'user'@'%'这类通配 host：若应用只从内网 192.168.10.0/24 连接，就该缩为'user'@'192.168.10.%'
创建应用账号时必须避开的三个默认陷阱
很多团队用 CREATE USER + GRANT ALL 一键生成账号，结果埋下隐患：
-
GRANT ALL ON app_db.* TO 'app'@'%'→ 实际应用通常只读写几张表，应拆成SELECT, INSERT, UPDATE ON app_db.orders和SELECT ON app_db.products - 忘记
REQUIRE SSL：公网或混合云场景下，明文传输账号密码极危险，加一句REQUIRE SSL强制加密通道 - 未设
MAX_USER_CONNECTIONS：一个被攻破的应用账号可能发起数百并发连接拖垮实例，建议按应用 QPS 预估后设限，例如MAX_USER_CONNECTIONS 20
用角色（ROLE）替代重复授权，但要注意 MySQL 版本差异
MySQL 8.0+ 支持角色，可把权限打包复用，但 5.7 及更早版本不支持，强行用会报错 ERROR 1396 (HY000): Operation CREATE ROLE failed：
CREATE ROLE 'app_reader';<br>GRANT SELECT ON sales.* TO 'app_reader';<br>CREATE USER 'report_user'@'10.0.2.%' IDENTIFIED BY 'xxx';<br>GRANT 'app_reader' TO 'report_user'@'10.0.2.%';
- 启用角色前确认
show variables like 'activate_all_roles_on_login';是否为ON，否则用户登录后需手动SET DEFAULT ROLE - 角色不能嵌套（MySQL 8.0.16+ 才支持），避免设计成
role_a → role_b → role_c的链式依赖 - 回收权限时优先 revoke 角色，而非单个用户——否则下次新建同名用户会意外继承旧权限
权限变更后必须立即 FLUSH PRIVILEGES 吗？
不需要。只有直接修改 mysql.user 等系统表后才需刷新；所有通过 GRANT/REVOKE/DROP ROLE 做的操作，权限立即生效（无需 flush，也不建议 flush）。
误执行 FLUSH PRIVILEGES 反而可能触发 bug：在某些 MySQL 5.7 小版本中，它会重载权限表但忽略内存中的角色缓存，导致新授角色不生效。
真正该做的，是记录每次权限变更：GRANT 操作本身要进版本控制（如 Ansible playbooks 或 SQL 变更工单），并定期用 SELECT * FROM mysql.role_edges;（8.0+）核对角色绑定关系是否符合预期。
