查询卡顿但无报错，常见因连接池耗尽、网络延迟、驱动配置不当（如 timeout 设置过长）或 sql 在客户端快而应用端慢（如未复用连接、预处理缺失）。
为什么 database/sql 查询看起来卡顿，但实际没报错？
常见现象是：SQL 在 MySQL 客户端执行很快（db.QueryRow() 却要 200ms+，且无超时或错误。这通常不是 SQL 本身慢，而是连接建立或复用出了问题。
- 默认
db.SetMaxOpenConns(0)（即不限制），但底层连接池初始为空，首次查询需完整 TCP 握手 + TLS（若启用）+ 认证，耗时集中在这一轮 - MySQL 默认 wait_timeout=8小时，但中间网络设备（如 NAT 网关、云厂商 LB）可能 60–300 秒就静默断连，Go 的
database/sql不主动探测空闲连接是否存活，下次复用时才报错并重连——表现为“偶发性延迟尖刺” - 解决方法：显式配置连接池 + 启用连接健康检查
db.SetMaxOpenConns(20) db.SetMaxIdleConns(10) db.SetConnMaxLifetime(3 * time.Hour) // 避免被中间设备踢掉 db.SetConnMaxIdleTime(30 * time.Second) // 主动回收空闲太久的连接
Scan() 太慢？别直接扫 struct，优先用字段索引
用 rows.Scan(&u.ID, &u.Name, &u.Email) 比 rows.Scan(&u)（struct tag 映射）快 15–30%，尤其字段多于 5 个时。反射开销在高频查询中不可忽略。
- struct 扫描需 runtime 获取字段名、匹配列名、类型转换校验；而位置扫描直接按顺序绑定，零反射
- 如果必须用 struct（比如 ORM 场景），确保
db.Query()返回的列顺序与 struct 字段声明顺序严格一致，否则会 silently 赋错值 - 避免
sql.NullString等 wrapper 类型嵌套过深——每层额外接口判断和指针解引用都会叠加微小延迟
批量插入为何比单条还慢？检查 Exec() 是否被自动拆成多语句
写 INSERT INTO users VALUES (?, ?), (?, ?), (?, ?) 本应是一次网络往返，但如果驱动或 MySQL 配置不当，可能被拆成 3 次单条 INSERT 执行。
