MySQL环境权限管控需账号隔离、最小权限与环境标识三者结合：按环境建独立账号并限制IP与库权限，生产账号禁用DROP/ALTER等高危权限，DBA分级授权，库名统一前缀隔离，配合接入层校验与审计日志。

MySQL 中区分开发与生产环境权限，核心是通过账号隔离 + 权限最小化 + 环境标识约束来实现，不能仅靠命名习惯或人工约定，必须由数据库层面强制管控。

按环境创建独立账号

为开发、测试、预发、生产等环境分别创建专用账号，禁止跨环境复用。例如：

• dev_app@'10.10.%'：仅允许从开发网段连接，仅授予开发库（如 app_dev）的 SELECT, INSERT, UPDATE, DELETE 权限
• prod_app@'10.20.%'：仅允许从生产应用服务器 IP 段连接，仅授予生产库（如 app_prod）的 SELECT, INSERT, UPDATE 权限，默认禁用 DROP、TRUNCATE、ALTER、CREATE
• 生产账号不赋予 GRANT OPTION，禁止授权传播

严格限制高危操作权限

生产账号应主动剥离可能引发事故的权限，而非依赖“不乱执行”的自觉：

• 显式回收：REVOKE DROP, ALTER, CREATE, INDEX, FILE, PROCESS, SUPER, REPLICATION CLIENT ON *.* FROM 'prod_app'@'%';
• 避免使用 ALL PRIVILEGES 授权，始终用具体权限列表
• 对 DBA 账号也做分级：日常运维用 dba_ops（无 SUPER），紧急修复才启用 dba_root（需二次认证或临时开通）

利用数据库名前缀或 schema 隔离

在建库阶段就固化环境边界，降低误操作风险：

• 统一命名规范：如 app_dev、app_test、app_prod，禁止裸名 app
• 开发账号无法访问 app_prod 库，即使连错实例也无法查/改生产数据
• 配合 MySQL 8.0+ 的 partial_revokes（需开启），可实现“全局权限下精确排除某库”

接入层强化环境校验（可选但推荐）

单靠数据库权限不够，建议在应用连接池或中间件中增加环境标识检查：

• 应用启动时读取配置中的 env=prod，并校验所连 MySQL 实例的 @@hostname 或自定义变量（如 SELECT @@global.env_tag;）是否匹配
• 中间件（如 MyCat、ProxySQL）根据用户前缀自动路由或拦截非授权操作
• 审计日志中固定记录 user + host + db + command，便于事后追溯越权行为