SQLAlchemyCore与ORM性能对比详解

在纯数据读取场景下，SQLAlchemy Core 通常比 ORM 快1.5–3倍（实测百万行查询可从200ms+降至80ms），因其跳过对象生命周期管理、关系加载和属性监控等开销；但ORM在需要领域模型、业务方法复用、关联操作或数据持久化时不可替代——真正关键不是盲目追求性能，而是根据实际需求选择：Core适合高吞吐只读任务（如报表导出、ETL中间计算、对接混乱视图），ORM适合需对象行为与维护性的业务逻辑，而两者混合使用（Core查数据 + 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 根本不合适，硬用反而埋坑：

• 实时导出报表：要查几十万行、拼宽表、聚合后直接写 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，而是清楚自己到底要什么：是拿数据流做计算，还是拿数据建领域模型。选错方向，优化再多参数也白搭。

今天关于《SQLAlchemyCore与ORM性能对比详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！