一、存儲引擎

InnoDB

InnoDB 是 MySQL 默認的事務型存儲引擎，只有在需要 InnoDB 不支持的特性時，才考慮使用其它存儲引擎。

採用 MVCC 來支持高併發，並且實現了四個標準的隔離級別，默認級別是可重複讀（REPEATABLE READ），並且通過間隙鎖（next-key locking）策略防止幻讀的出現。間隙鎖使得 InnoDB 不僅僅鎖定查詢涉及的行，還會對索引中的間隙進行鎖定，以防止幻影行的插入。

表是基於聚簇索引建立的，它對主鍵的查詢性能有很大的提升。

內部做了很多優化，包括從磁盤讀取數據時採用的可預測性讀、能夠自動在內存中創建哈希索引以加速讀操作的自適應哈希索引、能夠加速插入操作的插入緩衝區等。

通過一些機制和工具支持真正的熱備份。其它存儲引擎不支持熱備份，要獲取一致性視圖需要停止對所有表的寫入，而在讀寫混合場景中，停止寫入可能也意味着停止讀取。

MyISAM

MyISAM 提供了大量的特性，包括壓縮表、空間數據索引等。

不支持事務。

不支持行級鎖，只能對整張表加鎖，讀取時會對需要讀到的所有表加共享鎖，寫入時則對錶加排它鎖。但在表有讀取查詢的同時，也可以往表中插入新的記錄，這被稱爲併發插入（CONCURRENT INSERT）。

可以手工或者自動執行檢查和修復操作，但是和事務恢復以及崩潰恢復不同，可能導致一些數據丟失，而且修復操作是非常慢的。

如果指定了 DELAY_KEY_WRITE 選項，在每次修改執行完成時，不會立即將修改的索引數據寫入磁盤，而是會寫到內存中的鍵緩衝區，只有在清理鍵緩衝區或者關閉表的時候纔會將對應的索引塊寫入磁盤。這種方式可以極大的提升寫入性能，但是在數據庫或者主機崩潰時會造成索引損壞，需要執行修復操作。

MyISAM 設計簡單，數據以緊密格式存儲。對於只讀數據，或者表比較小、可以容忍修復操作，則依然可以繼續使用 MyISAM。

比較

事務：InnoDB 是事務型的。
備份：InnoDB 支持在線熱備份。
崩潰恢復：MyISAM 崩潰後發生損壞的概率比 InnoDB 高很多，而且恢復的速度也更慢。
併發：MyISAM 只支持表級鎖，而 InnoDB 還支持行級鎖。
其它特性：MyISAM 支持壓縮表和空間數據索引。

二、數據類型

整型

TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT 分別使用 8, 16, 24, 32, 64 位存儲空間，一般情況下越小的列越好。

INT(11) 中的數字只是規定了交互工具顯示字符的個數，對於存儲和計算來說是沒有意義的。

浮點數

FLOAT 和 DOUBLE 爲浮點類型，DECIMAL 爲高精度小數類型。CPU 原生支持浮點運算，但是不支持 DECIMAl 類型的計算，因此 DECIMAL 的計算比浮點類型需要更高的代價。

FLOAT、DOUBLE 和 DECIMAL 都可以指定列寬，例如 DECIMAL(18, 9) 表示總共 18 位，取 9 位存儲小數部分，剩下 9 位存儲整數部分。

字符串

主要有 CHAR 和 VARCHAR 兩種類型，一種是定長的，一種是變長的。

VARCHAR 這種變長類型能夠節省空間，因爲只需要存儲必要的內容。但是在執行 UPDATE 時可能會使行變得比原來長，當超出一個頁所能容納的大小時，就要執行額外的操作。MyISAM 會將行拆成不同的片段存儲，而 InnoDB 則需要分裂頁來使行放進頁內。

VARCHAR 會保留字符串末尾的空格，而 CHAR 會刪除。

時間和日期

MySQL 提供了兩種相似的日期時間類型：DATATIME 和 TIMESTAMP。

1. DATATIME

能夠保存從 1001 年到 9999 年的日期和時間，精度爲秒，使用 8 字節的存儲空間。

它與時區無關。

默認情況下，MySQL 以一種可排序的、無歧義的格式顯示 DATATIME 值，例如“2008-01-16 22:37:08”，這是 ANSI 標準定義的日期和時間表示方法。

2. TIMESTAMP

