這兩個月都在搞一儲存過程，快要被它搞出精神病了。
主要是它執行的時間比較長，每次執行幾十分鐘是常有的事，幾個小時也不少見。甚至乎這幾天，執行了兩天一夜都還不知道何時會圓滿結束。等待本來就是乙個痛苦的過程，而這個過程要幾天幾夜，那我不瘋誰人瘋。
這肯定是有問題的。執行時間超過1小時的都應該有問題。
後來，改進了之後，時間至多幾十秒。
改進的關鍵在於使用了臨時表。
具體來說，就是將要處理的資料，從巨大無比的表裡面，先讀到臨時表，在執行過程中，就只從臨時表中讀取就好了。從處理幾千萬條記錄的表，到至多一萬條的表，資源的消耗一下子就降下來了，不可同日而語。
雖然，那個巨大表有索引，但始終比不上記錄數小的表。事實上，在我看來，無論是分割槽、建立索引，其本質都是減少處理的資料量。建立索引，可以快速找到要處理的資料，而無須全表掃瞄。這跟臨時表是殊途同歸的，而相比之下，臨時表效率更高，效果更明顯。
臨時表的資料準備好後，使用的次數也多，這個臨時表的經濟效益就越好，取得的成果就越大。至於插入資料時的一點點io，簡直不值一提。我想起在sql server中，有臨時表和表物件兩樣東西，究竟是用臨時表還是表物件？答案是，如果資料量大，應該用臨時表；如果只有區區幾十筆，則可以用表物件。為啥呢？因為臨時表資料真的儲存在物理磁碟，而表物件則存活於記憶體。記憶體不是比磁碟效率更高嗎？對，但問題是，記憶體也寶貴的多，你將大量的臨時資料儲存於記憶體，則資料庫能用的記憶體就少了，可能會引起它效能下降，因此得不償失。
所以說，為了生成臨時表，那一點點的磁碟io不值一提，完全不用考慮。
建立oracle的臨時表，類似地：
create global temporary table tmp_test
( id number ,
name varchar2(32)
) on commit preserve rows;建立出來之後，這個臨時表就跟其他物理表一樣可見，表面上看上去也沒啥區別；區別在於其資料，會被自動清掉。清掉的方式有兩種，取決於建立此臨時表時的指定：
1）on commit delete rows
事務提交則清空
2）commit preserve rows
會話結束則清空
SQLServer效能優化之活用臨時表
繼續調優，今天上午分析了以下一條處理時間達40秒的sql語句 select from table where t table id in select distinct s.t table id from select distinct a.t table id,a.bt from select l...
優化臨時表使用，SQL語句效能提公升100倍
sql語句如下 select distinct g.cp.name as cp name,c.name as category name,t.name as type name fromgm gameg left joingm cpcp on cp.id g.cp id and cp.deleted...
臨時表使用
臨時表語法 會話型的,會話結束資料清空 create global temporary table test tmp id number,name varchar2 10 on commit preserve rows 事務型的，事務結束資料清空 create global temporary ta...