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