雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
一.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優化器隻需搜對應的區，不會搜尋所有分區。關注微信公衆号：網際網路架構師，在背景回複：2T，可以擷取網際網路架構師 教程，都T是幹貨。
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 |
+----+-------------+-------------------+------------+------+---------------+------+---------+------+-------+-------------+
row in set (0.00 sec) 【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/zhibo立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-04-28
本文作者： GrimMjx
本文來自：“
網際網路架構師 微信公衆号”，了解相關資訊可以關注“
網際網路架構師”