本文详解如何通过预加载（eager loading）策略解决 sqlalchemy 中常见的 n+1 查询问题，显著提升多表关联查询性能，尤其适用于生成嵌套 json 的复杂业务场景。
本文详解如何通过预加载（eager loading）策略解决 sqlalchemy 中常见的 n+1 查询问题，显著提升多表关联查询性能，尤其适用于生成嵌套 json 的复杂业务场景。
在你当前的代码中，虽然主查询通过 join(Order) 获取了 Delivery 和 Order 的关联数据，但后续循环中频繁访问 delivery.JobDeliveries、job_delivery.Job、delivery.AddressContact、delivery.DeliveryMethod 等关系属性时，SQLAlchemy 默认会触发惰性加载（lazy loading）——即每访问一次未加载的关系，就发起一条新 SQL 查询。对于 100 条 Delivery 记录，若平均每条关联 5 个 JobDelivery，再各自关联 Job、Address、Client 等，最终可能产生数百甚至上千次数据库往返，这是性能瓶颈的根本原因（15 秒耗时即典型表现）。
✅ 核心解决方案：使用 Eager Loading 预加载所有必需关联
SQLAlchemy 提供了多种预加载策略，应根据关联类型和数据规模合理选择：
| 加载方式 | 适用场景 | 示例说明 |
|---|---|---|
| joinedload() | 关系为一对一或一对少，且需 JOIN 合并结果 | Delivery.Order、Order.Client |
| selectinload() | 关系为一对多/多对多，推荐默认首选（N+1 → 1+N） | Delivery.JobDeliveries、Delivery.Address |
| subqueryload() | 兼容旧版，功能类似 selectinload，但效率略低 | 已不推荐新项目使用 |
以下是针对你业务逻辑重构后的高性能查询示例（基于 SQLAlchemy 2.0+ select() 风格）：
from sqlalchemy import select, and_
from sqlalchemy.orm import joinedload, selectinload
# 构建预加载查询
stmt = (
select(Delivery)
.join(Order)
.where(
and_(
Delivery.DespatchDateTime.between(start_date, end_date),
Order.ProductionSite == site_map.get(site)
)
)
.options(
# 一级关联：Order（已 JOIN，复用该 JOIN）
joinedload(Delivery.Order).joinedload(Order.Client),
# 一级关联：DeliveryMethod、Address、AddressContact（一对少，可 selectin）
selectinload(Delivery.DeliveryMethod),
selectinload(Delivery.Address),
selectinload(Delivery.AddressContact),
# 一对多关联：JobDeliveries → Job（关键！避免 job_delivery.Job 触发 N+1）
selectinload(Delivery.JobDeliveries).joinedload(JobDelivery.Job)
)
)
delivery_rs = session.scalars(stmt).all() # 返回 Delivery 实例列表，所有关联均已加载⚠️ 重要注意事项：
- 关闭 echo 验证效果：启动时设置 echo=True（如 create_engine(..., echo=True)），运行后观察日志——理想情况下仅出现 1 条主查询 + 少量（通常 ≤ 5 条）预加载子查询，循环内不应再有 SELECT 日志。
- 避免 joinedload 滥用一对多：对 Delivery.JobDeliveries 使用 joinedload 可能导致笛卡尔积膨胀（1 Delivery × N JobDeliveries × M Jobs），数据量大时内存与网络开销剧增。selectinload 更安全高效。
- 正则处理无需数据库参与：web_ref 的清洗（如 re.sub(r'^CCW_', '', web_ref)）是纯 Python 逻辑，确保放在 Python 层处理，而非尝试在 SQL 中做字符串操作。
- 批量序列化优化（进阶）：若后续仍存在性能压力，可考虑使用 sqlalchemy.ext.baked 或手动构造字典（绕过 ORM 属性访问开销），但绝大多数场景下，正确预加载已解决 90% 问题。
? 总结：你的性能瓶颈并非 SQLAlchemy 本身慢，而是默认的惰性加载机制在深度遍历时被反复触发。通过精准配置 joinedload 与 selectinload，将原本 O(N×M) 的查询复杂度降至 O(1) 主查询 + O(K) 预加载查询（K 为关联表数量），100 条 Delivery 的响应时间可轻松从 15 秒压缩至 1~2 秒内。记住黄金法则：“所有在循环中访问的关系，都必须显式预加载”。
