sql优化之：批量处理和分批处理

周五按照客户要求，修改任务参数，重新抽取1-5月的数据，默认情况下只会抽取最近2个月的数据。

到了周六，发现任务从早上9点到下午4点，持续了7个小时，考虑到之前一次同步4个月的数据也就是3个小时左右，正常应该早就跑完了。

于是把任务给kill掉了，但从下午4点开始rollback，还好晚上10点回滚完了。。。

这次由于同步大量数据，导致任务运行失败的问题，我想了几点影响因素：

1、这次任务为什么跑了7个小时仍然没跑完？

经过监控，发现任务在近12点时，就已经运行到最后一步了，只要把数据insert到结果表就完成了，可是一直卡在这一步。

想到的原因可能是 ：

（1）这个任务 从远程拉取数据到本地的临时表，然后接下来insert到目的表，都在1个事务中，涉及到数据700w左右，会产生大量日志，很有可能是日志空间无法及时扩展，导致卡住的，虽然从监控信息没有看到任何日志相关等待。

（2）目的表有15个索引，索引空间比表本身数据还大，占到70G，导致索引维护的成本很高，时间很长，但这个表也只有140G左右，不算很大

2、一般来说批处理的效率要高于分批处理的效率，为什么会卡住？

在周日改为分3次处理后，消耗3个多小时，总算任务成功了。

批处理比分批处理的效率还低的原因：

我觉得主要是批次的大小，1-5月这批次太大，包含了近700w的数据，而且还是远程抽取的，分成3个批次后，每个批次的数据量在200多w，使得每次处理的数据量小了很多，对网络流量、事务日志、数据空间扩展、内存、磁盘资源的压力就小很多，使得任务最后能跑完。

总结：

从对这2个问题的思考，知道了平时表现很好的任务，在抽取数据量压力增加了3倍后，会出现异常，之所以这样，主要在于1个批次处理的数据量太大，对各种资源的压力太大，让资源满负荷的跑，只要其中有一个没满足，任务就会一直跑，总也跑不完。

所以，对于这种问题，可以采用分批次处理，降低对资源的压力，虽然单个批次的时间长了，但是不至于跑不完。