MySQL多租户POS系统：库存批量更新与逐条更新方案优劣咨询

性能对比 #

• 资源消耗：第一种方案的CPU、内存、IO开销显著低于第二种。不管单张单据包含多少商品，第一种方案只需要和MySQL进行3次交互（保存主数据、批量插入明细、批量更新库存），网络往返、SQL解析执行的固定开销不会随商品数量增长。第二种方案每多一个商品就要多2次数据库交互，当单单据商品数超过10个时，总资源消耗会是第一种的3~8倍，多租户高并发场景下差距会进一步放大。
• 特殊情况：如果第一种方案的子查询没有加对索引，可能产生临时表、全表扫描的额外开销，优化后可以避免。

安全性对比 #

• 原子性：两种方案只要都包裹在begin_transaction...commit事务中，数据一致性没有差异，出现异常都能全量回滚。
• 锁冲突风险：第一种方案一次性申请所有需要更新的商品行锁，持锁时间短，死锁概率极低；第二种方案循环逐次申请行锁，若不同单据操作重叠商品时拿锁顺序不一致，死锁概率会大幅提升。
• 业务逻辑正确性：第二种方案的单条SQL逻辑简单，不容易出现条件遗漏、子查询逻辑错误等问题，后续维护出bug的概率更低。

适用性建议 #

• 优先选第二种的场景：你的业务以零售为主，单单据平均商品数在5个以内，且业务迭代速度快，需要频繁新增商品联动更新逻辑（比如积分抵扣、商品保质期校验、批次管理等），这种场景下性能差距完全可以忽略，可维护性的收益更高。
• 优先选第一种的场景：你的业务以批发为主，单单据经常有20个以上商品，且租户并发量高，这种场景下第一种方案的性能优势可以支撑更高的业务承载量。
• 折中方案：可以保留第二种的简单逻辑，同时优化交互次数——先批量插入所有明细，再批量生成所有单商品的UPDATE语句一次性执行，既降低了交互开销，又避免了复杂子查询的维护问题。

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