ClickHouse写入慢的主因是未正确使用clickhouse-go批量模式：须用conn.PrepareBatch()获取Batch对象，以列式切片调用batch.Append()并手动控制batch.Send()时机，避免单条插入、结构体传参、内存溢出、时区错配及并发block碎片化。
ClickHouse写入慢？别急着换驱动，先看clickhouse-go的批量模式怎么开
默认用conn.Exec()逐条插入，10万行可能要几十秒；换成批量写入，通常能压到1秒内。关键不是“能不能”，而是stmt.Exec()和batch.Append()两种路径选错——前者仍是单条模拟，后者才是真批量。
- 必须用
conn.PrepareBatch()获取Batch对象，不是conn.Prepare() -
batch.Append()不触发网络发送，攒够再调batch.Send()，否则每append都发一次包 - 列式写入要求数据按列组织：比如写两列
id和name，得传两个切片[]int64和[]string，不能传[]struct{ID int64; Name string} - 常见错误：
batch.Append(row...)传结构体字段值——会panic：“cannot convert struct to []interface{}”
大批量写入时内存爆了？batch没设上限是主因
clickhouse-go的Batch默认不限制缓冲大小，100万行字符串可能吃掉2GB内存。它不自动分块，全靠你控制Send()时机。
- 按行数分批：每5000–10000行
batch.Send()一次，避免OOM - 按字节估算：用
len([]byte(s))粗略算单行长度，总缓存建议≤16MB（ClickHouse服务端默认max_insert_block_size=1048576） - 别依赖
defer batch.Send()——函数退出才发，中间内存一直占着 - 错误现象：
runtime: out of memory或GC频繁卡顿，pprof能看到github.com/ClickHouse/clickhouse-go/v2.Batch实例暴涨
为什么time.Time写入后变成1970-01-01？时区和类型映射没对齐
ClickHouse的DateTime和DateTime64字段在Go里必须配time.Time，但驱动默认按UTC解析；如果表定义是DateTime('Asia/Shanghai')，而Go传的是本地时间且未指定Location，就会偏移8小时甚至归零。
- 写入前统一转UTC：
t.In(time.UTC)，或按表定义的时区转：t.In(loc)（需提前time.LoadLocation("Asia/Shanghai")） - 确认表字段类型：用
DESCRIBE TABLE查实际类型，DateTimevsDateTime64(3)影响time.Time精度匹配 - 避免用
int64时间戳直接Append()——驱动不会自动转成DateTime，会当普通整数插进去 - 典型错误：
INSERT成功但查出来全是1970-01-01 00:00:00，多半是时区没处理
并发写ClickHouse反而更慢？连接池和block size冲突了
开10个goroutine各持一个Batch往同一张表写，性能可能比单协程还差——ClickHouse服务端对并发insert有锁竞争，尤其当max_insert_block_size设得太小，每个batch被切成大量小block，调度开销反超收益。
立即学习“go语言免费学习笔记（深入）”；
- 优先横向扩展：单个
Batch写满再Send()，比多个小batch并发更稳 - 调整服务端参数：
SET max_insert_block_size = 100000（会话级）或改配置文件，减少block切分次数 - 连接池别盲目加大：
sql.Open("clickhouse", "...&max_open_conns=20")不如保证每个conn专注一个大batch - 验证方法：看ClickHouse日志里的
QueryPipelineExplain，如果出现大量CreatingSource和MergingSorted，说明block太碎
最易忽略的是列式写入的数据组织方式——它不接受结构体切片，也不自动解构，所有字段必须提前拆成平行切片。这点和PostgreSQL驱动完全不同，硬套习惯会卡死在第一步。
