前一陣子寫了一點有關分割槽表的東西（我們的專案限於甲方的摳門，分配給我們的磁碟空間相當的小，因此我們的專案中並不習慣使用索引這個好用的東西，因為索引也是要耗用很大的空間的，有的時候索引佔據的空間比資料表還要大。於是我們約定俗成的使用了分割槽表，而且很多同事認為分割槽表就相當於建立了很多很多的小表一樣。事實，確實如此嗎？
建立一張分割槽表test1，按照month列進行分割槽，資料量大概在1200萬左右，201205這個分割槽中有4194304條記錄。
建立一張表test_201205，結構和test1一樣，只不過只有test1這個表的一部分資料，也就是存在201205這個partition中的所有資料，4194304條記錄。
對兩張表analyze，這樣一來就保證了oracle能正確的生成執行計畫。
首先看看分割槽表的執行計畫：
非常好的使用了分割槽條件。
接下來統計下test_201205的執行計畫，如圖：
由此可以看出，物理存在的表還是要快一點，但是這個差異已經不大了。
但是有乙個有意思的現象，如果把小表中的查詢條件加上，就會發生有意思的變化：
加上了乙個無關緊要的條件，cost就變成了和分割槽表一樣的數值。這是為什麼，我還是以後慢慢**吧。
從我以上的**和過去的博文中的研究可以看出來，分割槽表在某些時候還是比較具有優越性的。
但是空分割槽還是要佔據空間的。其他的，以後慢慢研究吧。
把非分割槽表改為分割槽表
把非分割槽表改為分割槽表 說明 把非分割槽表改為分割槽表適用於歷史表 1 建立分割槽表 結構和非分割槽表tbl stock balance log相同 createtabletbl stock balance log part1 account id varchar2 20 byte occur d...
sqlserver 分割槽表
1 建分割槽函式，用於自動劃分物理表資料的流向 建好後可以在databases dbname storage中看到 下面分成四個區域 bigscreen且 computer且 pooltable 若是right，則x1 bigscreen x2 computer x3 pooltable x4 若是...
GPT 分割槽表
guid 分割槽表 gpt 一種由基於 itanium 計算機中的可擴充套件韌體介面 efi 使用的磁碟分割槽架構。與主啟動記錄 mbr 分割槽方法相比，gpt 具有更多的優點，因為它允許每個 磁碟有多達 128 個分割槽，支援高達 18 千兆兆位元組的卷大小，允許將主磁碟分割槽表和備份磁碟分割槽表...