平常開發中咱們常常會遇到大表的狀況,所謂的大表是指存儲了百萬級乃至千萬級條記錄的表。這樣的表過於龐大,致使數據庫在查詢和插入的時候耗時太長,性能低下,若是涉及聯合查詢的狀況,性能會更加糟糕。分表和表分區的目的就是減小數據庫的負擔,提升數據庫的效率,一般點來說就是提升表的增刪改查效率。mysql
分表是將一個大表按照必定的規則分解成多張具備獨立存儲空間的實體表,咱們能夠稱爲子表,每一個表都對應三個文件,MYD數據文件,.MYI索引文件,.frm表結構文件。這些子表能夠分佈在同一塊磁盤上,也能夠在不一樣的機器上。app讀寫的時候根據事先定義好的規則獲得對應的子表名,而後去操做它。sql
分區和分表類似,都是按照規則分解表。不一樣在於分表將大表分解爲若干個獨立的實體表,而分區是將數據分段劃分在多個位置存放,能夠是同一塊磁盤也能夠在不一樣的機器。分區後,表面上仍是一張表,但數據散列到多個位置了。app讀寫的時候操做的仍是大表名字,db自動去組織分區的數據。數據庫
1.都能提升mysql的性高,在高併發狀態下都有一個良好的表現。
2.分表和分區不矛盾,能夠相互配合的,對於那些大訪問量,而且表數據比較多的表,咱們能夠採起分表和分區結合的方式(若是merge這種分表方式,不能和分區配合的話,能夠用其餘的分表試),訪問量不大,可是表數據不少的表,咱們能夠採起分區的方式等。
3.分表技術是比較麻煩的,須要手動去建立子表,app服務端讀寫時候須要計算子表名。採用merge好一些,但也要建立子表和配置子表間的union關係。
4.表分區相對於分表,操做方便,不須要建立子表。併發
自5.1開始對分區(Partition)有支持app
舉個簡單例子:一個包含十年發票記錄的表能夠被分區爲十個不一樣的分區,每一個分區包含的是其中一年的記錄。
=== 水平分區的幾種模式:===
* Range(範圍) – 這種模式容許DBA將數據劃分不一樣範圍。例如DBA能夠將一個表經過年份劃分紅三個分區,80年代(1980's)的數據,90年代(1990's)的數據以及任何在2000年(包括2000年)後的數據。
* Hash(哈希) – 這中模式容許DBA經過對錶的一個或多個列的Hash Key進行計算,最後經過這個Hash碼不一樣數值對應的數據區域進行分區,。例如DBA能夠創建一個對錶主鍵進行分區的表。
* Key(鍵值) – 上面Hash模式的一種延伸,這裏的Hash Key是MySQL系統產生的。
* List(預約義列表) – 這種模式容許系統經過DBA定義的列表的值所對應的行數據進行分割。例如:DBA創建了一個橫跨三個分區的表,分別根據2004年2005年和2006年值所對應的數據。
* Composite(複合模式) - 很神祕吧,哈哈,實際上是以上模式的組合使用而已,就不解釋了。舉例:在初始化已經進行了Range範圍分區的表上,咱們能夠對其中一個分區再進行hash哈希分區。 高併發
舉個簡單例子:一個包含了大text和BLOB列的表,這些text和BLOB列又不常常被訪問,這時候就要把這些不常用的text和BLOB了劃分到另外一個分區,在保證它們數據相關性的同時還能提升訪問速度。性能
[分區表和未分區表試驗過程]
*建立分區表,按日期的年份拆分測試
[sql] 大數據
注意最後一行,考慮到可能的最大值
*建立未分區表ui
[sql]
*經過存儲過程灌入800萬條測試數據
mysql> set sql_mode=''; /* 若是建立存儲過程失敗,則先需設置此變量, bug? */
MySQL> delimiter // /* 設定語句終結符爲 //,因存儲過程語句用;結束 */
[sql] view plain copy
Query OK, 1 row affected (8 min 17.75 sec)
[sql] view plain copy
Query OK, 8000000 rows affected (51.59 sec)
Records: 8000000 Duplicates: 0 Warnings: 0
* 測試SQL性能
[sql] view plain copy
+----------+
| count(*) |
+----------+
| 795181 |
+----------+
1 row in set (0.55 sec)
[sql] view plain copy
+----------+
| count(*) |
+----------+
| 795181 |
+----------+
1 row in set (4.69 sec)
結果代表分區表比未分區表的執行時間少90%。
* 經過explain語句來分析執行狀況
[sql] view plain copy
/* 結尾的\G使得mysql的輸出改成列模式 */
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: no_part_tab
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 8000000
Extra: Using where
1 row in set (0.00 sec)
[sql] view plain copy
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: part_tab
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 798458
Extra: Using where
1 row in set (0.00 sec)
explain語句顯示了SQL查詢要處理的記錄數目
* 試驗建立索引後狀況
[sql] view plain copy
Query OK, 8000000 rows affected (1 min 18.08 sec)
Records: 8000000 Duplicates: 0 Warnings: 0
[sql] view plain copy
Query OK, 8000000 rows affected (1 min 19.19 sec)
Records: 8000000 Duplicates: 0 Warnings: 0
建立索引後的數據庫文件大小列表:
2008-05-24 09:23 8,608 no_part_tab.frm
2008-05-24 09:24 255,999,996 no_part_tab.MYD
2008-05-24 09:24 81,611,776 no_part_tab.MYI
2008-05-24 09:25 0 part_tab#P#p0.MYD
2008-05-24 09:26 1,024 part_tab#P#p0.MYI
2008-05-24 09:26 25,550,656 part_tab#P#p1.MYD
2008-05-24 09:26 8,148,992 part_tab#P#p1.MYI
2008-05-24 09:26 25,620,192 part_tab#P#p10.MYD
2008-05-24 09:26 8,170,496 part_tab#P#p10.MYI
2008-05-24 09:25 0 part_tab#P#p11.MYD
2008-05-24 09:26 1,024 part_tab#P#p11.MYI
2008-05-24 09:26 25,656,512 part_tab#P#p2.MYD
2008-05-24 09:26 8,181,760 part_tab#P#p2.MYI
2008-05-24 09:26 25,586,880 part_tab#P#p3.MYD
2008-05-24 09:26 8,160,256 part_tab#P#p3.MYI
2008-05-24 09:26 25,585,696 part_tab#P#p4.MYD
2008-05-24 09:26 8,159,232 part_tab#P#p4.MYI
2008-05-24 09:26 25,585,216 part_tab#P#p5.MYD
2008-05-24 09:26 8,159,232 part_tab#P#p5.MYI
2008-05-24 09:26 25,655,740 part_tab#P#p6.MYD
2008-05-24 09:26 8,181,760 part_tab#P#p6.MYI
2008-05-24 09:26 25,586,528 part_tab#P#p7.MYD
2008-05-24 09:26 8,160,256 part_tab#P#p7.MYI
2008-05-24 09:26 25,586,752 part_tab#P#p8.MYD
2008-05-24 09:26 8,160,256 part_tab#P#p8.MYI
2008-05-24 09:26 25,585,824 part_tab#P#p9.MYD
2008-05-24 09:26 8,159,232 part_tab#P#p9.MYI
2008-05-24 09:25 8,608 part_tab.frm
2008-05-24 09:25 68 part_tab.par
* 再次測試SQL性能
[sql]
+----------+
| count(*) |
+----------+
| 795181 |
+----------+
1 row in set (2.42 sec) /* 爲原來4.69 sec 的51%*/
重啓mysql ( net stop mysql, net start mysql)後,查詢時間降爲0.89 sec,幾乎與分區表相同。
[sql]
+----------+
| count(*) |
+----------+
| 795181 |
+----------+
1 row in set (0.86 sec)
* 更進一步的試驗
** 增長日期範圍
[sql] view plain copy
+----------+
| count(*) |
+----------+
| 2396524 |
+----------+
1 row in set (5.42 sec)
[sql] view plain copy
+----------+
| count(*) |
+----------+
| 2396524 |
+----------+
1 row in set (2.63 sec)
** 增長未索引字段查詢
[sql] view plain copy
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (0.75 sec)
[sql] view plain copy
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (11.52 sec)
= 初步結論 =
* 分區和未分區佔用文件空間大體相同 (數據和索引文件)
* 若是查詢語句中有未創建索引字段,分區時間遠遠優於未分區時間
* 若是查詢語句中字段創建了索引,分區和未分區的差異縮小,分區略優於未分區。
= 最終結論 =
* 對於大數據量,建議使用分區功能。
* 去除沒必要要的字段
* 根據手冊, 增長myisam_max_sort_file_size 會增長分區性能
[分區命令詳解]
= 分區例子 =
* RANGE 類型
[sql] view plain copy
在這裏,將用戶表分紅4個分區,以每300萬條記錄爲界限,每一個分區都有本身獨立的數據、索引文件的存放目錄,與此同時,這些目錄所在的物理磁盤分區可能也都是徹底獨立的,能夠提升磁盤IO吞吐量。
* LIST 類型
[sql] view plain copy
分紅4個區,數據文件和索引文件單獨存放。
* HASH 類型
[sql] view plain copy
分紅4個區,數據文件和索引文件單獨存放。
例子:
[sql] view plain copy
* KEY 類型
[sql] view plain copy
分紅4個區,數據文件和索引文件單獨存放。
* 子分區
子分區是針對 RANGE/LIST 類型的分區表中每一個分區的再次分割。再次分割能夠是 HASH/KEY 等類型。例如:
[sql] view plain copy
對 RANGE 分區再次進行子分區劃分,子分區採用 HASH 類型。
或者
[sql] view plain copy
對 RANGE 分區再次進行子分區劃分,子分區採用 KEY 類型。
= 分區管理 =
* 刪除分區
[sql] view plain copy
刪除分區 p0。
* 重建分區
o RANGE 分區重建
[sql] view plain copy
將原來的 p0,p1 分區合併起來,放到新的 p0 分區中。
o LIST 分區重建
[sql] view plain copy
將原來的 p0,p1 分區合併起來,放到新的 p0 分區中。
o HASH/KEY 分區重建
[sql] view plain copy
用 REORGANIZE 方式重建分區的數量變成2,在這裏數量只能減小不能增長。想要增長能夠用 ADD PARTITION 方法。
* 新增分區
o 新增 RANGE 分區
[sql] view plain copy
新增一個RANGE分區。
o 新增 HASH/KEY 分區
[sql] view plain copy
將分區總數擴展到8個。
[ 給已有的表加上分區 ]
[sql] view plain copy
默認分區限制分區字段必須是主鍵(PRIMARY KEY)的一部分,爲了去除此
限制:
[方法1] 使用ID
[sql] view plain copy
ERROR 1503 (HY000): A PRIMARY KEY must include all columns in the table's partitioning function
However, this statement using the id column for the partitioning column is valid, as shown here:
[sql] view plain copy
Query OK, 0 rows affected (0.11 sec)
Records: 0 Duplicates: 0 Warnings: 0
[方法2] 將原有PK去掉生成新PK
[sql] view plain copy
Query OK, 5374850 rows affected (7 min 4.05 sec)
Records: 5374850 Duplicates: 0 Warnings: 0
[sql] view plain copy
Query OK, 5374850 rows affected (6 min 14.86 sec)
Records: 5374850 Duplicates: 0 Warnings: 0