MySQL不支持服务端自动执行初始化SQL，需通过客户端参数（如--init-command）、JDBC URL配置、驱动init_command等在连接建立时注入；连接池复用场景下必须额外校验或封装工厂函数确保每次获取连接后执行。
MySQL 连接建立后自动执行初始化 SQL 的几种方式
mysql 本身不支持“每次连接都自动跑一段 sql”，但可以通过客户端配置、驱动参数或代理层间接实现。核心思路是：把初始化逻辑塞进连接建立流程里，而不是依赖服务端自动触发。
常见错误现象：SET NAMES utf8mb4 没生效、sql_mode 被重置、自定义变量（如 @tenant_id）在应用首次查询前未设置，导致后续语句行为异常。
- 命令行客户端（
mysql）可用--init-command参数，例如：mysql --init-command="SET NAMES utf8mb4; SET @env='prod'" -h db1.example.com -u app - Java JDBC URL 中加
sessionVariables或initCommand，例如：jdbc:mysql://db2.example.com:3306/app?sessionVariables=sql_mode='STRICT_TRANS_TABLES',autocommit=0 - Python 的
pymysql支持init_command参数：connect(..., init_command="SET @user_role='admin'")；mysql-connector-python则用connection_attributes+ 配合post_connect回调（需手动封装） - 注意：某些 ORM（如 SQLAlchemy）会复用连接，且可能在连接池取到已存在连接时跳过初始化 —— 此时必须靠连接池的
creator或pool_pre_ping配合显式重置
PostgreSQL 中用 options 或 application_name 触发初始化逻辑
PostgreSQL 没有等价于 MySQL 的 --init-command，但可通过 options 参数传入启动选项，再配合 postgresql.conf 中的 local_preload_libraries 或 shared_preload_libraries + 自定义扩展拦截连接，不过这太重，一般不推荐。
更实际的做法是：在应用层连接后立刻执行 SET 语句，并确保该操作和后续业务查询在同一个事务/连接上下文中完成。
- libpq（C）可用
PQconnectdb("host=db3 options='-c search_path=app_v2 -c application_name=myapp-backend'")，但options只能传 GUC 参数，不能执行任意 SQL - Python 的
psycopg2支持options，也支持连接后立即执行cursor.execute("SET LOCAL ...")；注意SET LOCAL只对当前事务有效，SET才作用于整个连接 - Node.js 的
pg库可在client.connect()后立刻await client.query("SET timezone = 'Asia/Shanghai'")，但要防止单独连接未复用时漏掉 —— 建议封装成createClient()工厂函数统一处理
连接池场景下如何避免初始化被跳过
连接池（如 HikariCP、pgbouncer、ProxySQL）会让“新连接”和“复用连接”行为不一致。初始化 SQL 如果只在物理连接建立时执行，复用连接就完全不会触发，这是最常踩的坑。
- HikariCP 的
connection-init-sql配置项仅在连接创建时执行一次，不适用于连接复用后的状态清理 —— 必须配合connection-test-query+ 自定义验证逻辑来补救 - pgbouncer 在
transaction模式下根本不允许连接级变量（如SET myvar = 1），因为连接被多个客户端共享；改用session模式，或彻底放弃连接级变量，改用函数参数或表字段传递上下文 - 如果必须在每次获取连接后运行初始化，不要依赖驱动自动机制，而是在业务代码中抽象出
withFreshConnection()函数，内部强制SET+ 查询前校验
环境变量与 SQL 级别参数混用的风险点
很多人试图用操作系统环境变量（如 ENV=staging）去控制 SQL 初始化内容，但这容易失效 —— 因为环境变量只在进程启动时读取，而连接可能跨进程、跨容器、跨用户上下文。
- MySQL 的
init_connect系统变量虽可设全局初始化 SQL，但它对super用户无效，且无法区分不同应用连接，所有普通连接都会执行，容易引发冲突 - PostgreSQL 的
ALTER USER ... SET可设默认值（如ALTER USER app_user SET application_name = 'backend'），但这是静态配置，不能动态传参 - 真正需要“按服务器切换行为”的场景，应把初始化逻辑下沉到应用配置中心（如 Consul、Nacos），连接字符串和初始化 SQL 都从配置拉取，而非硬编码或靠环境变量推断
复杂点在于：初始化不是“做一次就完事”，它得和连接生命周期对齐，还得扛住连接复用、连接中断重试、多租户隔离这些现实压力。最容易被忽略的是——你以为设置了 @region='us-west'，其实那个连接早就被别人用过了，变量还是上个请求留下的旧值。
