2016年6月4日
摘要：
性能瓶颈在1734表的重复扫描。 想进一步研究，继续往下看 在oracle和sqlserver中，join有3中算法，分别是循环迭代，组合，哈希。而这3种算法，都要进行全部匹配。MySQL没有组合连接，只有两种算法。 而exist 和 in会根据统计信息，自动选择用半连接算法，（not exist 阅读全文
posted @ 2016-06-04 10:03
terry.zh
阅读(254)
评论(0)
推荐(0)
摘要：
性能瓶颈应该是在1014表的扫描上面。后面的代码是jxjjFXRXX_S.gz产品优化过的。替换后应该会有不小提升。 zmddhfxrxx_S.gz跟这个一样改法。 61分钟->1分钟 想进一步研究的，继续往下看 1.with里面 对1429进行了两次全表扫描，可以通过用unpivot合并成一次。（ 阅读全文
posted @ 2016-06-04 09:39
terry.zh
阅读(206)
评论(0)
推荐(0)
摘要：
性能瓶颈在函数的乱用。原代码黄色部分。 12分钟->35秒 1.对两个函数调用多次，而且两个函数之间还有调用关系。（优化器是可以自动把函数体拆出来，拼到主查询里面一起优化的。但是太复杂了它也蒙。） IsSpecial和gettradedate函数都是从1010表拿数据。 IsSpecial 扫2次1 阅读全文
posted @ 2016-06-04 09:34
terry.zh
阅读(229)
评论(0)
推荐(0)
摘要：
有几张表没有权限，所以跑不起来。 目测黄色部分比较坑爹，死了n多脑细胞才看懂，又死了n多脑细胞才改出来。对5034进行了2次扫描，并多次分组排序求和。（分组和排序算法相对来说比较耗性能） 改为只扫描一次，一次编号操作。 这个没有什么既定的规则，就是使劲想各种奇葩办法简化。（这个改写就是利用了orac 阅读全文
posted @ 2016-06-04 09:30
terry.zh
阅读(391)
评论(0)
推荐(0)
浙公网安备 33010602011771号