Google Cloud在2026年9月9日宣布调整Spanner的DML事务限制。过去，一笔事务中所有DML语句产生的修改量会累计计算，合计达到80000个mutation mods后就会触发上限；现在，这个上限改为对每条DML语句单独检查。
这项变化允许应用把更多相关的INSERT、UPDATE或DELETE放进同一笔ACID事务，不必只为绕开累计上限而人为拆分。不过，官方并没有取消全部限制，开发者仍要区分DML语句、Mutation API以及事务大小等不同约束。
8万次上限从整笔事务下放到单条DML
Spanner所说的mutation mods并不等同于SQL影响的行数。计算会考虑被修改的单元格、主键以及相关二级索引，因此一次看似简单的更新，在列数多或索引较多时可能产生更多mods。
新规则下，同一事务可以包含任意数量的DML语句，每条语句分别接受80000个mods的检查。多步结算、订单写入或状态联动更新可以按业务一致性需求组合，而不再共享一笔80000的累计额度。
变化的是DML语句之间的累计方式，不是把80000这个数字彻底删除。理解这一点可以避免批量更新上线后继续遇到同样的报错。
单条语句超过80000仍会失败
如果一条UPDATE、INSERT或DELETE本身生成超过80000个mutation mods，Spanner仍会返回原有错误。把多个大范围操作合并到同一事务，也不会让单条语句获得无限额度。
官方建议，对可能超过单语句上限的大批量操作使用Partitioned DML，或者按主键范围分页处理。Partitioned DML适合可以分区独立执行的批量更新，但它的原子性与普通读写事务不同，不能直接替代必须整体成功或整体回滚的业务流程。
需要强原子性的事务应先估算每条语句的mods，而不是在生产环境依赖失败后重试。
Mutation API继续按Commit整体计数
这次放宽只针对DML语句。使用客户端库的insert()、update()等Mutation API时，修改集合会在Commit阶段提交，80000个mods限制仍然作用于这次Commit包含的全部mutations。
同一个应用可能同时使用DML和Mutation API，两条路径的限制口径不同。迁移或重构时不能看到DML规则变化，就默认所有写入接口都已解除累计约束。
现有Mutation API批处理逻辑仍要保留分批、失败处理和幂等控制，此次更新不会自动扩大它的单次提交容量。
更大的事务会增加锁竞争和中止概率
一笔事务能容纳更多DML，并不代表越大越好。事务运行时间越长、覆盖的数据范围越广，持有锁的时间通常越久，其他并发事务发生锁竞争或被中止的概率也会提高。
应用应继续保持事务简短，把真正需要原子一致性的步骤放在一起，把报表修正、历史回填等可拆分任务放到事务之外。对于高并发热点键，还要观察中止率和重试延迟，而不能只看是否触及80000上限。
新的容量空间应服务于业务一致性，而不是成为无限扩张事务的理由。
现有客户端无需升级但监控仍要调整
Google表示，这项变化兼容现有Spanner客户端库，应用代码不需要为了获得新规则而升级。团队可以先找出过去因累计上限而拆分的事务，评估是否有必要恢复更自然的业务边界。
提交后可通过CommitStats中的mutation_count观察整笔事务实际产生的修改量。这个统计仍会汇总事务内所有DML语句和Commit调用，有助于识别异常膨胀、索引放大和锁竞争风险。
上线验收不应只确认大事务能够提交，还要同时检查事务中止率、P95与P99延迟、重试次数和热点分布。单条语句保持低于80000、总体延迟没有明显恶化，才算完成安全迁移。
