为何SQLAlchemy批量更新比原生更新查询在大表上慢很多？

一、性能差异的核心原因 #

• executemany的执行机制瓶颈：SQLAlchemy的bulk_update_mappings和update(model).where(...).values(...)底层均依赖executemany接口。针对SQL Server，该接口默认行为并非真正的批量执行——它会将每条更新请求单独发送至数据库，等同于执行400次独立的UPDATE操作。这会产生大量网络往返开销，加上数据库重复解析SQL语句的成本，400次请求的累积耗时直接拉到了40秒。
• 原生SQL的高效批量逻辑：你自行拼接的原生查询应该采用了单条UPDATE语句批量更新多行的方案（比如通过CASE WHEN匹配主键，结合IN条件锁定目标行）。这种方式仅需与数据库建立一次连接，数据库只需解析一次SQL并执行一次更新操作，网络和解析成本被压缩到最低，因此耗时仅0.2秒。两者的性能差距本质是请求次数与SQL解析次数的数量级差异。

二、原生SQL查询的架构缺陷分析 #

使用原生SQL确实会引入一些架构层面的问题，主要包括：

• 字段与模型脱节，维护成本飙升：原生SQL需要手动硬编码所有更新字段和对应逻辑，当SQLModel的表模型结构变动（如新增字段、修改字段名）时，必须同步修改所有相关的原生SQL语句，极易出现遗漏或不一致，团队协作场景下维护成本会显著上升。
• 类型安全缺失，易引发格式错误：SQLModel会自动处理Python类型与SQL Server数据类型的映射转换，而原生SQL需要你手动处理所有数据格式适配——比如日期格式化、字符串转义、数值类型匹配等，稍有疏忽就会触发SQL语法错误或数据类型不兼容问题。
• SQL注入风险提升：如果拼接原生SQL时直接将变量嵌入字符串（而非使用参数化查询），会直接引入SQL注入风险。即便当前是内部数据更新，后续逻辑扩展时这种写法很容易埋下安全隐患。
• 失去ORM的数据库抽象能力：ORM的核心价值之一是实现数据库逻辑与底层数据库的解耦，若后续需要切换数据库（如从SQL Server迁移至MySQL），原生SQL需要大量修改适配，而SQLModel的ORM方法几乎无需改动即可兼容，原生SQL会大幅提升代码与数据库的耦合度，丢失跨数据库的灵活性。

内容的提问来源于stack exchange，提问作者Martin Todorov