統(tǒng)計(jì)24小時(shí)的紅包感知專題，有1.5億行以上的數(shù)據(jù)，Nokia給出的方法是先按小時(shí)執(zhí)行算法，再匯總各個(gè)小時(shí)的執(zhí)行結(jié)果。

算法中包含了大量的 sum(case when)計(jì)算。

專題里有5個(gè)小節(jié)，執(zhí)行計(jì)劃的時(shí)候，需要跑5次where條件不同而查詢列相同的sql，需要執(zhí)行5次sum(case when)，很耗時(shí)間。

統(tǒng)計(jì)一天24小時(shí)的數(shù)據(jù)，需要9個(gè)多小時(shí)才能計(jì)算完成。

--------------于是我想優(yōu)化這個(gè)執(zhí)行過程--------

我把每小時(shí)的數(shù)據(jù)case when的計(jì)算先執(zhí)行，合并24小時(shí)各小時(shí)的case when 結(jié)果，然后再對(duì)合并的執(zhí)行sum等計(jì)算。

發(fā)現(xiàn)select時(shí)速度很快，sum速度也快，5個(gè)小節(jié)，執(zhí)行計(jì)劃時(shí)只要執(zhí)行一次case when，5次sum，按理速度應(yīng)該會(huì)提高很大。

--------------沒想到，現(xiàn)實(shí)不是這樣的，居然還原來的快----------

找原因，發(fā)現(xiàn)問題在 create table xxxx as select 的性能問題

原來的方法雖然執(zhí)行了5次sum(case when)，很耗時(shí)間，但因?yàn)閰R總了數(shù)據(jù)，create table 的表行數(shù)少，創(chuàng)建表的速度快。

-------------

優(yōu)化后的方法，雖然select速度很快，但是創(chuàng)建表的行太多，24小時(shí)有1.5億行+，這個(gè)表好大啊，create table xxxx as ?select 的執(zhí)行耗時(shí)比上面的還要多。

于是我醉了，2天的優(yōu)化，白弄了。

--------下文是create table as select 性能優(yōu)化方法------

http://blog.csdn.net/yangzhijun_cau/article/details/7396088

可專題工具系統(tǒng)在代碼里硬編碼了create table as select 的語句，不能加入優(yōu)化方法里的參數(shù)，優(yōu)化的方法用不上。

總結(jié)

以上是生活随笔為你收集整理的当create table as select 遇上大数据的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。