应放弃 gorm.preload 改用 joins + select：preload 在一对多场景下引发笛卡尔积、索引失效及嵌套 join 问题；joins 可控字段、避免冗余加载，配合手动建索引与分步查询更高效。
什么时候该放弃 GORM.Preload 改用 Joins + Select
GORM 的 Preload 在一对多场景下极易引发笛卡尔积，比如查 100 个用户、每人平均关联 5 条订单，内存里会加载 500 个对象再靠 Go 层分组——既吃带宽又拖 GC。更隐蔽的问题是 PostgreSQL 优化器看到 LEFT JOIN 后可能弃用主表索引，转而走嵌套循环。
- 显式写
Joins("JOIN orders ON orders.user_id = users.id")，立刻跟Select("users.id, users.name, orders.amount, orders.status")，字段粒度可控 - 避免
Preload("Orders.Items.Tags")这类三级嵌套，它会生成两个LEFT JOIN；若orders.user_id没索引，EXPLAIN显示type=ALL是常态 - 关联逻辑复杂时（如“只取每个用户最新一笔订单”），宁可拆成两查：
SELECT id FROM users WHERE ...→SELECT * FROM orders WHERE user_id IN (?) ORDER BY created_at DESC→ Go 层map匹配 -
Joins不自动建索引，务必手动确认orders.user_id上有INDEX，否则 JOIN 性能断崖下跌
大批量导出别用 FindInBatches，改用 pgx.Batch 或 COPY
FindInBatches 看似解决“查百万行”的银弹，但踩坑率极高：漏数据、重复、性能不稳。根本原因在于它依赖主键单调递增且无空洞的假设，而现实中软删除、UUID 主键、手动 INSERT ID 都会打破这个前提。
- 主键必须是自增
SERIAL或BIGSERIAL，且表中从未执行过DELETE或TRUNCATE；用 UUID 的表不能用 - 批次大小设为 100～500，太小导致网络往返过多，太大则单次查询内存暴涨；实测发现 300 在多数 1KB/行场景下最稳
- 禁止在
func(tx *gorm.DB) error回调里做任何阻塞操作（如 HTTP 请求、文件写入），否则整个批次卡住；应把数据取出后丢进chan，由 goroutine 异步处理 - 替代方案：直接用
pgx.Batch或原生COPY导出，绕过 ORM 层，吞吐量提升 3～5 倍
混合使用 GORM 和原生 SQL 的关键分层点
别迷信 ORM 一层封装，该切原生 SQL 就切，但必须保留 GORM 的连接池、事务管理及结构体扫描能力。问题不在选哪个，而在怎么混用——核心是让它们共用同一套 *sql.DB 实例。
- 简单 CRUD、模型迁移、钩子逻辑交给 GORM；复杂 JOIN、窗口函数、CTE、JSONB 聚合等交给原生 SQL
- 用
db.Raw("...").Scan(&result)或db.Session(&gorm.Session{NewDB: true}).Raw("...").Scan(&result)复用 GORM 的连接和事务上下文 - 手动拼
EXPLAIN语句时，必须独立执行并检查pg_indexes，验证索引是否真实生效——GORM 日志里的 SQL 往往被重写过，不能直接拿去EXPLAIN - 如果项目已重度依赖 GORM，优先升级到 v1.25+，它支持
WithContext和Session更细粒度控制，避免事务泄漏
pg_query_go 解析 SQL 的真实用途边界
pg_query_go 基于 PostgreSQL 官方解析器，能将 SQL 转成 JSON AST 或 Go 结构体，但它不是执行引擎，也不参与运行时优化。它的价值在静态分析环节。
- 用于 SQL 指纹生成：统一替换常量为
$1占位符，实现慢查询去重和归类 - 安全审查：扫描 AST 中是否存在
CREATE FUNCTION、DO $$等高危节点，拦截动态拼接的 PL/pgSQL - 查询标准化：把
SELECT * FROM users WHERE id = 123和SELECT id,name FROM users WHERE id = 123 AND status = 'active'归为不同指纹，辅助性能监控 - 不建议在请求链路中实时调用
pg_query_go.Parse—— 它是 CPU 密集型操作，单次解析耗时 1–3ms，QPS 高时会成为瓶颈
复杂查询的真正难点不在语法本身，而在连接复用、索引有效性验证、以及 ORM 与原生 SQL 的职责切割。很多团队卡在“写不出高效 JOIN”，其实是因为没意识到 Preload 和 Joins 的底层执行计划差异，也没在每次上线前跑一遍 EXPLAIN ANALYZE 对比真实执行路径。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