和 UNIX 時間戳相同，保存從 1970 年 1 月 1 日午夜（格林威治時間）以來的秒數，使用 4 個字節，只能表示從 1970 年到 2038 年。

它和時區有關，也就是說一個時間戳在不同的時區所代表的具體時間是不同的。

MySQL 提供了 FROM_UNIXTIME() 函數把 UNIX 時間戳轉換爲日期，並提供了 UNIX_TIMESTAMP() 函數把日期轉換爲 UNIX 時間戳。

默認情況下，如果插入時沒有指定 TIMESTAMP 列的值，會將這個值設置爲當前時間。

應該儘量使用 TIMESTAMP，因爲它比 DATETIME 空間效率更高。

三、索引

索引是在存儲引擎層實現的，而不是在服務器層實現的，所以不同存儲引擎具有不同的索引類型和實現。

索引能夠輕易將查詢性能提升幾個數量級。

對於非常小的表、大部分情況下簡單的全表掃描比建立索引更高效。對於中到大型的表，索引就非常有效。但是對於特大型的表，建立和使用索引的代價將會隨之增長。這種情況下，需要用到一種技術可以直接區分出需要查詢的一組數據，而不是一條記錄一條記錄地匹配，例如可以使用分區技術。

B-Tree 和 B+Tree 原理

1. B-Tree

定義一條數據記錄爲一個二元組 [key, data]，B-Tree 是滿足下列條件的數據結構：

所有葉節點具有相同的深度，也就是說 B-Tree 是平衡的；
一個節點中的 key 從左到右非遞減排列；
如果某個指針的左右相鄰 key 分別是 key_i 和 key_i+1，且不爲 null，則該指針指向節點的所有 key 大於等於 key_i 且小於等於 key_i+1。

查找算法：首先在根節點進行二分查找，如果找到則返回對應節點的 data，否則在相應區間的指針指向的節點遞歸進行查找。

由於插入刪除新的數據記錄會破壞 B-Tree 的性質，因此在插入刪除時，需要對樹進行一個分裂、合併、轉移等操作以保持 B-Tree 性質。

2. B+Tree

與 B-Tree 相比，B+Tree 有以下不同點：

每個節點的指針上限爲 2d 而不是 2d+1（d 爲節點的出度）；
內節點不存儲 data，只存儲 key；
葉子節點不存儲指針。

3. 順序訪問指針

一般在數據庫系統或文件系統中使用的 B+Tree 結構都在經典 B+Tree 基礎上進行了優化，在葉子節點增加了順序訪問指針，做這個優化的目的是爲了提高區間訪問的性能。

4. B+Tree 和 B-Tree 優勢

紅黑樹等平衡樹也可以用來實現索引，但是文件系統及數據庫系統普遍採用 B+Tree 和 B-Tree 作爲索引結構，主要有以下兩個原因：

（一）更少的檢索次數

平衡樹檢索數據的時間複雜度等於樹高 h，而樹高大致爲 O(h)=O(log_dN)，其中 d 爲每個節點的出度。

紅黑樹的出度爲 2，而 B+Tree 與 B-Tree 的出度一般都非常大。紅黑樹的樹高 h 很明顯比 B+Tree 和 B-Tree 大非常多，因此檢索的次數也就更多。

B+Tree 相比於 B-Tree 更適合外存索引，因爲 B+Tree 內節點去掉了 data 域，因此可以擁有更大的出度，檢索效率會更高。

（二）利用計算機預讀特性

爲了減少磁盤 I/O，磁盤往往不是嚴格按需讀取，而是每次都會預讀。這樣做的理論依據是計算機科學中著名的局部性原理：當一個數據被用到時，其附近的數據也通常會馬上被使用。預讀過程中，磁盤進行順序讀取，順序讀取不需要進行磁盤尋道，並且只需要很短的旋轉時間，因此速度會非常快。

操作系統一般將內存和磁盤分割成固態大小的塊，每一塊稱爲一頁，內存與磁盤以頁爲單位交換數據。數據庫系統將索引的一個節點的大小設置爲頁的大小，使得一次 I/O 就能完全載入一個節點，並且可以利用預讀特性，臨近的節點也能夠被預先載入。

更多內容請參考：MySQL 索引背後的數據結構及算法原理

索引分類

1. B+Tree 索引

《高性能 MySQL》一書使用 B-Tree 進行描述，其實從技術上來說這種索引是 B+Tree，因爲只有葉子節點存儲數據值。

B+Tree 索引是大多數 MySQL 存儲引擎的默認索引類型。

