更多
什麼是分割槽表
分割槽就是根據一定的規則，把一個表分解成多個更小的、更容易管理的部分，在邏輯上就只有一個表，但實際上這個表可能有N個物理分割槽物件組成，每個分割槽都是一個獨立的物件，可以獨立處理，可以作為表的一部分進行處理。

小試牛刀
看mysql是否支援分割槽
#檢視一下mysql版本

mysql> select version();

+------------+

| version() |

+------------+

| 5.7.11-log |

+------------+

1 row in set (0.02 sec)

#檢視是否支援表分割槽

出現partition的status為active說明mysql支援分割槽。

2.建立一個分割槽表

表建立成功後，我們會發現這個表(tb_partition_demo)包含了一個.frm檔案和4個.ibd檔案(每一個分割槽對應一個.ibd檔案)也就是說：

對於引擎層來說，這是4個表
對於Server層來說，這是1個表
所以分割槽對應用來說是完全透明的，我們就可以像使用普通表一樣來使用分割槽表，不影響應用的業務邏輯。

3.資料寫入分割槽表

上面寫入的3條資料，”劉備“會被寫入到partition_2018分割槽中，”關羽“會被寫入到partition_2019分割槽中，”張飛“會被寫入partition_2020分割槽中,可以通過下面的sql語句來驗證一下：

可以看出 partition_2018、partition_2019、partition_2020分割槽的確各有一條資料，而且對資料的更新和刪除操作都和普通表使用方式一樣，是不是很方便。

下面我們來看看分割槽表和普通表的效能對比吧

為了方便對比我們先建立一張和上面分割槽表一樣的普通表，建立語句如下：

我們分別先往tb_normal_demo和tb_partition_demo表中增加200W條資料後(寫入資料的程式就不在這裡展示了)，再分別執行以下sql

#查詢普通表

mysql> select count(1) from tb_normal_demo where create_time between '2019-01-01' and '2019-12-31';

+----------+

| count(1) |

+----------+

| 744352 |

+----------+

1 row in set (2.12 sec)

#查詢分割槽表

mysql> select count(1) from tb_normal_demo where create_time between '2019-01-01' and '2019-12-31';

+----------+

| count(1) |

+----------+

| 744352 |

+----------+

1 row in set (0.22 sec)

可見根據分割槽欄位查詢表資料時，分割槽表的優勢一下就體現出來了。

當然以上用了Range分割槽型別，其實Mysql來有很多種分割槽型別如：

Range分割槽
List分割槽
Columns分割槽
Hash分割槽
Key分割槽
子分割槽
用法都差不多，這裡就不在過多描述。

使用分割槽表的優勢

分割槽表最大優勢就是對業務透明，相對於分割槽表來說，使用分割槽表的業務程式碼更簡潔，還有分割槽表可以很方便的清理歷史資料(只需要drop掉某個歷史分割槽就可以了，語法為：alter table t drop partition ....)使用分割槽表時要注意：

分割槽並不是越細越好，實際上，單表或者單分割槽的資料1000W行，只要沒有特別大的索引，對於現在的硬體能力來說都已經是小表了。
分割槽也不要提前預留太多，在使用之前預先建立即可，又如按月分割槽，每年年底再把下一年的12個分割槽建立上即可，對於沒有資料的歷史分割槽，要及時drop掉。
查詢資料儘量不要跨很多分割槽取資料，這樣可能導致查詢會很慢，所以使用分割槽前要提前做好充分的考慮。

使用分割槽表的劣勢

Mysql在第一次開啟分割槽表的時候，需要訪問所有的分割槽(開啟的檔案較多)
在Server層，Mysql認為這是同一張表，因此所有分割槽共同使用一個MDL鎖(鎖的粒度大)，影響併發。

————————————————
版權宣告：本文為CSDN博主「Stone Chan」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。
原文連結：https://blog.csdn.net/weixin_35782626/article/details/113088299