Java中使用JDBC批量更新实现REST资源部分更新的最优方案

以下方案均不需要提前查询原有数据回填，性能优于先查后写的逻辑：

方案1：按更新字段分组批量执行（最优） #

你当前只有2个偏好字段，更新的字段组合只有3种，你可以先把请求中的用户按updateFields包含的字段分成3组，每组对应独立的更新语句，分别执行JDBC批量更新：

• 仅更新preference1的用户组，使用语句：

  update preferences set pref1 = ? where userId = ?
  

  批量参数依次传入每组的preference1值、userId即可
• 仅更新preference2的用户组，使用语句：

  update preferences set pref2 = ? where userId = ?
  

• 同时更新两个偏好的用户组，使用你原有语句即可：

  update preferences set pref1 = ?, pref2 = ? where userId= ?
  

该方案无额外SQL开销，也没有兼容风险，是当前场景下的最优选择。即使后续偏好字段增加到5个以内，组合总数也只有十几种，完全可以沿用该逻辑。

方案2：通用单SQL批量更新（开发成本最低） #

如果你不想做分组逻辑，可以直接用数据库原生的COALESCE函数改造更新语句，所有用户共用同一条SQL做批量更新：

update preferences set 
  pref1 = COALESCE(?, pref1), 
  pref2 = COALESCE(?, pref2) 
where userId = ?

逻辑说明：COALESCE会取第一个非null的参数值。如果某个偏好字段用户没传，你给对应参数位置赋值为null，SQL会自动保留数据库中原有的pref1/pref2值，不会覆盖。
注意：如果你的业务允许用户将偏好值主动更新为null，需要额外加逻辑规避，比如约定一个业务层面不会用到的特殊值作为「主动更新为null」的占位符，SQL里新增一层判断即可。

先查后写方案的适用场景 #

如果后续偏好字段扩展到10个以上，分组逻辑太过繁琐，且业务上不允许使用COALESCE方案，再考虑先查后写的逻辑，注意查询时用in语句批量查询所有待更新用户的原有值，不要单条循环查询，性能损耗也可控。

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