共計 3620 個字符，預計需要花費 10 分鐘才能閱讀完成。
本篇文章為大家展示了 MySQL 中怎么實現分區，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。
一.InnoDB 邏輯存儲結構
首先要先介紹一下 InnoDB 邏輯存儲結構和區的概念，它的所有數據都被邏輯地存放在表空間，表空間又由段，區，頁組成。
段
段就是上圖的 segment 區域，常見的段有數據段、索引段、回滾段等，在 InnoDB 存儲引擎中，對段的管理都是由引擎自身所完成的。
區
區就是上圖的 extent 區域，區是由連續的頁組成的空間，無論頁的大小怎么變，區的大小默認總是為 1MB。
為了保證區中的頁的連續性，InnoDB 存儲引擎一次從磁盤申請 4 - 5 個區，InnoDB 頁的大小默認為 16kb，即一個區一共有 64（1MB/16kb=16）個連續的頁。
每個段開始，先用 32 頁（page）大小的碎片頁來存放數據，在使用完這些頁之后才是 64 個連續頁的申請。這樣做的目的是，對于一些小表或者是 undo 類的段，可以開始申請較小的空間，節約磁盤開銷。
頁
頁就是上圖的 page 區域，也可以叫塊。頁是 InnoDB 磁盤管理的最小單位。默認大小為 16KB，可以通過參數 innodb_page_size 來設置。
常見的頁類型有：數據頁，undo 頁，系統頁，事務數據頁，插入緩沖位圖頁，插入緩沖空閑列表頁，未壓縮的二進制大對象頁，壓縮的二進制大對象頁等。
二. 分區概述
分區
這里講的分區，此“區”非彼“區”，這里講的分區的意思是指將同一表中不同行的記錄分配到不同的物理文件中，幾個分區就有幾個.idb 文件，不是我們剛剛說的區。MySQL 在 5.1 時添加了對水平分區的支持。
分區是將一個表或索引分解成多個更小，更可管理的部分。
每個區都是獨立的，可以獨立處理，也可以作為一個更大對象的一部分進行處理。這個是 MySQL 支持的功能，業務代碼無需改動。要知道 MySQL 是面向 OLTP 的數據，它不像 TIDB 等其他 DB。
那么對于分區的使用應該非常小心，如果不清楚如何使用分區可能會對性能產生負面的影響。
MySQL 數據庫的分區是局部分區索引，一個分區中既存了數據，又放了索引。也就是說，每個區的聚集索引和非聚集索引都放在各自區的（不同的物理文件）。目前 MySQL 數據庫還不支持全局分區。
無論哪種類型的分區，如果表中存在主鍵或唯一索引時，分區列必須是唯一索引的一個組成部分。
三. 分區類型
目前 MySQL 支持一下幾種類型的分區，RANGE 分區，LIST 分區，HASH 分區，KEY 分區。
如果表存在主鍵或者唯一索引時，分區列必須是唯一索引的一個組成部分。實戰十有八九都是用 RANGE 分區。
RANGE 分區
RANGE 分區是實戰最常用的一種分區類型，行數據基于屬于一個給定的連續區間的列值被放入分區。
但是記住，當插入的數據不在一個分區中定義的值的時候，會拋異常。RANGE 分區主要用于日期列的分區，比如交易表啊，銷售表啊等。可以根據年月來存放數據。
如果你分區走的唯一索引中 date 類型的數據，那么注意了，優化器只能對 YEAR()，TO_DAYS()，TO_SECONDS()，UNIX_TIMESTAMP() 這類函數進行優化選擇。實戰中可以用 int 類型，那么只用存 yyyyMM 就好了。也不用關心函數了。
CREATE TABLE `m_test_db`.`Order` ( `id` INT NOT NULL AUTO_INCREMENT, `partition_key` INT NOT NULL, `amt` DECIMAL(5) NULL, PRIMARY KEY (`id`, `partition_key`)) PARTITION BY RANGE(partition_key) PARTITIONS 5( PARTITION part0 VALUES LESS THAN (201901), PARTITION part1 VALUES LESS THAN (201902), PARTITION part2 VALUES LESS THAN (201903), PARTITION part3 VALUES LESS THAN (201904), PARTITION part4 VALUES LESS THAN (201905)) ;這時候我們先插入一些數據
INSERT INTO `m_test_db`.`Order` (`id`, `partition_key`, `amt`) VALUES (1 , 201901 , 1000 INSERT INTO `m_test_db`.`Order` (`id`, `partition_key`, `amt`) VALUES (2 , 201902 , 800 INSERT INTO `m_test_db`.`Order` (`id`, `partition_key`, `amt`) VALUES (3 , 201903 , 1200現在我們查詢一下，通過 EXPLAIN PARTITION 命令發現 SQL 優化器只需搜對應的區，不會搜索所有分區
如果 sql 語句有問題，那么會走所有區。會很危險。所以分區表后，select 語句必須走分區鍵。
以下 3 種不是太常用，就一筆帶過了。
LIST 分區
LIST 分區和 RANGE 分區很相似，只是分區列的值是離散的，不是連續的。LIST 分區使用 VALUES IN，因為每個分區的值是離散的，因此只能定義值。
HASH 分區
說到哈希，那么目的很明顯了，將數據均勻的分布到預先定義的各個分區中，保證每個分區的數量大致相同。
KEY 分區
KEY 分區和 HASH 分區相似，不同之處在于 HASH 分區使用用戶定義的函數進行分區，KEY 分區使用數據庫提供的函數進行分區。
四. 分區和性能
一項技術，不是用了就一定帶來益處。比如顯式鎖功能比內置鎖強大，你沒玩好可能導致很不好的情況。
分區也是一樣，不是啟動了分區數據庫就會運行的更快，分區可能會給某些 sql 語句性能提高，但是分區主要用于數據庫高可用性的管理。
數據庫應用分為 2 類，一類是 OLTP（在線事務處理），一類是 OLAP（在線分析處理）。
對于 OLAP 應用分區的確可以很好的提高查詢性能，因為一般分析都需要返回大量的數據，如果按時間分區，比如一個月用戶行為等數據，則只需掃描響應的分區即可。
在 OLTP 應用中，分區更加要小心，通常不會獲取一張大表的 10% 的數據，大部分是通過索引返回幾條數據即可。
比如一張表 1000w 數據量，如果一句 select 語句走輔助索引，但是沒有走分區鍵。那么結果會很尷尬。
如果 1000w 的 B + 樹的高度是 3，現在有 10 個分區。那么不是要 (3+3)*10 次的邏輯 IO？（3 次聚集索引，3 次輔助索引，10 個分區）。所以在 OLTP 應用中請小心使用分區表。
在日常開發中，如果想查看 sql 語句的分區查詢結果可以使用 explain partitions + select sql 來獲取，partitions 標識走了哪幾個分區。
mysql explain partitions select * from TxnList where startTime 2016-08-25 00:00:00 and startTime 2016-08-25 23:59:00 +----+-------------+-------------------+------------+------+---------------+------+---------+------+-------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------------------+------------+------+---------------+------+---------+------+-------+-------------+ | 1 | SIMPLE | ClientActionTrack | p20160825 | ALL | NULL | NULL | NULL | NULL | 33868 | Using where | +----+-------------+-------------------+------------+------+---------------+------+---------+------+-------+-------------+ 1 row in set (0.00 sec)上述內容就是 MySQL 中怎么實現分區，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注丸趣 TV 行業資訊頻道。
