GORM默认配置导致高频握手，因SetMaxOpenConns(0)不限连接数、SetMaxIdleConns(2)空闲连接过少、SetConnMaxLifetime(0)连接永不过期，致使每次请求频繁触发TCP/SSL/认证握手；须显式调db.DB()设三参数并Ping校验。
必须显式调用 db.DB() 获取原生 *sql.DB，再设置连接池参数；GORM 本身不管理连接，只包装它——不手动配置，就永远在重复 TCP 握手和 MySQL 认证。
为什么 GORM 默认配置会导致高频握手
GORM 的 gorm.Open() 返回的是 *gorm.DB，它底层依赖 database/sql 的连接池，但默认参数完全不适合生产：
-
SetMaxOpenConns(0)：不限制最大连接数，MySQL 服务端被撑爆前，新连接不断触发三次握手 + SSL 协商 + auth handshake -
SetMaxIdleConns(2)：空闲连接太少，高并发下几乎每个请求都得新建连接，每次新建都含完整握手链路 -
SetConnMaxLifetime(0)：连接永不过期，MySQL 主动断连（如 wait_timeout 触发）后，GORM 下次复用该连接时会先失败重试，再重连——等于把一次握手变成两次
怎么设 *sql.DB 参数才能压住握手频率
关键不是“多开连接”，而是让连接够用、能复用、不死僵：
- 调
db.DB().SetMaxIdleConns(20)：保证常驻 20 条空闲连接，90% 请求直接从池里取，跳过握手 - 设
db.DB().SetMaxOpenConns(100)：按峰值 QPS × 平均查询耗时（秒）× 1.2 估算，避免连接争抢导致排队等待 - 配
db.DB().SetConnMaxLifetime(3 * time.Minute)：强制连接在 3 分钟内轮换，避开 MySQL 的wait_timeout（通常 8 小时）导致的被动断连 - 务必加
db.Ping()：启动时验证连接通路，否则第一个请求才暴露握手失败，日志里只看到dial tcp: i/o timeout或auth plugin not supported
哪些场景下握手开销会被放大
不是所有请求都平等消耗握手资源，以下情况会让问题更明显：
- 短生命周期服务（如 AWS Lambda、Knative）：每次冷启都重建连接池，
SetMaxIdleConns彻底失效 - 跨可用区部署（如应用在 us-east-1，RDS 在 us-west-2）：单次 TCP 握手延迟从 1ms 拉到 60ms+，放大 60 倍
- 启用了 TLS（尤其是 mutual TLS）：握手阶段增加证书交换与验签，耗时翻倍甚至更多
- MySQL 配置了
skip-name-resolve=OFF：每次连接还要做 DNS 反查，遇到 DNS 延迟或超时直接卡死
真正起效的永远是那三行：db.DB().SetMaxIdleConns()、SetMaxOpenConns()、SetConnMaxLifetime()。漏掉任意一个，连接池就只是个摆设，你写的每条 db.First(&u) 都可能在后台偷偷重做一次握手。
