开发与生产环境须严格分离：使用不同库名（如myapp_dev/myapp）、限定账号主机名、禁用远程root、配置bind-address及敏感参数按环境区分，并通过环境变量注入库名和运行时校验防止误操作。
开发环境用 localhost 限制访问范围
开发机通常只允许本机连接，避免误连生产库或被局域网其他设备探测。mysql 默认的 root@localhost 账号权限过大，不建议直接用于应用连接；应新建账号并显式限定主机名。
- 创建开发账号：
CREATE USER 'devuser'@'localhost' IDENTifIED BY 'devpass123'; - 仅授予必要库权限：
GRANT select, INSERT, UPDATE, delete ON `myapp_dev`.* TO 'devuser'@'localhost'; - 禁止远程登录：
DROP USER IF EXISTS 'devuser'@'%';（防止通配符覆盖） - 开发配置中数据库地址写死为
127.0.0.1或localhost，注意二者在 MySQL 中行为不同：localhost触发 socket 连接，127.0.0.1走 TCP，后者可能绕过@localhost规则
生产环境禁用 root 远程登录且拆分权限
生产库必须关闭所有高危账户的远程访问能力，并按角色最小化授权。常见错误是保留 root@% 或用同一账号跑前后端服务。
- 立即回收远程 root：
DROP USER IF EXISTS 'root'@'%';，确认只剩root@localhost - 按功能建账号：如
app_rw@'10.20.30.%'（应用读写）、backup@'192.168.1.100'（备份专用 IP）、monitor@'10.0.0.5'（zabbix 监控节点） - 避免跨库授权：
GRANT SELECT ON `orders`.* TO 'report_user'@'%';比GRANT SELECT ON *.*安全得多 - 生产配置中的
host必须是内网 IP 段，绝不能是%或公网地址；若用容器部署，需检查宿主机防火墙 + MySQL bind-address 是否双层限制
用不同数据库名物理隔离开发与生产数据
靠账号权限无法完全防止误操作（比如 dev 账号连错 host 后删了 prod 表），最稳妥的是让开发和生产使用不同库名，从源头降低风险。
- 约定命名规范：开发库统一加
_dev后缀（myapp_dev），测试库用_test，生产库用无后缀名（myapp） - 应用启动时通过环境变量注入库名：
DB_NAME=${ENVIRONMENT}_db，而非硬编码myapp - 执行 SQL 迁移脚本前加校验：
SELECT database();确认当前库名是否符合预期，不符合则退出 - 不要依赖 MySQL 的
sql_mode差异做环境区分——它不阻止 DML，也不防 DROP TABLE
my.cnf 配置文件按环境拆分并禁止上传到代码仓库
MySQL 主配置本身也需环境差异化，尤其是日志、缓存、超时等参数；但更关键的是避免敏感配置泄露。
- 生产
my.cnf关闭 query log：general_log = 0，调低slow_query_log阈值（如long_query_time = 0.5） - 开发环境可开启
log_error_verbosity = 3方便调试，但禁止在生产启用 -
bind-address开发设为127.0.0.1，生产设为内网 IP（如10.20.30.10），绝不可写0.0.0.0 - 所有含密码或 IP 的配置项（如
[client]段）必须从my.cnf剥离，改用运行时传参或独立.mylogin.cnf（并chmod 600）
环境分离真正的难点不在语法，而在于每次部署、迁移、排查问题时，人是否会下意识忽略当前连接的是哪个实例——库名、账号、IP、配置文件路径，四个维度只要一个对不上，就可能把开发语句跑进生产表里。