pgx连接池配置不当会导致查询延迟飙升，需合理设置MaxOpenConns（50～200）、MaxIdleConns（约MaxOpenConns的0.5倍）和ConnMaxLifetime（如30分钟），并避免在handler中频繁Ping；JSONB查询需确保GIN索引建在表达式路径上且类型匹配；GORM Preload易引发JOIN性能问题，建议手动Joins并确保外键索引；SQLx命名参数在动态SQL中易出错，推荐位置参数或sqlx.In辅助函数。
pgx 连接池配置不当导致查询延迟飙升
用 pgx 时，sql.Open 或 pgx.Connect 默认的连接池参数根本扛不住真实业务流量。你看到的“查询变慢”，大概率不是 SQL 写得差，而是连接池在排队、超时、频繁重建连接。
-
db.SetMaxOpenConns(10)是很多教程默认值，但实际生产中常需设为 50～200（取决于 PostgreSQL 的max_connections和平均查询耗时） -
db.SetMaxIdleConns(5)太小会导致空闲连接被频繁回收，下次请求又得重连；建议设为MaxOpenConns * 0.5左右 -
db.SetConnMaxLifetime(30 * time.Minute)必须设——PostgreSQL 的连接可能被中间网络设备静默断开，不设这个会导致后续查询卡住几秒才报错 - 别在每次 HTTP handler 里调用
db.Ping()，它会阻塞整个 goroutine；改用db.Stats().OpenConnections+ 健康检查端点异步监控
JSONB 字段查询慢却查不出原因
你写了 SELECT * FROM users WHERE data @> '{"theme": "dark"}'，执行计划显示走索引，但实际响应还是 200ms+？问题往往出在类型匹配和索引定义上。
- 确保 GIN 索引建在**表达式路径**上：比如
CREATE INDEX idx_users_theme ON users USING GIN ((data -> 'theme'))，而不是USING GIN (data) - 查询用
->>提取字符串时，索引字段必须是 text 类型；若建的是(data -> 'theme')（返回 jsonb），而查询写成data ->> 'theme' = 'dark'，索引完全失效 - 避免在 WHERE 中对 JSONB 字段套函数：如
lower(data ->> 'name') = 'alice'—— 除非你额外建了函数索引CREATE INDEX ... ON users (lower(data ->> 'name')) - 批量读 JSONB 子字段时，优先用
rows.Scan(&s)直接扫text，别扫整块json.RawMessage再 Go 层解析，后者 CPU 开销翻倍
GORM Preload 导致内存暴涨和索引失效
Preload 不是银弹，尤其在一对多关联超过 3 层或主表数据量 > 1k 行时，它生成的 LEFT JOIN 很容易让 PostgreSQL 放弃使用主键索引，转而嵌套循环扫描。
- 用
Joins("JOIN orders ON orders.user_id = users.id").Select("users.id, users.name, orders.amount")替代Preload("Orders")，字段可控、JOIN 可优化 - 确认
orders.user_id上有索引，否则 JOIN 性能断崖下跌——EXPLAIN ANALYZE显示type=Seq Scan就是没索引 - 三级嵌套如
Preload("Orders.Items.Tags")会触发两个 LEFT JOIN，极易笛卡尔积；拆成两查更稳：SELECT id FROM users WHERE ...→SELECT * FROM orders WHERE user_id IN (?) - 别在
FindInBatches回调里做阻塞操作（HTTP 请求、文件写入），goroutine 会卡住整个批次；应把数据取出后丢进chan异步处理
SQLx 命名参数在复杂查询中反而埋雷
SQLx 的 :name 看似清爽，但在动态拼接、子查询或 WITH 语句里容易出错，且错误信息模糊，调试成本高于位置参数。
立即学习“go语言免费学习笔记（深入）”；
- 命名参数不支持在
IN ($1, $2, $3)这类可变长度列表中自动展开；你得手动生成占位符串再拼 SQL，不如直接用sqlx.In辅助函数 - 在 CTE（WITH 子句）中混用命名参数，某些 pgx 版本会解析失败，报
pq: syntax error at or near ":" - 结构体传参时，字段名大小写敏感：数据库列是
user_name，结构体 tag 得写db:"user_name"，写成db:"username"就静默忽略 - 跨事务复用同一命名参数 map 容易污染——比如两次查询都用了
map[string]interface{}{"id": 1}，第二次覆盖第一次，结果错乱
真正卡住性能的，从来不是某条 SQL 写得多漂亮，而是连接池配置、索引路径与查询表达式是否严格一致、以及 ORM 封装层有没有悄悄把你的意图翻译成低效执行计划。这些地方一不留神，QPS 上不去、GC 频繁、CPU 暴涨，全都有迹可循。
