一张表（库存待调整明细）记录了不同区域的门店各商品的两个数值，可调出数（超过库存可分给其他差货门店的数量），需调入数（库存不足需要从超库存门店调入），每个记录要么可调出 >0，需调入=0；要么可调出=0，需调入 >0。
工作流 1：自定义按钮（单条数据）串行，获取当相同区域、相同商品、id 不等于触发记录、需调入数 >0 的多条记录，子流程串行处理（将本记录可调出数减少至 0 或子流程中不存在需调入数 >0 的记录）；
工作流 2：自定义按钮（单条数据）串行，获取当相同区域、相同商品、id 不等于触发记录、可调出数 >0 的多条记录，子流程串行处理（将本记录需调入数减少至 0 或子流程中不存在可调出数 >0 的记录）；
结果工作流 1 每 15-20s 处理一条，工作流 2 几乎每秒处理 2-5 条，表内共 50000+ 数据需处理，工作流 1 需要 208 小时，工作流 2 需要 6 小时，卧槽这差距也太大了，我想破头也想不出来，为啥差距这么大
每次处理 1 条当然慢，每次可以处理 200 条，全读出来，算好写回。
次与次之间是串行，一次内的 200 条并行。
子流程逐条执行完再执行下一个，是这样的，如果设置严格执行，更加慢（仅按钮可以设置，工作流只有并行）
我每周生六千多的填报空数据，近一个小时都有
但是同样的执行模式，需调入的去匹配可调出的就要比可调出的去匹配需调入的快这么多，这个就值得思考了，啧啧啧，写工作流真的还是需要点技巧的 😄 剩下的就是对硬件，至强 12 核，120GB 内存，固态硬盘搞上，哈哈哈
子流程逐条执行完再执行下一个，是这样的，如果设置严格执行，更加慢（仅按钮可以设置，工作流只有并行）
我每周生六千多的填报空数据，近一个小时都有
应该有比较好的 Method，从多条数据中筛选部分数据再去匹配多条数据中的 部分数据，不然工作流还没执行完 ，人家客户都下班了。
子流程逐条执行完再执行下一个，是这样的，如果设置严格执行，更加慢（仅按钮可以设置，工作流只有并行）
我每周生六千多的填报空数据，近一个小时都有
