上週我寫了一篇博文，裡面有一點關於分割槽表的論述（但是我發現我少寫了一點，在你的查詢條件和分割槽列沒有太大關係的時候，分割槽表不會幫助你提高效率。
我是按照area_id分割槽的，圖1的執行計畫：
圖2的執行計畫：
建立一張表，這張表的資料和test一樣，但是沒有分割槽，執行一下圖1中的語句，檢視其執行計畫：
可以明顯的看出來，分割槽表的執行計畫多了乙個partition list all，明顯增加了cpu的耗用。再看看圖2中sql在test111中執行的執行計畫吧：
確實很明顯，這裡少了partition list single，但是cpu的耗用卻沒有變，當然了，我這個表非常非常小，如果資料量超過千萬級，那麼就能看出好處了。
從上述對比中可以很明顯的看出來，分割槽表的使用是要看實際應用的需求的。如果儲存過程始終是按照某一條件對資料進行查詢，就像是圖2中那樣，每次查詢的時候總是要帶上area_id，那麼建表的時候就可以考慮按照area_id進行分割槽。但是如果你平時的查詢沒有什麼規律可循，那麼你分割槽了，也許好心辦壞事。
為了這篇博文，小弟在此豁出去了，不停地插表，現在搞出了一張3145728的test表和test111表，兩個表資料一樣，test有分割槽，test111沒有。再看看執行計畫，首先是sql：
select*from test a where a.item_id =
1and a.area_id =
290;
select然後是執行計畫：*from test111 a where a.item_id =
1and a.area_id =
290;
看看，用了分割槽表之後雖說cpu的cost增加了，但是rows和bytes都有了十分可觀的降低。再將表擴大一倍，分割槽表和非分割槽表的rows比達到了2159k：10m，而bytes比也達到了 121m：594m，cpu cost比：14487：8847。上帝啊，分割槽表在降低讀取量方面堪稱出色，但是在增加cpu cost方面堪稱令人髮指。
以前看過蓋國強的書，裡面說優化sql主要是降低其物理讀。但是我想如果能降低這裡的rows和bytes，對於乙個小機環境的資料庫處理器來說，高一點的cpu cost也是可以理解的吧。
關於分割槽表的操作
建立分割槽表 範圍分割槽 create table t partition by ranger range key column partiton part1 values less then partiton part2 values less then hash 分割槽可以是資料分散從而更好的避...
關於分割槽表的使用
關於分割槽表的使用 最近在使用oracle的分割槽表，有點心得，對之後的效能優化可能有幫助，先記著.表a，有type欄位，一般只記錄1和2，1表示某一類資料，2表示另外一類資料，一般對於這種字段建立索引是沒有意義的，因為就只有1和2兩個值，就算建了索引，一般oracle也不會用。例如，有如下查詢 s...
把非分割槽表改為分割槽表
把非分割槽表改為分割槽表 說明 把非分割槽表改為分割槽表適用於歷史表 1 建立分割槽表 結構和非分割槽表tbl stock balance log相同 createtabletbl stock balance log part1 account id varchar2 20 byte occur d...