一般情況下在上篇文章的處理後，利用物化檢視，已經能夠解決複雜檢視的

查詢效率了，但是有時候資料量是在過大，且檢視中使用了很多自定義的函式。

這兩種情況單單是建物化檢視也提升不了效率。

    第一，資料量過大，物化檢視的建立及其緩慢，而且由於由於是做資料介面，要求

物化檢視的重新整理機制需要全表更新，使用force（即能全表更新是就全表，不能是則更新增量）

以保證物化檢視的資料的準確性。這就導致物化檢視的重新整理也很緩慢。

    第二，由於有的資料是通過自定義的函式獲取，而函式的執行也比較影響效率。

考慮到這兩種情況，且實踐證明物化檢視的確很緩慢，200w資料建了一天還沒建完，且導致Oracle

CPU佔用率極高，伺服器緩慢，故而停止了建物化檢視，思考新的方案，後面在請教經理後構思瞭如下解決方案。

第一，檢視中的資料來源於多張基表，可以建立一張表專門存多張基表的有效資料，這樣可優化掉檢視中的union all

第二，利用儲存過程將基表的資料同步到新表，同步過程中只取滿足條件的資料，降低資料量，減少where條件過濾。

第三，資料在新表中批量update相應需要使用函式的欄位，直接將資料更新為目標值，優化掉函式在介面中的使用。

第四，在新表上建檢視，該加索引的加索引。

第五，設定job每天執行儲存過程。

具體實施過程中可以使用以下技巧調高效率：

第一，新表使用獨立的表空間 ；

第二，新表設定為nologging模式加快操作效率。

第三，往新表插入資料時使用append歸檔模式加快效率。

第四，使用parallel並行度，開啟多執行緒模式。

通過以上操作後發現從新表上建的檢視查詢效率高了不止10倍，但是後面檢查發現一點自定義函式中要使用到幾張表

有的欄位沒加索引，這也會導致效率過低，一個查詢不僅僅要看where後面的欄位加沒加索引，還得注意select的自定義函式，點進去看，這函式裡那些查詢的where後面的欄位加沒加索引。