因爲不再需要進行全表掃描，只需要對樹進行搜索即可，因此查找速度快很多。除了用於查找，還可以用於排序和分組。

可以指定多個列作爲索引列，多個索引列共同組成鍵。B+Tree 索引適用於全鍵值、鍵值範圍和鍵前綴查找，其中鍵前綴查找只適用於最左前綴查找。如果不是按照索引列的順序進行查找，則無法使用索引。

2. 哈希索引

基於哈希表實現，優點是查找非常快。

在 MySQL 中只有 Memory 引擎顯式支持哈希索引。

InnoDB 引擎有一個特殊的功能叫“自適應哈希索引”，當某個索引值被使用的非常頻繁時，會在 B+Tree 索引之上再創建一個哈希索引，這樣就讓 B+Tree 索引具有哈希索引的一些優點，比如快速的哈希查找。

限制：

哈希索引只包含哈希值和行指針，而不存儲字段值，所以不能使用索引中的值來避免讀取行。不過，訪問內存中的行的速度很快，所以大部分情況下這一點對性能影響並不明顯；
無法用於排序與分組；
只支持精確查找，無法用於部分查找和範圍查找；
如果哈希衝突很多，查找速度會變得很慢。

3. 空間數據索引（R-Tree）

MyISAM 存儲引擎支持空間數據索引，可以用於地理數據存儲。

空間數據索引會從所有維度來索引數據，可以有效地使用任意維度來進行組合查詢。

必須使用 GIS 相關的函數來維護數據。

4. 全文索引

MyISAM 存儲引擎支持全文索引，用於查找文本中的關鍵詞，而不是直接比值是否相等。查找條件使用 MATCH AGAINST，而不是普通的 WHERE。

InnoDB 存儲引擎在 MySQL 5.6.4 版本中也開始支持全文索引。

索引的優點

大大減少了服務器需要掃描的數據量；
幫助服務器避免進行排序和創建臨時表（B+Tree 索引是有序的，可以用來做 ORDER BY 和 GROUP BY 操作）；
將隨機 I/O 變爲順序 I/O（B+Tree 索引是有序的，也就將相鄰的數據都存儲在一起）。

索引優化

1. 獨立的列

在進行查詢時，索引列不能是表達式的一部分，也不能是函數的參數，否則無法使用索引。

例如下面的查詢不能使用 actor_id 列的索引：

SELECT actor_id FROM sakila.actor WHERE actor_id + 1 = 5;

2. 多列索引

在需要使用多個列作爲條件進行查詢時，使用多列索引比使用多個單列索引性能更好。例如下面的語句中，最好把 actor_id 和 film_id 設置爲多列索引。

SELECT film_id, actor_ id FROM sakila.film_actor
WhERE actor_id = 1 AND film_id = 1;

3. 索引列的順序

讓選擇性最強的索引列放在前面，索引的選擇性是指：不重複的索引值和記錄總數的比值。最大值爲 1，此時每個記錄都有唯一的索引與其對應。選擇性越高，查詢效率也越高。

例如下面顯示的結果中 customer_id 的選擇性比 staff_id 更高，因此最好把 customer_id 列放在多列索引的前面。

SELECT COUNT(DISTINCT staff_id)/COUNT(*) AS staff_id_selectivity,
COUNT(DISTINCT customer_id)/COUNT(*) AS customer_id_selectivity,
COUNT(*)
FROM payment;

   staff_id_selectivity: 0.0001
customer_id_selectivity: 0.0373
               COUNT(*): 16049

4. 前綴索引

對於 BLOB、TEXT 和 VARCHAR 類型的列，必須使用前綴索引，只索引開始的部分字符。

對於前綴長度的選取需要根據索引選擇性來確定。

5. 覆蓋索引

索引包含所有需要查詢的字段的值。

優點

因爲索引條目通常遠小於數據行的大小，所以若只讀取索引，能大大減少數據訪問量。
一些存儲引擎（例如 MyISAM）在內存中只緩存索引，而數據依賴於操作系統來緩存。因此，只訪問索引可以不使用系統調用（通常比較費時）。
對於 InnoDB 引擎，若二級索引能夠覆蓋查詢，則無需訪問聚簇索引。

6. 聚簇索引

聚簇索引並不是一種索引類型，而是一種數據存儲方式。

術語“聚簇”表示數據行和相鄰的鍵值緊密地存儲在一起，InnoDB 的聚簇索引在同一個結構中保存了 B+Tree 索引和數據行。

