ClickHouse连接池无需自行管理，clickhouse-go/v2默认内置连接池，支持TCP复用、自动重连和上下文超时控制；直接使用sql.Open即可，通过SetMaxOpenConns和SetMaxIdleConns调节，避免DSN漏写compress=true或忽略context超时导致性能与稳定性问题。
ClickHouse 连接池要不要自己管？
不用自己维护连接池，clickhouse-go v2 默认就带连接池，且行为比手动封装更可靠。它默认复用 TCP 连接、自动重连、支持上下文超时控制，直接用 sql.Open("clickhouse", dsn) 就行。
容易踩的坑：
- 误以为要像 PostgreSQL 那样手动建 pool —— 实际上
clickhouse-go的*sql.DB本身就是带池的，调SetMaxOpenConns和SetMaxIdleConns即可调控 - DSN 中漏写
?compress=true—— 导致亿级结果集网络传输慢 3–5 倍，尤其导出 CSV 时明显卡顿 - 没设
context.WithTimeout—— 单条慢查询（比如漏加 WHERE）会阻塞整个 HTTP handler，Gin 里必须显式传 context
Gin HTTP handler 怎么安全读取 ClickHouse 大结果集？
别用 rows.Scan() 逐行解包，也别一次性 rows.Columns() + rows.Values() 全加载进内存 —— 亿级数据下 Go runtime 会 OOM。
正确做法是流式处理：
- 用
rows.Next()+rows.Scan(dest...)循环读，每轮只 hold 一行数据 - 导出 CSV 时直接写入
c.Writer，配合bufio.NewWriterSize(c.Writer, 1 提升吞吐 - 对聚合类查询（如 GROUP BY + COUNT），务必加
LIMIT或用WHERE event_time >= ? AND event_time 控制范围，避免全表扫
示例关键片段：
UInt64
- 查询层：用
rows.ColumnTypes()拿到字段类型名，对UInt64字段手动转string，对DateTime字段统一转 UTC 时间戳或 ISO8601 字符串 - 结构体层：定义 struct 时字段类型用
string或int64，配合json.Marshaler接口定制序列化逻辑（比如type Timestamp int64实现MarshalJSON） - 千万别依赖
database/sql的泛型扫描（Scan(&v)）自动转 —— 它对 ClickHouse 特有类型支持弱，容易 panic
为什么用 Gin 跑 ClickHouse 查询偶尔返回空数组但没报错？
常见原因是 ClickHouse 的 http:// 接口（非 native 协议）在 timeout 或网络抖动时静默返回空响应，而 clickhouse-go 默认走的是 native TCP 协议（tcp://），但如果误配成 http:// 或用了不兼容的 driver，就会出现这种“成功但无数据”的假象。
排查要点：
- 检查 DSN 是否以
tcp://开头（如tcp://127.0.0.1:9000?database=default），不是http:// - 确认
clickhouse-go版本 ≥ v2.8.0 —— 旧版本对DateTime64和嵌套数组支持不全，某些查询会静默失败 - 开启 driver 日志：
clickhouse.Settings{"log_level": clickhouse.LogLevelDebug}，看底层是否收到完整 response packet
真正稳定的做法，是始终用 native 协议 + 显式 context 超时 + 检查 rows.Err() 而不只是 rows.Next() 的布尔值。
