应以 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 报错，第一反应常是“配置错了”，其实只是没意识到自己连的是只读节点——这种混淆，比连错环境更隐蔽。
