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，便于事后追溯越权行为
