db.session.query()触发N+1查询是因为relationship默认lazy='select'，查完主表后访问关联属性会逐个发起SQL；应优先用selectinload()批量预加载，避免循环中触发额外查询。
为什么 db.session.query() 会触发 N+1 查询？
当你在 Flask 中用 db.session.query(User).all() 获取用户列表，再对每个用户调用 user.posts（假设是 relationship），SQLAlchemy 默认会为每个用户单独发一条 SQL 查 posts——这就是典型的 N+1 问题。它不报错，但响应变慢、数据库压力陡增。
根本原因是：关系字段默认是 lazy 加载，user.posts 第一次访问时才触发查询，且没做批量预取。
- 检查是否用了
lazy='select'（默认值）——这是 N+1 的温床 - 确认模型中
relationship没显式设成lazy='dynamic'（它返回 query 对象，容易误用.all()多次） - 避免在模板里循环时直接访问关联属性，比如 Jinja2 中写
{% for post in user.posts %}
用 joinedload() 和 selectinload() 预加载关联数据
joinedload() 把主表和关联表用 JOIN 一次性查出，适合关联数据量小、层级浅的场景；selectinload() 则先查主表 ID，再用 IN 子句批量查关联表，更稳定、不易爆内存，推荐作为默认选择。
示例：查用户及他们的文章
立即学习“Python免费学习笔记（深入）”；
from sqlalchemy.orm import selectinload
users = db.session.query(User)\
.options(selectinload(User.posts))\
.filter(User.active == True)\
.all()
-
selectinload()不生成 JOIN，避免笛卡尔积膨胀，尤其当一个用户有上百篇文章时更安全 - 多级嵌套用点号链式写，如
selectinload(User.posts).selectinload(Post.tags) - 不能混用
joinedload()和selectinload()加载同一关系，否则 SQLAlchemy 会忽略后者
慎用 subqueryload() 和避免 lazy='joined'
subqueryload() 本质是子查询 + JOIN，性能介于 joinedload() 和 selectinload() 之间，但调试困难、SQL 可读性差，多数情况没必要选它。lazy='joined' 看似方便，实则把 JOIN 写死在关系定义里，导致每次访问 user.posts 都强制 JOIN，哪怕你根本不需要 posts 字段——这会让简单查询变慢、无法被缓存利用。
- 不要在模型定义里写
lazy='joined'，除非该关系 100% 每次都需要 -
subqueryload()只在极少数 ORM 无法生成高效IN查询的老版本中考虑 - 如果发现
selectinload()返回空列表却查不到数据，检查外键是否为空或类型不匹配（比如post.user_id是None或字符串）
用 contains_eager() 处理已 JOIN 的查询结果
当你手动写了 JOIN 查询（比如 db.session.query(User, Post).join(Post)），SQLAlchemy 不知道如何把结果映射回 User 对象的 posts 属性。此时必须用 contains_eager() 告诉 ORM：“这段 SQL 已包含关联数据，请直接填充进去”。否则你拿到的是裸 tuple，或者 user.posts 仍是未加载状态。
from sqlalchemy.orm import contains_eager
users_with_posts = db.session.query(User)\
.join(Post)\
.options(contains_eager(User.posts))\
.filter(Post.published == True)\
.all()
-
contains_eager()不发起新查询，只做结果映射，性能无额外开销 - 必须确保 JOIN 的路径与
relationship定义一致，否则映射失败 - 不能和
selectinload()同时用于同一关系，会冲突
真正难的不是记住这几个 loader，而是判断哪条路径正在悄悄发起额外查询——打开 SQLAlchemy 的 echo=True，盯着日志里每条 SQL 的来源，比任何文档都管用。
