bulk_update_mappings更快是因为将N次UPDATE合并为1条SQL，避免循环、ORM实例化、事务及网络开销；需传入含主键的字典列表，字段名为模型属性名，不触发ORM事件。
SQLAlchemy bulk_update_mappings 为什么比 for + commit 更快
因为 bulk_update_mappings 把所有更新操作合并成一条（或极少数几条）SQL语句发给数据库，避免了 Python 层循环、每次 ORM 实例化、事务开销和网络往返。而用 for 遍历对象再 session.commit()，实际是 N 次 UPDATE，哪怕加了 autocommit=False，也逃不开 N 次 SQL 解析与执行。
实操建议：
- 必须确保传入的字典列表中每个字典都含主键字段（如
id），否则 SQLAlchemy 找不到对应行，会静默跳过 - 只支持更新已存在数据库中的记录；新增数据要用
bulk_insert_mappings - 不触发 ORM 事件（如
@event.listens_for）、不调用模型的__init__或属性 setter，纯 SQL 层操作 - 更新字段名必须与模型定义的列名完全一致（不是表字段名），大小写敏感
如何正确构造 bulk_update_mappings 的数据结构
它只接受一个字典列表，每个字典代表一行更新，且必须包含主键。不能混用模型实例或混合字段名/列名。
常见错误现象：sqlalchemy.exc.InvalidRequestError: No row was found for one()... 或静默无更新——大概率是字典里漏了主键，或主键值在库中不存在。
立即学习“Python免费学习笔记（深入）”；
示例（假设模型为 User，主键是 id）：
data = [
{"id": 1, "name": "Alice", "status": "active"},
{"id": 2, "name": "Bob", "status": "inactive"},
{"id": 3, "name": "Charlie", "status": "pending"},
]
db.session.bulk_update_mappings(User, data)
db.session.commit()
注意：data 中字段名必须是模型属性名（如 name），不是数据库列名（如 user_name），除非你显式用 column_property 映射过。
bulk_update_mappings 和 execute(update()) 的性能与适用边界
bulk_update_mappings 适合「按主键批量更新固定字段」；而 session.execute(update(...).where(...)) 更适合「按条件批量更新，不依赖主键」或需要复杂 WHERE 逻辑的场景。
性能上两者都远优于逐条 update，但有关键差异：
-
bulk_update_mappings：底层仍是 ORM 映射，需提前加载模型类，字段安全性由 Python 层校验 -
execute(update(User).values(...).where(User.status == 'pending'))：绕过 ORM，直接拼 SQL，更快更轻量，但要自己确保字段名、类型、SQL 注入安全 - 后者不支持自动刷新对象状态（
expire_on_commit=True时），前者会按需 expire 对应实例
如果只是“把一批 ID 对应的记录统一设为某个状态”，优先选 bulk_update_mappings；如果是“把所有 status='draft' 的记录改成 'reviewing'”，就该用 execute(update().where(...))。
容易被忽略的事务与异常处理细节
bulk_update_mappings 不自动提交，也不自动回滚。一旦 commit() 失败（如唯一约束冲突、字段超长），整个批次都会失败，且已执行的部分不会回退——因为它是单条 SQL，数据库要么全成功，要么全失败。但 Python 层感知不到中间状态。
实操建议：
- 务必用
try/except包裹commit()，捕获IntegrityError、DataError等 - 不要在
bulk_update_mappings后混用其他 ORM 操作（如session.add()）再一起 commit——可能引发状态混乱 - 若需部分失败容忍（比如某几条脏数据不想阻断整体），得先用
SELECT过滤出合法 ID，或改用逐条 try/except（牺牲性能换健壮性） - PostgreSQL 用户注意：
ON CONFLICT不适用于bulk_update_mappings，它不生成 UPSERT 语句
批量更新真正难的不是写法，而是确认数据一致性边界和失败后的可观测性——比如日志里至少记下本次更新的 ID 范围和报错详情。
