前言
大家可能都有遇到类似这样的紧急情况吧：
系统投产上线，程序例如存储过程负责数据转换的部分，跑起来后生产环境居然发现比测试环境慢了很多！不知道什么时候能跑完，投产窗口又有限，气氛一度紧张起来…
客户领导紧急协调各专家分析，核查一圈下来，基本定位为：
生产环境比测试环境的IO要慢！
是的，基础架构的问题，短时间内也无法解决呀！
总计有6000万的数据需要处理，现在过去半个小时了，300万条数据都没处理完呢！
这个时候是继续等待还是启用紧急优化手段…
继续等待，不知道什么时候才能结束，真的是难以决策啊！
实际上，造成这样难以决策的情况，除了环境不一致的问题外，主要是因为缺少量化思维导致的！
那么什么是量化思维呢？
简单说，一个SQL或存储过程在执行前就可以通过计算来预估他正常应该跑多长时间时间！
要做到这个程度，确实很难，很多人终其一生，也没找到答案。做到执行时间可量化可预估，需要结合软件的算法以及基础架构的硬件能力！而软硬件都要熟悉，因此国内很少有人可以做到量化思维。
1月6日（周四）的分享和直播，小y将为大家分享一个存储过程优化的故事！
看小y是如果通过量化思维预估当前方案的执行时间无法满足投产窗口后，果断放弃当前变更方案，然后启用紧急优化方案解决这次危机的！
量化思维,cool!
独特的视角和经验分享，今晚的直播，开发人员和DBA不要错过哦！也希望大家在方便的情况下帮忙转发和分享给大家，您的支持是我们持续分享干货的动力！
新年来享新福利啦！！！！大家心心念的小y开课了！不要1288，不要398，拼团成功299，量化思维带回家！！！2022年，对自己好一点，送自己一个课程！
1. 问题来了
“一个月的数据，跑了半个小时了，还没跑完，我测试环境15分钟就跑出来了，是不是生产环境有问题啊，这样下去不行啊，后面还要跑20个月的数据呢”
人山人海的投产室里，突然气氛一下紧张起来。
客户的领导们也纷纷聚了过来，开始组织大家分析。
小y 自然也开始准备介入问题的分析。在客户帮助小y登录环境的过程中，负责基础架构环境的客户，好像有了一些进展，略带内疚地给大家解释到：
“这个系统，测试环境一开始跑不出来，后来我们给迁到了SSD闪盘上！”
“不过现在生产不是跑在SSD闪盘上，性能肯定是比不过测试环境的SSD存储性能的”
话音一落，糟糕，好像给判了刑！
“别着急，让小y先看下，会有办法的！…”
作为为客户提供第三方优化服务的我们, 小y听到这样的认可，心里还是暖洋洋的！
文章到这里，大家不妨停一下，思考一下，如果是你，接下来你打算分几步来分析，又需要哪些信息来帮助你找到问题的原因，如何解决呢…
思考时间
……
……
什么时候往下翻，由你决定…
……
2. 存储过程代码
于是小y拿到了存储过程的代码，如下图所示。
看得出来，开发还是用了心思来设计这次任务的！
对大表的更新支持并发处理，每个并发处理一个月的数据。
只不过最开始先启用了2个并发，分别处理2个月的数据的时候，就出现了性能比测试环境慢不少的情况，所以也就自然不会再继续增加并发了！
3. 思考时间
好的，如果是你在现场，存储代码也给到你了，
接下来你是如何理解这段存储过程代码的呢？
另外，接下来你会用什么方法论来分析以及应急处理这个问题呢？
……
……
什么时候往下翻，由你决定…
……
4. 头脑风暴
看到这里，可能有小伙伴们跃跃欲试了。
01
BIG_TAB_6000W_ROW按月处理，每个月数据300万左右，那么游标定义cursor的部分走全表扫描和走索引都不合适，是该表没有做分区导致的么？
答案是NO！
BIG_TAB_6000W_ROW是一个分区表，分区字段为WORKDATE，按月分区。
02
是大表BIG_TAB_6000W_ROW更新语句where过滤条件没有创建合适的索引导致的么
答案是NO！
该表存在一个复合索引，复合索引的前两列就是WORKDATE, AGENTSERIALNO。
其中AGENTSERIALNO选择性很好，不同的值的个数2000多万个！如下所示
03
是小表T_MAP_1000_ROW过滤条件oldbrno=:1 缺少索引导致的么，小表的相关查询如下图2个，虽然小，如果没有索引，但是会被执行6000W*2次小表全表扫描，是不是时间都花在了这个最不可能出现问题的环节呢？
答案是NO！
该表存在一个主键，是一个复合索引，复合索引的顺序为OLDBRNO, NEWBRNO，表中OLDBRNO是唯一的，如下图所示
其次，只要全扫一次，小表是很容易被缓存的，那么接下来就是全部在CPU上了，接下来就很快了！
5.基于量化思维下的
应急优化与决策！
我们不妨回顾下相关的信息：
存储过程最终要更新的大表BIG_TAB_6000W_ROW是一个分区表，分区字段为WORKDATE，按月分区
大表BIG_TAB_6000W_ROW总计保存20个月的数据，每个月的数据为300万左右
存储过程中涉及的小表T_MAP_1000_ROW记录数为1000行左右
大表和小表的过滤条件都有高效的索引，实际当中也走了这些高效的索引
小y检查了一下，测试环境用SSD，IO响应时间大概0.5毫秒
生产环境没有用SSD，IO响应时间大概4个毫秒，虽然比测试环境大，但实际上也在正常范围内。
有了这些信息，小y接下来开始通过量化思维给开发和客户的领导们计算和预估了存储过程中每一步的时间消耗！
是的，按照目前的情况，继续等下去，时间窗口是不够的！
然后小y提出了一个全新的应急优化方案！并重新计算了该方案下的时间。经过计算，10分钟左右就可以全部处理完成6000万的数据！
大家听完，有理有据，计算严谨，靠谱！
果然取消了当前执行的两个并发，并且按照新的方案实施，最后真的不到10分钟，数据全部处理完成！喜大普奔！
6. 真相即将揭晓
那么小y是如何通过量化思维预估该存储过程的执行时间的呢？
请关注上图中的视频号，并预约直播， 2022年01月06日（下周四）晚上八点，小y将用半个小时为大家揭晓真相并传播量化思维！记得帮转发，喊上你的开发同事和DBA朋友一起来参加哦。
更多实战分享和风险提示，请关注“中亦安图”公众号和小y视频号！也可以加小y微信，shadow-huang-bj，进微信群探讨技术。喜欢就转发吧，您的转发是我们持续分享的动力！
