应按角色分类账号并遵循最小权限原则，严格限制权限范围、强化密码与生命周期管理、定期审计回收权限。
明确账号分类与最小权限原则
数据库账号不应“一账号走天下”。项目中需按角色划分：开发账号、测试账号、生产只读账号、生产运维账号等。每个账号仅授予完成其职责所必需的最小权限。例如，前端服务连接数据库的账号，通常只需对特定业务表有SELECT/INSERT/UPDATE权限，严禁授予DROP、ALTER、CREATE或全局权限（如ALL PRIVILEGES ON *.*）。
按库、按表粒度授权，禁用通配符过度授权
避免使用GRANT ... ON *.*或ON `app_%`.*这类模糊匹配，除非有强管控的命名规范和自动化审计。推荐显式指定库名与表名：
- GRANT SELECT, INSERT ON `order_db`.`orders` TO 'app_order_rw'@'10.20.%';
- GRANT SELECT ON `user_db`.`users` TO 'report_reader'@'%';
- 若需跨多表，逐表授权或统一建视图后授视图权限，而非直接开放整个库
密码与生命周期必须强管控
所有账号密码须满足复杂度要求（长度≥12，含大小写字母+数字+符号），禁止明文存于代码或配置文件。建议：
- 使用密钥管理服务（如Vault、阿里云KMS）动态获取密码
- 生产账号密码每90天轮换，自动触发权限复核
- 离职/转岗人员关联账号须在24小时内禁用并审计历史操作
- 临时调试账号设置MAX_QUERIES_PER_HOUR和MAX_CONNECTIONS_PER_HOUR限制
定期审计与权限回收机制
权限不是“设一次就放心”。应建立常态化检查：
- 每月执行SELECT user, host, authentication_string FROM mysql.user;比对账号清单
- 用SHOW GRANTS FOR 'xxx'@'yyy';验证实际权限是否仍符合当前角色需求
- 对6个月无登录记录或权限长期未变更的账号，自动发起回收流程
- 上线新模块前，必须提交《数据库权限申请单》，经DBA与安全组双签审批
