當面對巨大的資料表的時候，至少有一程式設計客棧件事情是確定的，錶太大了以至於每次查詢的時候我們沒法做全表掃瞄。而這個時候也沒法使用索引，或者說索引意義不大，更不用說索引的維護代價和空間占用非常高。如果是依賴索引，會導致大量的碎片和低聚集度的資料，這會導致查詢的時候有上千次的隨機 i/o 訪問而導致宕機。這種情況下一般只會使用1-2個索引，而不會更多。這種情況下，有兩個可行的選項：查詢必須從資料表的指定的部分順序查詢或者是期望的部分資料及其索引與伺服器的記憶體匹配。
需要再次重申：在儲存空間過大時，除非索引覆蓋了整個查詢，否則二叉樹索引就無法發揮作用。服務端需要查詢資料表的一整行資料，並且會在乙個大空間跨度裡執行隨機 i/o 操作，這會導致查詢響應時間無法接受。而維護索引（磁碟空間，i/o 操作）的代價同樣很高。
而這是分割槽能夠解決的問題。這其中的關鍵就是分割槽是索引的乙個初級形式，它的負荷低並且能夠讓我們從臨近的資料中獲取結果。這種情形下，我們可以依次掃瞄相鄰的資料或者是將臨近的資料載入到記憶體進行檢索。分割槽之所以負荷低是因為它並沒有指標指向對應的資料行，也不需要被更新。分割槽並不精確地將資料按行劃分，也沒有涉及到所謂的資料結構。實際上，分割槽相當於對資料進行了分類。
對於大資料表，有兩種策略進行分割槽：
兩種分割槽策略是基於兩個關鍵假設：在查詢的時候可以通過過濾分割槽縮小查詢範圍，且分割槽自身的代價不高。然而，這兩個假設未必總是有效，下面是可能遇到的問題：
如上所述，分割槽並不是完美解決方案，目前版本的 mysql還有一些其他的約束：
當然，隨著 mysql 版本的更新迭代，對分割槽的支援也越來越好，並且很多分割槽的問題都得到了修復。
資料表分割槽
create partition scheme userscheme as partition xkxuserrange to xkxuser01 xkxuser02 xkxuser03 xkxuser04 xkxuser05 xkxuser06 primary create partition f...
sql資料表分割槽
一般情況下，我們建立資料庫表時，表資料都存放在乙個檔案裡。但是如果是分割槽表的話，表資料 就會按照你指定的規則分放到不同的檔案裡，把乙個大的資料檔案拆分為多個小檔案，還可以把這些小檔案放在不同的磁碟下由多個cpu進行處理 分割槽函式,將資料對映到一組分割槽上。create partition fun...
MySQL對資料表已有表進行分割槽表
對現有的乙個表進行建立分割槽表，並把資料遷移到新錶，可以按時間來分割槽，然後這錶不是實時更新，每天有一次插入操作。時間比較充裕，但是伺服器上有其他應用，使用較小資源為主要方式。1 可以使用alter table來進行更改表為分割槽表，這個操作會建立乙個分割槽表，然後自動進行資料copy然後刪除原表，...