mysql开发环境和生产环境权限如何区分_mysql规范建议

开发环境账号仅授 SELECT/INSERT/UPDATE/DELETE 权限，禁用 DDL；生产环境按最小权限拆分账号，严格管控 information_schema 与 performance_schema 访问，权限变更须走 SQL 流程并版本化管理。

开发环境 账号只给 SELECT、INSERT、UPDATE、DELETE，禁用 DROP、CREATE、ALTER

开发环境不是沙盒，但必须当作沙盒用。很多团队误以为“本地连的是测试库就随便操作”，结果 mysql -u dev -p -h test-db 登进去随手 DROP TABLE user_log_2023，第二天发现日志归档脚本崩了——因为表结构被删了，而下游服务没做兜底。

实操建议：

• 建库时统一用 CREATE DATABASE dev_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;，之后只授权给开发账号 GRANT SELECT, INSERT, UPDATE, DELETE ON dev_db.* TO 'dev'@'%';
• 禁止授予 GRANT OPTION，避免开发账号再转授权限
• 开发账号密码不存入项目 配置文件 ，改用 环境变量 或密钥管理 工具 注入，防止误提交到 Git
• 如果用 Docker 启动 MySQL，可在 docker-compose.yml 的 command 里加 --skip-grant-tables 仅限本地调试（切记不可用于任何网络可访问的容器）

生产环境账号按最小权限原则拆分，严禁使用 root 或 super 权限应用连接

线上 application.properties 里写 spring.datasource.username=root 是高危行为。哪怕密码再强，一旦应用层有 SQL 注入或日志泄露，攻击者就能直接 SHOW MASTER STATUS 拿到 binlog 位置，甚至 SET GLOBAL read_only=OFF 开启写权限。

实操建议：

• 读写分离场景下，应用连接至少两个账号：app_rw（仅业务库 INSERT/UPDATE/DELETE/SELECT）和 app_ro（只读从库，SELECT + SHOW 类元数据查询）
• 备份账号单独建，只赋予 RELOAD、LOCK TABLES、REPLICATION CLIENT，且限制来源 IP（如 'backup'@'10.10.20.5'）
• DBA 管理账号用 mysql_native_password 插件认证，禁用 caching_sha2_password（老版本客户端兼容问题多，反而导致临时改密失败）
• 检查现有账号权限：执行 SELECT User, Host, authentication_string FROM mysql.user WHERE User NOT IN ('mysql.session', 'mysql.sys', 'root');，确认无明文密码字段残留

information_schema 和 performance_schema 的访问需显式控制

默认情况下，普通账号能查 information_schema.TABLES，这会暴露所有库名、表名、行数估算值。在 金融 或 SaaS 多租户场景中，一个租户可能通过 SELECT table_name FROM information_schema.TABLES WHERE table_schema = 'tenant_123' 推断出其他租户存在，构成信息泄露。

实操建议：

• MySQL 8.0+ 可用 CREATE ROLE 'schema_reader'; GRANT SELECT ON information_schema.TABLES TO 'schema_reader';，再把该 role 授予必要人员，而非开放全局 SELECT
• 若用 MySQL 5.7，只能靠应用层拦截关键词（如禁止 SQL 中含 information_schema），但更稳妥的做法是代理层（如 ProxySQL）重写或拒绝这类查询
• performance_schema 默认对所有用户只读，但某些表（如 events_statements_history_long）可能暴露完整 SQL 文本，建议用 SET GLOBAL performance_schema = OFF; 关闭，除非真有性能诊断需求

权限变更必须走 SQL 变更流程，禁止手工 GRANT / REVOKE

有人在凌晨两点紧急修复 bug，顺手 GRANT ALTER ON prod_db.order TO 'dev'@'%';，忘了回收——三个月后安全审计扫出该账号仍有 DDL 权限，而当时那个临时需求早已下线。

实操建议：

• 所有权限变更必须提交 SQL 文件到版本库，命名如 20240521_add_alter_to_dev.sql，内容包含 GRANT 和对应的 REVOKE 回滚语句，并注明有效期（如“仅限 2024-05-21 至 2024-05-23”）
• 用 mysqldump --no-data --routines --triggers mysql 定期导出权限快照，与 Git 历史比对，发现未走流程的权限漂移
• 在 CI 流程中加入检查：扫描提交的 SQL 文件是否含 GRANT ALL PRIVILEGES、WITH GRANT OPTION，自动阻断合并

权限不是设一次就完事的事。最常被忽略的是账号生命周期管理——开发离职后，其账号是否还在 mysql.user 表里？有没有人悄悄用 % 通配符建过 'admin'@'%' 这种高危账号？这些细节比“要不要开 audit log”更决定系统实际防线厚度。