应以 host + port + database 三元组是否指向同一物理实例并明确标记环境为准；dev 用本地或 Docker，test 用内网域名和非标端口，prod 强制 SSL 并走代理；my.cnf 按环境分段配置，启动时校验 hostname、server_uuid 和 DATABASE() 后缀；避免仅依赖 SHOW VARIABLES。

MySQL 连接参数里怎么区分环境？

靠数据库名、用户名或 host 区分环境不可靠，真正有效的判断依据是 host + port + database 三元组是否指向同一套物理实例，以及该实例是否被明确标记为某类环境。很多团队误把 test_db 当作测试库，结果它连的是生产实例的副本——数据没动，但查询压垮了主库。

• dev 环境通常用本地 127.0.0.1:3306 或 Docker 容器（如 mysql-dev:3306），database 名常带 _dev 后缀
• test 环境一般走独立服务器或 K8s 命名空间，host 是固定内网域名（如 mysql-test.internal），port 可能非标准（如 3307）以隔离流量
• prod 环境必须强制启用 SSL，并禁用 root@% 这类宽泛账号；连接字符串中 host 应为 VIP 或读写分离代理地址（如 mysql-prod-proxy），而非真实主库 IP

my.cnf 里怎么配置不同环境的启动行为？

单靠运行时传参不够，my.cnf 的配置段落才是环境行为的源头。MySQL 启动时会按顺序加载 [mysqld]、[client] 等节，而环境差异往往体现在 [mysqld] 下的参数组合上。

• 开发环境可加 skip_log_bin = 1 和 innodb_flush_log_at_trx_commit = 2 加速本地事务，但上线前必须删掉
• 测试环境建议开启 slow_query_log = 1 并设 long_query_time = 1，便于暴露低效 SQL
• 生产环境必须设置 max_connections = 500（根据规格调整）、wait_timeout = 300，并关闭 query_cache_type（MySQL 8.0+ 已移除）

[mysqld]
# 开发专用
skip_log_bin = 1
innodb_flush_log_at_trx_commit = 2
测试专用
slow_query_log = 1
long_query_time = 1
生产专用（不能和上面混用）
max_connections = 500
wait_timeout = 300

如何防止代码里误连错环境？

最常见错误是硬编码 "localhost" 或用 os.getenv("DB_HOST") 却没校验值合法性。正确做法是在应用启动时做环境指纹校验，而不是只信配置来源。

• 读取 DB_ENV 环境变量后，立刻查表 SELECT @@hostname, @@version_compile_os，比对预期值
• 在连接池初始化时执行 SELECT DATABASE()，确保当前 database 名符合环境后缀规则（如 prod 环境必须匹配 .*_prod$）
• 禁止在代码里拼接 SQL 判断环境，例如 "SELECT 'dev' FROM dual WHERE @@port = 3306" —— 这种逻辑会随 MySQL 版本失效

为什么 SHOW VARIABLES 不足以确认环境类型？

SHOW VARIABLES 返回的是实例当前配置，但配置可能被动态修改（如 SET GLOBAL max_connections = 1000），且无法反映部署拓扑。一个被标记为 test 的实例，可能因故障临时接管了 prod 流量，此时它的 max_connections 值反而接近生产配置。

• 真正可靠的环境标识应来自外部系统：K8s 的 namespace、Consul 的 service.tags、或 CMDB 中的 env_type 字段
• SELECT @@hostname 只能告诉你机器名，而 SELECT @@server_uuid 才是实例唯一 ID，可用于比对 CMDB 记录
• 如果使用 ProxySQL 或 Vitess，必须检查 SELECT * FROM runtime_mysql_servers，因为实际路由目标可能和连接字符串不一致

环境划分不是命名游戏，而是控制面与数据面的对齐。最容易被忽略的是：当使用主从复制时，read_only = ON 在从库生效，但开发人员连上从库执行 INSERT 报错，第一反应常是“配置错了”，其实只是没意识到自己连的是只读节点——这种混淆，比连错环境更隐蔽。