纯数据读取场景下，sqlalchemy.core 通常比 sqlalchemy.orm 快 1.5–3 倍，因绕过对象生命周期管理；但 orm 在需对象行为、关联操作时更优，二者应按场景混合使用。
core 查询比 orm 快多少？
直接说结论：纯数据读取场景下，sqlalchemy.core 通常比 sqlalchemy.orm 快 1.5–3 倍，尤其在批量读、无业务逻辑、不需对象映射时。这不是理论值，是实测——比如从百万行表里 select * where id in (……)，core 耗时 80ms，等价 orm 查询（session.query(……).filter(……).all()）常在 200ms 以上。
快的原因很实在：core 绕过了 orm 的整套对象生命周期管理——没 identity map、没 dirty checking、没 relationship 加载、没 attribute instrumentation。它就是把 SQL 扔给数据库，把结果集按行返回成 Row 或 dict，不碰类、不建实例。
但别急着全切 core。如果你需要把结果当对象用（比如传给 Pydantic 模型、做字段校验、复用已有业务方法），或者要写关联更新、级联删除，orm 的抽象省掉的代码量和出错概率，远比那 100ms 更值。
什么时候必须用 core？
不是“性能差就换 core”，而是某些场景下，orm 根本不合适，硬用反而埋坑：
立即学习 “Python 免费学习笔记（深入）”；
- 实时导出报表：要查几十万行、拼宽表、聚合后直接写 CSV，用
session.execute()+fetchall()明显更稳；用 orm 加载几万个实例，内存暴涨还容易 OOM - ETL 流水线中的中间计算：比如用
func.json_extract()解析 JSON 字段再过滤，core 的select().select_from().where()写法直译 SQL，调试时一眼看懂执行计划 - 对接遗留系统或只读视图：表结构野、命名不规范、没有主键、字段类型混乱——orm 的
declarative_base映射会卡在反射或类型推断上，core 用text()或table(……, autoload_with=engine)更扛造
orm 性能差的常见操作，其实可以优化
很多人一测 orm 慢，就归咎于“orm 天然慢”，其实很多是误用导致的额外开销：
- 用
query.all()加载全部结果，但只取前几条 → 改用.limit(10).scalars().all()或直接.first() - 开启
lazy='select'关系后，循环中访问user.posts触发 N+1 → 改用joinedload()或selectinload()预加载 - 对不需要的对象字段也全量查（比如用户表有
avatar_blob大字段）→ 用load_only(User.name, User.email)显式指定列 - 频繁创建
Session实例（如每个请求 new 一个）→ 改用scoped_session或依赖注入管理生命周期
这些改完，orm 查询耗时可能从 300ms 掉到 120ms，已经够用。没必要为这点差距放弃 orm 的可维护性。
混合用法：core 查 + orm 构造对象
最实用的折中方案，是用 core 拿原始数据，再喂给 orm 类构造轻量实例——绕过 session 管理，又保留对象接口：
result = conn.execute(select(User.id, User.name, User.email)).mappings().all() users = [User(**row) for row in result] # 不走 session.add()，不进 identity map 这种写法适合：需要对象方法（比如 user.get_display_name()）、但不需要持久化、也不关心变更跟踪的场景。注意两点：
-
User类必须支持**kwargs初始化（比如用@dataclass或手动写__init__） - 别在构造后调
session.add(user)，否则会触发重复插入或主键冲突 - 如果字段名和数据库列名不一致（比如 ORM 用了
Column('user_name', ……)），得用Result.mappings()而不是Result.fetchall()，不然 key 对不上
真正难的从来不是选 core 还是 orm，而是清楚自己到底要什么：是拿数据流做计算，还是拿数据建领域模型。选错方向，优化再多参数也白搭。
