sqlalchemy中n+1查询源于relationship默认lazy='select'，实操应优先用joinedload或selectinload优化，并通过sql日志、explain分析、索引检查及合理session管理来根治。
SQLAlchemy里relationship默认懒加载，一查列表就触发N+1
查10条用户数据，顺带要显示每个用户的最新订单，结果发了11次SQL：1次查用户，再为每个用户各查1次订单——这就是典型的N+1。根本原因在于relationship默认是lazy='select'，不显式干预就会在访问属性时逐个触发查询。
实操建议：
- 用
joinedload()在主查询中提前JOIN关联表，适合关联数据量小、且确定要展示的场景 - 用
selectinload()发第二条IN查询批量加载，比N+1快得多，也比joinedload更可控（避免笛卡尔积爆炸） - 别在循环里访问
user.orders[0]这类属性——哪怕加了lazy='joined'，如果ORM没把整个关系预加载进来，仍可能触发额外查询 - 开启SQL日志：
echo=True或设环境变量SQLALCHEMY_ECHO=1，一眼看出是不是又冒出一堆SELECT ... FROM orders WHERE user_id = ?
用Query.statement和explain()看真实执行计划
ORM生成的SQL不一定高效，尤其用了joinedload后容易产生冗余字段或隐式笛卡尔积。光看Python代码看不出问题，得让数据库自己说话。
实操建议：
- 在Flask shell或调试时，先构造查询对象
q = session.query(User).options(joinedload(User.orders))，再执行print(q.statement.compile(compile_kwargs={"literal_binds": True}))拿到可读SQL - 把生成的SQL粘到数据库客户端里跑
EXPLAIN ANALYZE（PostgreSQL）或EXPLAIN FORMAT=JSON（MySQL），重点看是否用上索引、有没有Seq Scan、rows预估是否离谱 - 注意
selectinload最终会生成类似SELECT ... WHERE id IN (1,2,3...)，确保orders.user_id有索引，否则IN查询也会慢
Flask上下文里session生命周期没管好，缓存失效还重复查
一个请求里多次调用session.query(User).get(1)，本该命中Identity Map缓存，但如果每次都在新session里查，或者手动session.expire_all()，缓存就废了，变成反复查库。
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
实操建议：
- 用
scoped_session绑定到Flask的request生命周期，确保同一次请求内复用session——别在视图函数里自己Session()新建实例 - 避免在循环中创建新session：
for u in users: Session().query(Order).filter_by(user_id=u.id).first()是典型反模式 - 查完立刻用
session.expunge_all()或session.close()？小心——这会让后续对已加载对象的user.orders访问再次触发SQL，因为对象被踢出session缓存了
复杂查询别硬套ORM，该写原生SQL就写text()
涉及多表聚合、窗口函数、UNION、CTE或者需要精细控制JOIN顺序时，硬用SQLAlchemy的query.join().group_by().having()链式调用，要么写出来难读，要么生成SQL带多余子查询，性能反而更差。
实操建议：
- 用
session.execute(text("SELECT ..."))直接执行手写SQL，参数用命名占位符：text("SELECT * FROM users WHERE status = :status")，防注入 - 返回结果用
session.execute(...).mappings().all()得到字典列表，比fetchall()更贴近业务逻辑 - 别为了“纯ORM”把
COUNT(*) OVER (PARTITION BY category)硬拆成Python端分组统计——数据库算1次，Python要拉全量再循环，网络+内存都吃亏
真正卡住性能的，往往不是ORM本身，而是没意识到什么时候该交出控制权。比如selectinload看着安全，但若关联表数据量极大，批量IN查询反而拖垮连接池；又比如EXPLAIN里看到Bitmap Heap Scan占比高，说明索引存在但数据局部性差——这些细节，只看Python代码永远发现不了。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
