MybatisPlus批量更新的小插曲

插曲背景

在商城项目中涉及订单业务，有两个主要的表：订单表order和订单明细表order_detail。

• order表：主要存储订单的主要信息，订单总金额，收货人信息，订单状态等；
• order_detail表：主要存储订单购买的商品明细信息，每个SKU一条记录；

order表和order_detail表的主键id都是自增的，order表有一个sn字段，order_detail表有一个order_sn字段，这两个表通过sn和order_sn两个字段进行关联，实现业务：1个订单有多少条订单明细记录。

插曲描述

项目增加一个状态同步需求：更新order记录的状态status，同时更新对应的订单明细记录的status。

在开发环境联调测试都是ok的：下单 -> 更新订单状态。然后，在sit测试环境出现一种奇怪的现象，执行状态更新操作之后，指定订单对应的所有的订单明细记录数据全部都变成一样了，且每条记录的id均为0。

因为之前订单功能是已上线的，且数据库变更的管理采用flyway组件，同样的代码在不同的环境执行效果不一样，只能猜测是环境不一样导致的。

开发人员没有sit环境数据库的更新权限，只有只读权限。

问题排查

在更新逻辑代码中增加执行日志输出，重新提测之后。观察操作执行的日志，发现：在【下单】操作之后，生成的订单明细记录id均为0；继续执行更新操作时，所有的订单明细记录数据全部更新为相同的数据。批量更新使用MybatisPlus的updateBatchById方法。

针对上述情况，第一反应是原本自增的id字段值为啥都是0？查看一下sit环境order_detail表的设计语句，发现id字段没有被设置为：自增。再核对了开发环境order_detail表的设计语句，id字段是自增的。

造成问题的原因出来了：sit环境和dev环境的表结构不一致了。将sit环境order_detail表的id设置为自增，重新测试该需求功能，好了！

问题反思

1. 越让人放心省力的方法，一旦出现问题，越不好排查问题（通过flyway保证各个环境的数据表结构一致，也要小心使用）；
2. 敢于质疑，由于一开始并没有想到会是环境不同导致的问题，一致代码层面排查，所以浪费了时间，比如：修改可疑的代码，增加日志输出等工作。