2月份年后上班，刚过完年，还没从喜悦中解放出来，凌晨3点的时候同事就给我打电话，晚上的批量处理任务卡住了，快帮忙看看，做了几分钟的心里建设之后从被窝爬起来，看着手机上好几电话，赶紧开始看看咋回事。
第一步，找到问题，批量处理的任务 1点多就开始不再运行，三点多才被发现，赶紧先让任务运行起来呀，尝试重启任务，没有用，再看看，数据量太大了，任务执行超时停止了，原来的代码没有真实应付差事，前辈们优化好几轮，都是浅尝辄止，没什么有效的操作，紧急部署也是来不及了，就对任务数据做分批处理，紧急拆分任务，总算开始跑了，就是太慢了，10秒才3条交易处理完成，看着上百万的数据量，眼前就那么一黑啊，有种想提桶跑路的冲动，继续拆分，拆了20000多个任务去处理，总算是好一点了，大概三个小时能跑完。
继续监控任务执行情况，趁着监控的时候，看看前面几天的批量处理任务日志，我去，年前的一个小时执行时间涨到夸张的6个小时，各位运维的同事在做什么？今天晚上总算跑不动了！我们真的是有一个神仙客户啊，这样都没投诉。看看问题在哪？年前一波促销，业务量暴增，数据量也是好几番啊，找到耗时长的代码段，又是前辈的炫技，除了花里胡哨，就是烂。
总结分析：问题1，代码花里胡哨的，但是无效处理太多，重复太多，造成耗时大增，处理方案优化代码，删除无效逻辑。
问题2:一个sql 查询，五六张表，各种条件随便在后面加，优化方案，拆分sql，综合考虑应用和sql耗时，非索引条件，根据数据量考虑是否放在应用中处理。
问题3: 数据库选型不适合，数据库架构不适用于现在千万级数据处理，这个是个大活，只能徐徐图之，总有种当年骗钱来着的感觉。
补充解决方案：1，动态拆分批量处理任务，将一个总的任务根据数据量动态拆分若干子任务。
2，增加监控，在1个小时内没有完成就对运维人员的告警。
差不多整理完问题并且完成修复，批处理任务也结束了，一看时间，哋，快8点了，赶紧洗漱一下，去吃个早饭，然后和周公一起骂前辈去了。