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 <h1>测试专用</h1><p>slow_query_log = 1 long_query_time = 1</p><h1>生产专用（不能和上面混用）</h1><p>max_connections = 500 wait_timeout = 300</p>
如何防止代码里误连错环境？
最常见错误是硬编码
"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报错，第一反应常是“配置错了”，其实只是没意识到自己连的是只读节点——这种混淆，比连错环境更隐蔽。
