DuckDB 不适合直接用作微服务的主数据库，因其是面向 OLAP 的嵌入式分析引擎，不支持并发写入、无网络服务层、缺乏 WAL 和原子事务保障；必须作为只读、预加载、快照式分析引擎使用，典型做法是定期从 PostgreSQL 等主库导出 Parquet 后加载分析。
为什么 DuckDB 不适合直接用作微服务的主数据库
DuckDB 是面向 OLAP 的嵌入式分析引擎，不是事务型数据库。它不支持并发写入（INSERT/UPDATE/DELETE 同时多 goroutine 执行会 panic），没有网络服务层，也没有 WAL 或原子事务保障。如果你把它当 MySQL 用——比如每个 HTTP 请求都 sql.Open("duckdb", ":memory:") 然后反复建表查表——会立刻遇到连接泄漏、内存暴涨、查询阻塞甚至崩溃。
真正可行的路径只有一条：把 DuckDB 当作**只读、预加载、快照式分析引擎**来用。典型做法是定期从主库（如 PostgreSQL）导出 Parquet 文件，再用 DuckDB 加载分析。
如何安全地在 Go 中复用 DuckDB 连接池
DuckDB 的 Go 驱动（github.com/duckdb/duckdb-go）本身不提供连接池。但它的 database/sql 接口实现是线程安全的——前提是底层 *sql.DB 实例被正确配置。你不能每次查询都新建 sql.Open，而应全局复用一个实例，并调优其连接池参数：
-
db.SetMaxOpenConns(1)—— 必须设为 1，因为 DuckDB 不支持并发写；设 >1 可能导致IOError: cannot write to read-only database -
db.SetMaxIdleConns(1)—— 避免空闲连接堆积（尤其在 :memory: 模式下） -
db.SetConnMaxLifetime(0)—— DuckDB 连接无生命周期概念，设 0 禁用自动关闭
示例初始化：
立即学习“go语言免费学习笔记（深入）”；
db, err := sql.Open("duckdb", "path/to/data.duckdb")
if err != nil {
log.Fatal(err)
}
db.SetMaxOpenConns(1)
db.SetMaxIdleConns(1)
db.SetConnMaxLifetime(0)
怎样高效加载外部数据（Parquet / CSV）而不卡住 HTTP 请求
微服务里最常踩的坑是：收到 API 请求后才去 SELECT * FROM 'data.parquet' —— 这会导致每次请求都触发磁盘 I/O 和列式解析，延迟飙升。DuckDB 的优势在于“预加载 + 缓存”，不是“按需读取”。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
推荐做法是启动时或定时任务中完成数据加载：
- 用
CREATE TABLE t AS SELECT * FROM 'input.parquet'把 Parquet 导入内部表（比每次读 Parquet 快 5–10 倍） - 对大表启用
PRAGMA enable_object_cache（默认开启，但确认一下） - 避免在 HTTP handler 里执行
COPY或INSERT INTO ... SELECT—— 这些操作会阻塞整个连接
如果必须动态加载，改用 read_parquet() 函数并配合 WITH ... AS 临时视图，确保不修改数据库状态：
SELECT COUNT(*) FROM read_parquet('logs_202405*.parquet') WHERE status = 500
如何规避常见 panic 和类型转换陷阱
Go 驱动对 DuckDB 类型映射较粗粒度，容易在 Scan 时 panic。典型问题包括：
-
sql.NullInt64扫描TIMESTAMP字段 → panic：cannot scan type *time.Time into *sql.NullInt64 - Parquet 中的
INT96时间戳被 DuckDB 解析为TIME，但 Go 驱动返回[]uint8，需手动转time.Time - 使用
sql.NullString扫描可能为 NULL 的DECIMAL字段 → 驱动返回nil而非空字符串，Scan 失败
稳妥做法是统一用 interface{} Scan，再按 reflect.TypeOf 分支处理：
var val interface{}
err := row.Scan(&val)
if err != nil { /* handle */ }
switch v := val.(type) {
case time.Time:
// 处理时间
case float64:
// DuckDB 的 DECIMAL 常转成 float64
case string:
// TEXT 或 VARCHAR
}
真正麻烦的是嵌套结构（如 Parquet 中的 struct/list）——DuckDB 目前不支持直接 Scan 到 Go struct，只能先 Scan 成 string 再 JSON 解析。
别指望 DuckDB 替代主库，也别在热路径上做数据导入。它的价值在于：把离线分析逻辑搬到服务内，省掉额外的 Presto/Trino 依赖，但前提是你接受“数据有小时级延迟”和“写操作必须隔离”。
