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+）核对角色绑定关系是否符合预期。