因爲無法把數據行存放在兩個不同的地方，所以一個表只能有一個聚簇索引。

優點

可以把相關數據保存在一起，減少 I/O 操作。例如電子郵件表可以根據用戶 ID 來聚集數據，這樣只需要從磁盤讀取少數的數據也就能獲取某個用戶的全部郵件，如果沒有使用聚聚簇索引，則每封郵件都可能導致一次磁盤 I/O。
數據訪問更快。

缺點

聚簇索引最大限度提高了 I/O 密集型應用的性能，但是如果數據全部放在內存，就沒必要用聚簇索引。
插入速度嚴重依賴於插入順序，按主鍵的順序插入是最快的。
更新操作代價很高，因爲每個被更新的行都會移動到新的位置。
當插入到某個已滿的頁中，存儲引擎會將該頁分裂成兩個頁面來容納該行，頁分裂會導致表佔用更多的磁盤空間。
如果行比較稀疏，或者由於頁分裂導致數據存儲不連續時，聚簇索引可能導致全表掃描速度變慢。

四、查詢性能優化

使用 Explain 進行分析

Explain 用來分析 SELECT 查詢語句，開發人員可以通過分析結果來優化查詢語句。

比較重要的字段有：

select_type : 查詢類型，有簡單查詢、聯合查詢、子查詢等
key : 使用的索引
rows : 掃描的行數

更多內容請參考：MySQL 性能優化神器 Explain 使用分析

優化數據訪問

1. 減少請求的數據量

（一）只返回必要的列

最好不要使用 SELECT * 語句。

（二）只返回必要的行

使用 WHERE 語句進行查詢過濾，有時候也需要使用 LIMIT 語句來限制返回的數據。

（三）緩存重複查詢的數據

使用緩存可以避免在數據庫中進行查詢，特別要查詢的數據經常被重複查詢，緩存可以帶來的查詢性能提升將會是非常明顯的。

2. 減少服務器端掃描的行數

最有效的方式是使用索引來覆蓋查詢。

重構查詢方式

1. 切分大查詢

一個大查詢如果一次性執行的話，可能一次鎖住很多數據、佔滿整個事務日誌、耗盡系統資源、阻塞很多小的但重要的查詢。

DELEFT FROM messages WHERE create < DATE_SUB(NOW(), INTERVAL 3 MONTH);

rows_affected = 0
do {
    rows_affected = do_query(
    "DELETE FROM messages WHERE create  < DATE_SUB(NOW(), INTERVAL 3 MONTH) LIMIT 10000")
} while rows_affected > 0

2. 分解大連接查詢

將一個大連接查詢（JOIN）分解成對每一個表進行一次單表查詢，然後將結果在應用程序中進行關聯，這樣做的好處有：

讓緩存更高效。對於連接查詢，如果其中一個表發生變化，那麼整個查詢緩存就無法使用。而分解後的多個查詢，即使其中一個表發生變化，對其它表的查詢緩存依然可以使用。
減少鎖競爭；
在應用層進行連接，可以更容易對數據庫進行拆分，從而更容易做到高性能和可擴展。
查詢本身效率也可能會有所提升。例如下面的例子中，使用 IN() 代替連接查詢，可以讓 MySQL 按照 ID 順序進行查詢，這可能比隨機的連接要更高效。
分解成多個單表查詢，這些單表查詢的緩存結果更可能被其它查詢使用到，從而減少冗餘記錄的查詢。

SELECT * FROM tab
JOIN tag_post ON tag_post.tag_id=tag.id
JOIN post ON tag_post.post_id=post.id
WHERE tag.tag='mysql';

SELECT * FROM tag WHERE tag='mysql';
SELECT * FROM tag_post WHERE tag_id=1234;
SELECT * FROM post WHERE post.id IN (123,456,567,9098,8904);

還有很多性能優化的方向，具體可以參考：

https://www.jfox.info/20-tiao-mysql-xing-nen-you-hua-de-zui-jia-jing-yan.html

五、切分

水平切分

水平切分就是就是常見的 Sharding，它是將同一個表中的記錄拆分到多個結構相同的表中。

當一個表的數據不斷增多時，Sharding 是必然的選擇，它可以將數據分佈到集羣的不同節點上，從而緩存單個數據庫的壓力。

垂直切分

