会员系统会员合并逻辑设计疑问

对于会员系统，存在会员合并的逻辑，可能由于用户手动合并或者系统因为用户补充了部分信息可以判定为同一个会员时就会触发合并。
假设现在系统中有两个会员：
userId1 和 userId2
那么对于其他业务系统，比如订单，微服务方式设计
可能因为历史存在了以下数据：
order1 -> userId1
order2 -> userId1
order3 -> userId2

那么会员系统合并之后，业务系统应该如何操作，现在想到两种操作
1. 逐个去 update 订单归属的会员
2. order 用 in (userId)的方式进行关联

第一种方案对于原始数据进行了操作，繁琐且感觉不一定可靠，业务微服务得监听会员合并事件，如果操作的时候遗漏了就麻烦了
第二种方案需要 其他的业务微服务比如 order 去理解会员合并的逻辑，感觉逻辑不太干净

求问各位还有其他更好的思路吗