生产环境必须禁用dev_user账号，因其存在严重安全风险；应严格分离环境账号、限定IP、最小化权限、凭证动态获取、权限变更审计并定期检查继承关系。
开发环境用 dev_user，生产环境必须禁用该账号
开发账号在生产库上留着，等于把钥匙挂在门把手上。哪怕只读权限，也可能被误执行 SELECT * FROM users 拖垮主库；更别说有人顺手连错环境跑了个 DROP TABLE。真实事故里，80% 的线上数据异常源于开发账号未清理或权限未回收。
实操建议：
- 上线前自动化检查：用
SELECT user, host FROM mysql.user WHERE user = 'dev_user';扫描所有生产实例，脚本失败即阻断发布 - 禁止跨环境复用账号名——
dev_user和prod_app必须是两个独立账号，不能靠密码不同区分 - MySQL 8.0+ 可用
CREATE USER 'dev_user'@'192.168.1.%' IDENTIFIED BY 'xxx';显式限定 IP 段，避免泛解析主机名（如'%'）放行所有来源
GRANT 语句必须按环境写死权限粒度
开发环境给 ALL PRIVILEGES 看似省事，但会掩盖应用真实依赖的最小权限。比如一个只查订单的服务，在开发库有 DROP 权，上线后因权限不足报错，却要倒推排查哪条 SQL 触发了隐式元数据操作。
实操建议：
- 开发环境也只开必需权限：
SELECT, INSERT, UPDATE, DELETE, CREATE TEMPORARY TABLES，禁用DROP、ALTER、INDEX - 生产环境严格按角色授权：
prod_app只有SELECT, INSERT, UPDATE；prod_migrate单独存在，且仅在迁移窗口期启用ALTER - 避免用
GRANT ... ON *.*—— 明确到库：GRANT SELECT ON myapp_production.* TO 'prod_app'@'%';
连接字符串里的账号不能硬编码，也不能进 Git
看到 mysql://dev_user:pass@db/... 出现在 config.yml 或 .env 里，基本等于把凭证塞进公开仓库。扫描工具一跑，dev_user 密码就进了黑客的字典。
实操建议：
- 开发环境用本地密钥管理器（如 macOS Keychain / Windows Credential Manager），代码中调用
security find-generic-password或cmdkey动态取值 - 生产环境强制走配置中心（Consul / Vault），应用启动时拉取
prod_app凭证，不落地、不缓存明文 - CI/CD 流水线中，禁止任何
.env文件提交，用git secrets预检钩子拦截含user=、password=的行
权限变更必须走审计日志 + 变更窗口控制
DBA 手动执行 GRANT 后没记录，过两周谁也说不清为什么 prod_app 突然有了 FILE 权限——而这个权限恰好被新上线的导出功能滥用，导致敏感文件泄露。
实操建议：
- MySQL 开启
general_log或用audit_log插件，确保每条GRANT/REVOKE写入独立日志表，并关联操作人邮箱 - 非紧急变更只允许在每周三 22:00–24:00 执行，且需二次确认：
SET SESSION sql_log_bin = OFF;不影响主从同步，但必须人工输入CONFIRM_GRANT才放行 - 定期用
SELECT * FROM mysql.role_edges;检查角色继承链，防止dev_admin被意外加进prod_role
最常被忽略的是权限继承关系和主机名匹配逻辑——'dev_user'@'localhost' 和 'dev_user'@'127.0.0.1' 是两个账号，连本地 socket 和 TCP 是不同认证路径，漏掉任一个都可能让隔离失效。