垂直切分是將一張表按列切分成多個表，通常是按照列的關係密集程度進行切分。也可以利用垂直切分將經常被使用的列和不經常被使用的列切分到不同的表中。

也可以在數據庫的層面使用垂直切分，它按數據庫中表的密集程度部署到不同的庫中，例如將原來的電商數據庫垂直切分成商品數據庫 payDB、用戶數據庫 userBD 等。

Sharding 策略

哈希取模：hash(key) % NUM_DB
範圍：可以是 ID 範圍也可以是時間範圍
映射表：使用單獨的一個數據庫來存儲映射關係

Sharding 存在的問題

1. 事務問題

使用分佈式事務。

2. JOIN

將原來的 JOIN 查詢分解成多個單表查詢，然後在用戶程序中進行 JOIN。

3. ID 唯一性

使用全局唯一 ID：GUID。
爲每個分片指定一個 ID 範圍。
分佈式 ID 生成器 (如 Twitter 的 Snowflake 算法)。
隨着用戶數的不斷增加，以及數據量的不斷增加，通過分庫與分表的方式提高查詢性能的同時，帶來了一系列分佈式困境。
數據遷移與擴容問題
前面介紹到水平分表策略歸納總結爲隨機分表和連續分表兩種情況。連續分表有可能存在數據熱點的問題，有些表可能會被頻繁地查詢從而造成較大壓力，熱數據的表就成爲了整個庫的瓶頸，而有些表可能存的是歷史數據，很少需要被查詢到。連續分表的另外一個好處在於比較容易，不需要考慮遷移舊的數據，只需要添加分表就可以自動擴容。隨機分表的數據相對比較均勻，不容易出現熱點和併發訪問的瓶頸。但是，分表擴展需要遷移舊的數據。
針對於水平分表的設計至關重要，需要評估中短期內業務的增長速度，對當前的數據量進行容量規劃，綜合成本因素，推算出大概需要多少分片。對於數據遷移的問題，一般做法是通過程序先讀出數據，然後按照指定的分表策略再將數據寫入到各個分表中。
表關聯問題
在單庫單表的情況下，聯合查詢是非常容易的。但是，隨着分庫與分表的演變，聯合查詢就遇到跨庫關聯和跨表關係問題。在設計之初就應該儘量避免聯合查詢，可以通過程序中進行拼裝，或者通過反範式化設計進行規避。
分頁與排序問題
一般情況下，列表分頁時需要按照指定字段進行排序。在單庫單表的情況下，分頁和排序也是非常容易的。但是，隨着分庫與分表的演變，也會遇到跨庫排序和跨表排序問題。爲了最終結果的準確性，需要在不同的分表中將數據進行排序並返回，並將不同分表返回的結果集進行彙總和再次排序，最後再返回給用戶。
分佈式事務問題
隨着分庫與分表的演變，一定會遇到分佈式事務問題，那麼如何保證數據的一致性就成爲一個必須面對的問題。目前，分佈式事務並沒有很好的解決方案，難以滿足數據強一致性，一般情況下，使存儲數據儘可能達到用戶一致，保證系統經過一段較短的時間的自我恢復和修正，數據最終達到一致。
分佈式全局唯一ID
在單庫單表的情況下，直接使用數據庫自增特性來生成主鍵ID，這樣確實比較簡單。在分庫分表的環境中，數據分佈在不同的分表上，不能再借助數據庫自增長特性。需要使用全局唯一 ID，例如 UUID、GUID等。關於如何選擇合適的全局唯一 ID，我會在後面的章節中進行介紹。
總結
分庫與分表主要用於應對當前互聯網常見的兩個場景：海量數據和高併發。然而，分庫與分表是一把雙刃劍，雖然很好的應對海量數據和高併發對數據庫的衝擊和壓力，但是卻提高的系統的複雜度和維護成本。
因此，我的建議：需要結合實際需求，不宜過度設計，在項目一開始不採用分庫與分表設計，而是隨着業務的增長，在無法繼續優化的情況下，再考慮分庫與分表提高系統的性能。

更多內容請參考：

參考資料

BaronScbwartz, PeterZaitsev, VadimTkacbenko, 等. 高性能 MySQL[M]. 電子工業出版社, 2013.
20+ 條 MySQL 性能優化的最佳經驗
服務端指南數據存儲篇 | MySQL（09）分庫與分錶帶來的分佈式困境與應對之策
How to create unique row ID in sharded databases?
SQL Azure Federation – Introduction

技術基礎整理---索引 數據庫（2）