优先选PostgreSQL协议连接，pgx或database/sql可直接复用SQL逻辑；ILP写入吞吐更高但需自行处理协议、缓冲与重试；建表必须显式指定TIMESTAMP(ts)才能支持时间查询与分区剪枝。
QuestDB连接方式选PostgreSQL协议还是ILP？
直接用PostgreSQL协议连接最省事，pgx或database/sql + lib/pq就能跑通，适合已有SQL查询逻辑的微服务。InfluxDB Line Protocol（ILP）写入吞吐更高，但得自己拼协议、处理批量缓冲和重试——除非你每秒要灌几十万点，否则没必要过早切换。
常见错误现象：failed to connect: dial tcp 127.0.0.1:8812: connect: connection refused，说明QuestDB没启动，或端口没映射对（Docker默认暴露8812，不是5432）；ERROR: column "time" does not exist则大概率是建表时没用TIMESTAMP()指定时间列，导致SQL里用WHERE time > ...失败。
- 确认QuestDB已运行：
docker ps | grep questdb，确保状态为Up - 连接字符串示例：
postgresql://admin:quest@localhost:8812/qdb?sslmode=disable（QuestDB默认无密码，admin是默认用户） - 若用ILP，务必启用
ilp.min.bind.to配置项，并监听9009端口
建表必须显式声明TIMESTAMP列
QuestDB不是“自动识别time字段”，必须在CREATE TABLE语句里用TIMESTAMP(列名)明确标记——否则后续所有基于时间范围的查询、分区剪枝、窗口函数都会失效，甚至插入数据会报错timestamp column not found。
使用场景：设备上报温度、CPU指标、HTTP延迟等带毫秒级时间戳的数据。别用now()或数据库服务端时间，必须把客户端采集的真实时间戳传进来。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 正确写法：
CREATE TABLE metrics (ts TIMESTAMP, host SYMBOL, cpu DOUBLE, mem_mb LONG) TIMESTAMP(ts) - 错误写法：
CREATE TABLE metrics (ts TIMESTAMP, ...)（缺TIMESTAMP(ts)子句） - 时间精度建议用
TIMESTAMP类型（纳秒级），避免用DATE或STRING存时间，否则无法做高效范围扫描
Golang写入时如何避免慢查询拖垮服务
QuestDB的写入本身极快，但Golang里如果每条记录都db.Exec("INSERT ...")，网络往返+事务开销会吃掉大部分性能。真正卡住的不是QuestDB，而是你的Go代码。
参数差异：单条INSERT耗时约1–5ms（含网络），批量INSERT（100–1000行/批）可压到0.1ms/行；用ILP协议能再提速3–5倍，但需要额外维护连接池和缓冲区。
- 用
pgx.Batch批量提交，而非循环Exec：b := &pgx.Batch{}; for _, m := range metrics { b.Queue("INSERT INTO ...", m.ts, m.host, m.cpu) }; db.SendBatch(ctx, b) - 避免在HTTP handler里直接写库，改用异步队列（如
chan []Metric+ worker goroutine）控制背压 - 监控
pgx连接池等待时间，超时设为3s以内，防止一个慢查询阻塞整个goroutine池
查询时别忽略分区裁剪的实际效果
QuestDB按时间自动分区（小时/天/月），但前提是WHERE条件里必须用ts >= '2026-06-29' AND ts 这类可推导的范围表达式。写成<code>date(ts) = '2026-06-29'或extract(year from ts) = 2026会导致全表扫描——因为函数调用破坏了分区键的可推导性。
性能影响明显：查1天数据从20ms跳到2s以上，尤其当表有几百GB历史数据时。QuestDB Web控制台的EXPLAIN结果里，如果看到Partition count: all就说明裁剪失效了。
- 始终用原生时间比较：
WHERE ts BETWEEN '2026-06-29T00:00:00Z' AND '2026-06-29T23:59:59Z' - 避免在时间列上做任何计算：
ts + 1h、to_timestamp(...)都会让优化器放弃裁剪 - 高频查询字段（如
host）可建SYMBOL索引，但别滥用——每个SYMBOL列会额外占用内存
