最小权限原则必须落实到每个账号
给账号赋权时，
GRANT不该是“先给
ALL PRIVILEGES，后面再删”，而应从零开始、按需叠加。比如一个只读报表账号，只需
SELECT权限，且应限定在具体数据库（如
report_db）甚至表（如
report_db.monthly_summary），绝不能授予
mysql系统库或
*.* 的全局权限。
常见错误现象：
Access denied for user 'app'@'%' (using password: YES)看似权限不足，实则是误授了高危权限后被安全策略拦截；或更隐蔽的——账号被横向提权后执行
DROP TABLE却没被及时发现。 禁止使用
GRANT ALL ON *.*，哪怕临时调试也不行 用
SHOW GRANTS FOR 'user'@'host'定期核对实际权限，别只信自己记的 SQL 应用账号一律禁用
SUPER、
FILE、
PROCESS、
REPLICATION CLIENT等运维类权限
避免密码硬编码与共享账号
应用连接 MySQL 时，
root或同名通用账号写死在配置文件或环境变量里，等于把钥匙挂在门把手上。一旦某台应用服务器失陷，所有数据库都暴露。
真实场景中，微服务 A 和 B 共用一个
app_rw账号，B 出现 SQL 注入漏洞后，攻击者直接用该账号连上主库执行
LOAD DATA INFILE导出敏感数据——因为权限没做隔离，也没限制来源 IP。 每个服务/模块分配独立账号，命名体现用途（如
svc_payment_ro、
svc_analytics_rw） 密码不存代码或明文配置，走密钥管理服务（如 HashiCorp Vault）或容器 secret 注入 用
CREATE USER 'u'@'10.20.%.%'显式限制可连接的网段，不用
'%'泛匹配
定期清理失效账号与过期权限
离职人员账号、测试环境残留账号、半年没登录过的账号，都是权限滥用的温床。MySQL 不会自动过期或禁用闲置账号，全靠人工维护。
执行
SELECT user, host, account_locked, password_last_changed FROM mysql.user WHERE password_last_changed 可快速定位长期未轮换密码的账号；但更关键的是查登录行为——<code>performance_schema.accounts（需开启
performance_schema）能告诉你哪些账号近 30 天根本没活动。 设置账号密码有效期：
ALTER USER 'u'@'h' PASSWORD EXPIRE INTERVAL 90 DAY禁用非必要账号：
ALTER USER 'test_dev'@'%' ACCOUNT LOCK，比删掉更安全（保留审计线索） 每季度跑一次
SELECT user, host FROM mysql.user WHERE account_locked = 'N'，人工确认是否都合理
权限变更必须走审计与审批流程
开发提工单要
GRANT INSERT ON prod_orders.*，DBA 顺手加上
WITH GRANT OPTION方便他后续自助授权？这是典型的风险放大操作。一旦该账号泄露，攻击者就能递归创建新账号、绕过权限边界。
线上库权限调整不是“执行一条 SQL 就完事”，它直接影响数据资产边界。没有记录的
GRANT操作，等于没发生过；没有回滚预案的权限开放，就是埋雷。 所有
GRANT/
REVOKE必须提交至变更平台，附带业务原因、影响范围、有效期（如“仅上线期间临时开通”） 禁用
WITH GRANT OPTION，除非明确需要二级权限分发且已评估风险 生产环境权限变更后，立即在另一会话用
SHOW GRANTS FOR 'u'@'h'验证结果，别只信返回的 “Query OK”
权限滥用往往不出现在高调操作里，而藏在习以为常的“方便一下”“先加着后面再收”之中。真正难的不是写出合规的
GRANT语句，而是让每次赋权都经过质疑、留痕和验证。
