mysql高級

時間 2019-11-21

標籤 mysql 高級欄目 MySQL 简体版

原文原文鏈接

1、存儲引擎
- InnoDB
- MyISAM
- 比較
2、數據類型
- 整型
- 浮點數
- 字符串
- 時間和日期
3、索引
- 索引分類
- 索引的優勢
- 索引優化
- B-Tree 和 B+Tree 原理
4、查詢性能優化
5、切分
- 垂直切分
- 水平切分
- 切分的選擇
- 存在的問題
6、故障轉移和故障恢復
參考資料

1、存儲引擎

InnoDB

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

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

表是基於聚簇索引創建的，它對主鍵的查詢性能有很高的提高。算法

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

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

MyISAM

MyISAM 提供了大量的特性，包括全文索引、壓縮表、空間數據索引等。應該注意的是，MySQL 5.6.4 也添加了對 InnoDB 存儲引擎的全文索引支持。編程

不支持事務。緩存

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

能夠手工或者自動執行檢查和修復操做，可是和事務恢復以及崩潰恢復不一樣，可能致使一些數據丟失，並且修復操做是很是慢的。服務器

若是指定了 DELAYKEYWRITE 選項，在每次修改執行完成時，不會當即將修改的索引數據寫入磁盤，而是會寫到內存中的鍵緩衝區，只有在清理鍵緩衝區或者關閉表的時候纔會將對應的索引塊寫入磁盤。這種方式能夠極大的提高寫入性能，可是在數據庫或者主機崩潰時會形成索引損壞，須要執行修復操做。數據結構

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

比較

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

2、數據類型

整型

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 提供了 FROMUNIXTIME() 函數把 UNIX 時間戳轉換爲日期，並提供了 UNIXTIMESTAMP() 函數把日期轉換爲 UNIX 時間戳。

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

應該儘可能使用 TIMESTAMP，由於它比 DATETIME 空間效率更高。

3、索引

索引是在存儲引擎層實現的，而不是在服務器層實現的，因此不一樣存儲引擎具備不一樣的索引類型和實現。

索引可以輕易將查詢性能提高几個數量級。

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

索引分類

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。

索引的優勢

大大減小了服務器須要掃描的數據量；
幫助服務器避免進行排序和建立臨時表（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. 前綴索引

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

對於前綴長度的選取須要根據 索引選擇性 來肯定：不重複的索引值和記錄總數的比值。選擇性越高，查詢效率也越高。最大值爲 1，此時每一個記錄都有惟一的索引與其對應。

3. 多列索引

在須要使用多個列做爲條件進行查詢時，使用多列索引比使用多個單列索引性能更好。例以下面的語句中，最好把 actorid 和 filmid 設置爲多列索引。

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

4. 索引列的順序

讓選擇性最強的索引列放在前面，例以下面顯示的結果中 customerid 的選擇性比 staffid 更高，所以最好把 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

5. 聚簇索引

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

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

由於沒法把數據行存放在兩個不一樣的地方，因此一個表只能有一個聚簇索引。

優勢

能夠把相關數據保存在一塊兒，減小 I/O 操做。例如電子郵件表能夠根據用戶 ID 來彙集數據，這樣只須要從磁盤讀取少數的數據也就能獲取某個用戶的所有郵件，若是沒有使用聚聚簇索引，則每封郵件均可能致使一次磁盤 I/O。
數據訪問更快。

缺點

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

6. 覆蓋索引

索引包含全部須要查詢的字段的值。

優勢

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

B-Tree 和 B+Tree 原理

1. B-Tree

爲了描述 B-Tree，首先定義一條數據記錄爲一個二元組 [key, data]。

B-Tree 是知足下列條件的數據結構：

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

在 B-Tree 中按 key 檢索數據的算法很是直觀：首先在根節點進行二分查找，若是找到則返回對應節點的 data，不然在相應區間的指針指向的節點遞歸進行查找。

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

2. B+Tree

與 B-Tree 相比，B+Tree 有如下不一樣點：

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

3. 帶有順序訪問指針的 B+Tree

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

4. 爲何使用 B-Tree 和 B+Tree

紅黑樹等數據結構也能夠用來實現索引，可是文件系統及數據庫系統廣泛採用 B-/+Tree 做爲索引結構。

頁是計算機管理存儲器的邏輯塊，硬件及操做系統每每將主存和磁盤存儲區分割爲連續的大小相等的塊，每一個存儲塊稱爲一頁（在許多操做系統中，頁的大小一般爲 4k），主存和磁盤以頁爲單位交換數據。

通常來講，索引自己也很大，不可能所有存儲在內存中，所以索引每每以索引文件的形式存儲的磁盤上。爲了減小磁盤 I/O，磁盤每每不是嚴格按需讀取，而是每次都會預讀。這樣作的理論依據是計算機科學中著名的局部性原理：當一個數據被用到時，其附近的數據也一般會立刻被使用。數據庫系統的設計者巧妙利用了磁盤預讀原理，將一個節點的大小設爲等於一個頁，這樣每一個節點只須要一次 I/O 就能夠徹底載入。

B-Tree 中一次檢索最多須要 h-1 次 I/O（根節點常駐內存），漸進複雜度爲 O(h)=O(logdN)。通常實際應用中，出度 d 是很是大的數字，一般超過 100，所以 h 很是小（一般不超過 3）。而紅黑樹這種結構，h 明顯要深的多。而且於邏輯上很近的節點（父子）物理上可能很遠，沒法利用局部性，效率明顯比 B-Tree 差不少。

B+Tree 更適合外存索引，緣由和內節點出度 d 有關。因爲 B+Tree 內節點去掉了 data 域，所以能夠擁有更大的出度，擁有更好的性能。

4、查詢性能優化

Explain

用來分析 SQL 語句，分析結果中比較重要的字段有：

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

減小返回的列

慢查詢主要是由於訪問了過多數據，除了訪問過多行以外，也包括訪問過多列。

最好不要使用 SELECT * 語句，要根據須要選擇查詢的列。

減小返回的行

最好使用 LIMIT 語句來取出想要的那些行。

還能夠創建索引來減小條件語句的全表掃描。例如對於下面的語句，不使用索引的狀況下須要進行全表掃描，而使用索引只須要掃描幾行記錄便可，使用 Explain 語句能夠經過觀察 rows 字段來看出這種差別。

SELECT * FROM sakila.film_actor WHERE film_id = 1;

拆分大的 DELETE 或 INSERT 語句

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

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