直接使用 github.com/jackc/pgx/v5 而非 database/sql + pgx 驱动，因其支持 pg 原生二进制协议、自定义类型注册（如 timestamptz、double precision[]）及 pgxpool 连接复用，避免抽象层导致的性能损耗与类型解析错误。
为什么直接用 github.com/jackc/pgx/v5 而不是 database/sql + pgx 驱动
TimescaleDB 是 PostgreSQL 的扩展，本质仍是 PG 协议通信，但工业 IoT 场景下高频写入（如每秒万级 metric 点）、批量压缩、连续聚合等特性，对底层连接效率和类型支持要求更高。database/sql 抽象层会丢失 pgx 原生的二进制协议支持、自定义类型注册能力（比如 timestamptz、DOUBLE PRECISION[] 数组），还可能让 pgxpool 的连接复用失效。
实操建议：
- 用
pgxpool.Pool替代sql.DB，显式启用二进制参数传输：pgxpool.Config.ConnConfig.PreferSimpleProtocol = false - 注册 TimescaleDB 特有类型，例如 hypertable 的
time_bucket返回值是timestamptz，需确保pgx能正确解析为time.Time - 避免在
Scan时用interface{}接收时间列，改用*time.Time或pgtype.Timestamptz显式类型
写入时如何避免 “duplicate key violates unique constraint” 错误
IoT 设备常因网络抖动重发数据，或多个服务实例并发写入同一条 time-series 记录（如 (device_id, ts) 组合唯一），直接 INSERT 容易触发主键冲突。TimescaleDB 不支持 MySQL 风格的 ON DUPLICATE KEY UPDATE，但可借助 ON CONFLICT 语法实现幂等写入。
实操建议：
- 建表时定义
UNIQUE (device_id, time)或使用time_bucket()生成逻辑分区键 - 写入语句改用：
INSERT INTO metrics (device_id, time, value) VALUES ($1, $2, $3) ON CONFLICT (device_id, time) DO UPDATE SET value = EXCLUDED.value - 注意：若表启用了
chunk_time_interval自动分区，ON CONFLICT仍有效，但冲突检测仅限当前 chunk，跨 chunk 冲突不会被捕获——需靠应用层保证时间戳落在同一 chunk 内（通常 1 小时/1 天）
查询最近 7 天高频点位时，time_bucket 和 WHERE time >= ... 哪个更高效
单纯用 WHERE time >= NOW() - INTERVAL '7 days' 会让 PG 扫描所有相关 chunk，即使只查最近 2 个 chunk；而 time_bucket('1h', time) 本身不加速过滤，它只是分组函数。真正关键的是是否命中 hypertable 的 time 分区键索引。
实操建议：
- 必须在
WHERE子句中先用time字段做范围过滤（如time >= '2024-06-01' AND time ），再套 <code>time_bucket分组 - 避免
WHERE time_bucket('1h', time) >= ...，这会导致无法使用索引，全表扫描 - 高频点位聚合建议加物化视图：
CREATE MATERIALIZED VIEW metrics_1h_daily WITH (timescaledb.continuous) AS SELECT device_id, time_bucket('1h', time) bkt, avg(value) FROM metrics GROUP BY device_id, bkt
Go 服务重启后连接池卡住，日志报 failed to connect to `host=localhost user=postgres database=iot`: dial error
这不是 TimescaleDB 特有问题，而是微服务启动时依赖 DB 连接就绪，但 pgxpool 默认 MaxConns = 4、MinConns = 0，且未设置健康检查超时，在容器编排（如 Kubernetes）中，DB Pod 启动慢于应用 Pod，导致初始连接失败后 pool 不会自动重试，后续请求持续阻塞。
实操建议：
- 启动时主动等待 DB 可连：
for { if err := pool.Ping(context.Background()); err == nil { break }; time.Sleep(1 * time.Second) } - 调大
pgxpool.Config.MaxConns（IoT 写多读少场景建议 ≥20），并设MinConns = 5避免冷启动抖动 - 配置连接池健康检查：
pgxpool.Config.HealthCheckPeriod = 30 * time.Second，并监听pgconn.ConnectError类型错误做降级处理
TimescaleDB 的 hypertable 分区机制和 PG 原生生态是优势，但 Go client 层容易忽略二进制协议、类型映射和连接生命周期细节——这些地方出问题，往往表现为偶发超时或数据截断，而不是明显报错。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
