在软件程序的处理性能中，速度是永恒的真理。换言之，速度是最重要的指标。如果是简单，数据处理量小的程序，只要设备安装了时下主流CPU和足够的RAM，在处理速度方面一般不会带来麻烦。但是，如果程序需要处理海量数据，由于设备架构（基本设计和设计思路）不同，在处理时间上就会产生明显差异。

若是经验尚浅的软件工程师，为了满足规格条件就已焦头烂额，可能完全无法顾及处理速度。这次为大家讲述的是我入职半年后，首次独立开发子系统的经验。我是如何解决所遇到的障碍（改善处理时间）的呢？算不上什么先进的经验，仅供大家参考。

开发课题是数据迁移工具

交予我开发的子系统因为系统更新，需要将某个旧系统中的数据迁移至新系统用的子系统。现在已经很少这样做了，具体内容是创建一个将SQL组合在一起的存储过程（将多个处理位汇总在一起的程序），然后依次启动批处理文件，在数据库之间进行数据转换和迁移处理。

最初，我自认为这是一个非常简单的程序（新人非常容易犯的毛病…），但后来才发现，其实这并不单纯是数据迁移的问题，如果在运用维护方面考虑到用户体验的话，处理时间是很大的瓶颈。

开始着手这项工作时，我考虑的比较简单，认为只要通过单纯的规则便可实现迁移。但随着工作的进展，最终发现问题远非想像的那般简单，遇到了障碍──程序处理时间比较长。处理时间长不仅令用户体验差（用户压力），而且在调试过程中，如果出现某种问题，很难调整。

处理时间变长的原因

处理时间变长的原因主要可以归结为如下两点：

（1）旧系统的数据规格不规则，而且存在多种数据模式

在旧系统中，用户可以自由地编辑格式和决定规则，任意创建数据。因此，为了能够把所有用户数据迁移到新系统之中，需要在所有数据库表中嵌入转换处理程序。
实际试运行后发现，产生了多层的条件分支，其处理时间超过了预期。另外，不仅仅是转换处理时间的问题，导入之前旧系统中的数据规格也耗费了相当多的时间。

（2）需迁移的数据庞大

表有100多个，而且每个表的记录数量高达几百万条。由于旧系统中的运用记录数量庞大，只单纯的设定条件进行处理，处理时长会与记录数量的增加成正比。调试是使用样品记录，通过少量数据实施的，并没有太在意处理速度的问题，但首次进行联机测试时，实耗时间半天以上，简直让我无言以对。

鉴于此情况，我曾考虑通过新系统端的数据库设计调整解决该问题，但数据转换规格已经有了约定，只能采用改进表索引等方式，但仍然无法改善速度，作为入职经验不满一年的工程师，一时无法想到其他解决方案。

尝试逆向思维

当时感觉在这种情况下已经束手无策了，但转念又一想，既然已无计可施，何不转变想法，尝试一下其他的方法呢？于是开始挑战表分割，表追加，也就是分散处理。

按常理来说，将处理进行分散或增加只是单纯的增加工作量，反而会更浪费时间。当时，我自己也认为虽然可以分散处理，但程序会增加，分散后还需组合在一起，通过表的分割处理和表的追加，效果可能并不太好。但实际尝试后发现，处理时间居然减少了约10%。

冷静地仔细思考后发现，旧系统的数据多达几百万条记录，单纯地访问表就会花费很多处理时间。只要事先将表分割，对访问处理进行分散，便可有效地改变处理时间。
得出这一结论后，改善速度加快，完成了所有表的调整等工作。同时，在作业推进过程中，还发现了另一个改善点。

那就是，使用SQL可以组合和提取多个表，还可以对其进行多阶段组合。最初，按照数据转换，迁移的规则，单纯编写了SQL，所以制作了形成表组合队列的存储过程。

如此，该存储过程看上去像是在访问数据库的表，但实际上是在访问SQL的处理结果（查询），即虚拟表，并非实际的表。因此，与相同的记录数量相比，仅仅用SQL编写的存储过程的处理时间会大幅增加。着眼于这一点，通过进行表分割和设置过渡表，处理时间最终减少了约30％，总算完成了这项工作。

答案往往在“对面”

还是新人的时候，关注点只在按规格编写方面（符合规格要求，没有必要进行调整），从未考虑过处理时间的问题，但通过这次经验，我深刻地认识到站在各个不同角度研究问题的重要性。

我们很容易误解，增加程序＝延长处理时间，但如果把目光转移到处理分散等方面，也许结果会发生翻天覆地的变化。不仅SQL如此，我觉得其他程序语言也是相通的。在开发过程中遇到难以跨越的障碍时，先将自己的想法清零，通过逆向思维等方式，站在第三方视角冷静思考是一种有效的手段。

进入最后阶段时，我们会把视线集中到一个方向，自己一般意识不到。这种情况下，问题的答案往往在“对面”，而自己一个人是很难注意这一点的。即使能够发现，可能也会花费相当长的时间。因此我认为，开发不应该由一个人进行，而应该从封装之前的设计，评审阶段开始，由组织（团队）进行推进。这样能快速发现问题，很大程度上也可以避免开发上的返工（＝提高开发速度）。我希望年轻的开发人员能够认识到这一点。