开发环境用 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、配置文件路径，四个维度只要一个对不上，就可能把开发语句跑进生产表里。
