最小权限原则要求账号权限从零开始按需授予，如只读报表账号仅限select权限且限定于具体库表；禁用all privileges和高危权限；应用账号须独立、隔离、限ip、密钥管理；定期清理失效账号。
最小权限原则必须落实到每个账号
给账号赋权时，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 语句，而是让每次赋权都经过质疑、留痕和验证。