某年某司，我实现了一个核心业务逻辑，很复杂，因为尽量使用各种批处理和字典，所以跑起来还是相对比较快。

多年后，逻辑变得更复杂，性能变得很差，用户看见的就是操作超时的错误。

我接手，分析后，发现他们为了实现更多的逻辑，循环地处理每条记录，然后每条记录都多次去数据库拿不同的数据来做实现各种逻辑。

更糟糕的是，每个循环里面，还会套循环，然后每个子循环都可能会去数据库取数据然后跑复杂的业务逻辑。

最糟糕的是，每个数据库访问逻辑，都是用的ORM，而且这些ORM逻辑是没有经过优化的，而且会重复取一样的数据。

如果你遇到这种情况，你会：
A. 排查性能最差的那个逻辑，然后就优化那个逻辑（但是需要考虑积少成多，记录数多了，每条加起来的总时间也会很长）
B. 重写整个逻辑

我一般是按照给定的交付时间来决定。如果时间/成本允许，我会选择重写。否则，只能先做性能分析，找到最慢的那几个逻辑，然后改造。

鉴于时间等资源有限，没有采用重写，而是尽量使用批处理。经过优化，现在的速度提升了18倍。

主要优化手段是把需要使用的数据库记录都预加载，然后传递到每个循环中，大大减少了频繁细小的数据库操作。