pgx查询JSONB慢因运行时反序列化整段JSON且默认不触发GIN索引；需用原生操作符（如@>、#>>）在库侧过滤，并确保索引路径与查询表达式严格一致。
pgx 查询 JSONB 字段时为什么慢？
因为默认用 jsonb_extract_path_text() 或 ->> 做运行时解析，每次查都反序列化整段 JSON，尤其字段嵌套深、JSON 体积大时，CPU 和内存开销明显上升。PostgreSQL 虽支持 GIN 索引，但 pgx 默认不触发索引优化路径——你得手动写表达式，且确保类型匹配。
- 别直接用
row.Scan(&v)读整个jsonb列再用 Go 解析，这是最常见性能陷阱 - 要用 PostgreSQL 原生 JSONB 操作符（如
@>、?&、#>>）在数据库侧过滤，把结果集压到最小 - GIN 索引必须建在具体路径上，例如
CREATE INDEX idx_user_prefs_theme ON users USING GIN ((prefs -> 'theme'));，不能只建在prefs整列上
pgx 中安全提取 JSONB 子字段的三种方式
Go 层面对 JSONB 的处理不是“越快越好”，而是“越准越稳”。pgx 支持原生 json.RawMessage、自定义 struct 扫描、以及直接绑定到 PostgreSQL 表达式结果，三者适用场景不同。
- 想保留原始结构、后续动态解析：用
json.RawMessage，避免 pgx 多余解码/编码，但注意它不校验 JSON 合法性 - 字段结构固定、需强类型：定义 struct 并实现
sql.Scanner和driver.Valuer，否则 pgx 会报can't scan into dest[0]: cannot decode jsonb into *struct - 只取单个字符串/数字值：用
rows.Scan(&s)直接扫text类型，配合 SQL 中的prefs ->> 'theme'，最轻量，也最容易走索引
GIN 索引失效的典型配置错误
建了索引却没生效，90% 是因为查询表达式和索引定义不一致。pgx 本身不干预索引逻辑，但你的 SQL 写法决定了 PostgreSQL 能不能命中。
- 索引建在
(data -> 'user' ->> 'id')，但查询写成data -> 'user' -> 'id'（返回 jsonb 而非 text），索引完全无效 - 用
jsonb_path_exists(data, '$.user.id == "123"')查询，但没建jsonb_path_ops索引，只能全表扫描 - WHERE 条件里混用函数，比如
lower(data ->> 'name') = 'alice'，除非你建的是函数索引，否则 GIN 不起作用
批量更新 JSONB 字段时的原子性陷阱
用 jsonb_set() 或 || 拼接更新时，如果多个 goroutine 并发改同一行的 JSONB 字段，可能覆盖彼此修改——pgx 不提供乐观锁封装，得靠 SQL 层保障。
立即学习“go语言免费学习笔记（深入）”；
- 别用
UPDATE t SET data = data || $1 WHERE id = $2做并发更新，竞态下会丢数据 - 正确做法是加
WHERE ctid = $3或用SELECT ... FOR UPDATE显式加行锁 - 更稳妥的是用
jsonb_set(data, '{user,name}', to_jsonb($1), true)配合RETURNING data，再比对旧值做条件更新
JSONB 不是万能容器，嵌套过深或频繁更新的字段，拆成关系表通常更稳；pgx 的强大在于让你贴近 PostgreSQL 原生能力，而不是掩盖它。真正卡点往往不在 Go 代码，而在那条 SQL 是否精准命中索引、是否让数据库干它该干的活。
