17370845950

SQLAlchemy批量更新无法自动只改变化字段，必须手动比对新旧值并构造差异字典传给bulk_update_mappings()；若需ORM事件或默认值计算，则应使用merge()或逐个setattr后flush()。

SQLAlchemy 批量更新只改变化字段，用 update() + values() 不行

直接用 session.execute(update(...).values(...)) 是全量覆盖——哪怕你只传了 1 个字段，它也会把其他字段设为 NULL 或默认值（取决于数据库行为），根本不是“只更新变化字段”。这不是 bug，是 SQL 标准语义：UPDATE 语句本身不感知“原始值”，它只按你写的 SET

真正可行的方案：用 session.bulk_update_mappings() + 差异预计算

SQLAlchemy 原生不提供“自动 diff 字段后生成条件化 UPDATE”的功能。必须自己比对新旧值，构造仅含变化字段的字典。核心是两步：先查出原数据（或缓存旧值），再构造只含差异的 dict 列表传给 bulk_update_mappings()。

• 必须带主键（如 id）在 mapping 字典里，否则无法定位行
• 只写你想改的字段，没出现的字段完全不会出现在 SET 子句中
• 所有 mapping 字典的键名必须一致（不能有的写 user_name，有的写 username）
• 不触发 ORM 事件（如 @validates、before_update），也不走属性 setter

# 示例：只更新 name 和 email 有变化的用户
old_users = session.query(User).filter(User.id.in_([1, 2, 3])).all()
updates = []
for u in old_users:
    new_data = get_new_user_data(u.id)  # 你的业务逻辑，返回 dict
    changed = {k: v for k, v in new_data.items() if getattr(u, k) != v}
    if changed:
        changed["id"] = u.id  # 主键必须存在
        updates.append(changed)
if updates:
session.bulk_update_mappings(User, updates)
session.commit()

想保留 ORM 行为？只能单条处理 + session.merge() 或手动 set

如果依赖 @validates、关系级联、default/server_default 计算，或者需要触发 before_update，就别强求批量。老实用循环 + merge() 或显式赋值：

• session.merge() 会查库比对，只发变更字段的 UPDATE（但本质是 1 次 SELECT + 1 次 UPDATE）
• 更轻量的是直接查出对象、逐个 setattr()、然后 session.flush() —— 只要没调 commit()，仍是单次事务内的多条 UPDATE
• 注意：merge() 对无主键或复合主键场景行为复杂，慎用

# 安全可控的做法（推荐用于中小批量）
users = session.query(User).filter(User.id.in_([1, 2, 3])).all()
for u in users:
    new_vals = get_new_user_data(u.id)
    for field, val in new_vals.items():
        if getattr(u, field) != val:
            setattr(u, field, val)
session.flush()  # 不 commit，留到外层统一提交

绕不开的坑：数据库层面的并发更新风险

无论用哪种方式，“先查再比再更”都不是原子操作。两个并发请求同时读到同一旧值，各自算出不同变更集并写入，可能丢失某一方的修改。真要强一致性，得加 WHERE 条件校验原始值（即“乐观锁”）：

• 在 UPDATE 语句里显式加上 WHERE name = 'old' AND email = 'old@x.com'
• SQLAlchemy 中需手写 update(...).where(...)，无法用 bulk_update_mappings 实现
• 或者加版本列（version_id_col），用 update(...).where(Model.version == old_ver)

差分更新本身不解决并发问题，这点常被忽略——业务上是否允许“最后写入获胜”，得提前想清楚。