一、索引

B+ Tree 原理

1. 數(shù)據(jù)結構

B Tree 指的是 Balance Tree，也就是平衡樹。平衡樹是一顆查找樹，并且所有葉子節(jié)點位于同一層。

B+ Tree 是基于 B Tree 和葉子節(jié)點順序訪問指針進行實現(xiàn)，它具有 B Tree 的平衡性，并且通過順序訪問指針來提高區(qū)間查詢的性能。

在 B+ Tree 中，一個節(jié)點中的 key 從左到右非遞減排列，如果某個指針的左右相鄰 key 分別是 keyi?和 keyi+1，且不為 null，則該指針指向節(jié)點的所有 key 大于等于 keyi?且小于等于 keyi+1。

2. 操作

進行查找操作時，首先在根節(jié)點進行二分查找，找到一個 key 所在的指針，然后遞歸地在指針所指向的節(jié)點進行查找。直到查找到葉子節(jié)點，然后在葉子節(jié)點上進行二分查找，找出 key 所對應的 data。

插入刪除操作會破壞平衡樹的平衡性，因此在插入刪除操作之后，需要對樹進行一個分裂、合并、旋轉等操作來維護平衡性。

3. 與紅黑樹的比較

紅黑樹等平衡樹也可以用來實現(xiàn)索引，但是文件系統(tǒng)及數(shù)據(jù)庫系統(tǒng)普遍采用 B+ Tree 作為索引結構，主要有以下兩個原因：

(一)更少的查找次數(shù)

平衡樹查找操作的時間復雜度和樹高 h 相關，O(h)=O(logdN)，其中 d 為每個節(jié)點的出度。

紅黑樹的出度為 2，而 B+ Tree 的出度一般都非常大，所以紅黑樹的樹高 h 很明顯比 B+ Tree 大非常多，查找的次數(shù)也就更多。

(二)利用磁盤預讀特性

為了減少磁盤 I/O 操作，磁盤往往不是嚴格按需讀取，而是每次都會預讀。預讀過程中，磁盤進行順序讀取，順序讀取不需要進行磁盤尋道，并且只需要很短的旋轉時間，速度會非常快。

操作系統(tǒng)一般將內存和磁盤分割成固定大小的塊，每一塊稱為一頁，內存與磁盤以頁為單位交換數(shù)據(jù)。數(shù)據(jù)庫系統(tǒng)將索引的一個節(jié)點的大小設置為頁的大小，使得一次 I/O 就能完全載入一個節(jié)點。并且可以利用預讀特性，相鄰的節(jié)點也能夠被預先載入。

MySQL 索引

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

1. B+Tree 索引

是大多數(shù) MySQL 存儲引擎的默認索引類型。

因為不再需要進行全表掃描，只需要對樹進行搜索即可，所以查找速度快很多。

除了用于查找，還可以用于排序和分組。

可以指定多個列作為索引列，多個索引列共同組成鍵。

適用于全鍵值、鍵值范圍和鍵前綴查找，其中鍵前綴查找只適用于最左前綴查找。如果不是按照索引列的順序進行查找，則無法使用索引。

InnoDB 的 B+Tree 索引分為主索引和輔助索引。主索引的葉子節(jié)點 data 域記錄著完整的數(shù)據(jù)記錄，這種索引方式被稱為聚簇索引。因為無法把數(shù)據(jù)行存放在兩個不同的地方，所以一個表只能有一個聚簇索引。

輔助索引的葉子節(jié)點的 data 域記錄著主鍵的值，因此在使用輔助索引進行查找時，需要先查找到主鍵值，然后再到主索引中進行查找。

2. 哈希索引

哈希索引能以 O(1) 時間進行查找，但是失去了有序性：

無法用于排序與分組；

只支持精確查找，無法用于部分查找和范圍查找。

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

3. 全文索引

MyISAM 存儲引擎支持全文索引，用于查找文本中的關鍵詞，而不是直接比較是否相等。

查找條件使用 MATCH AGAINST，而不是普通的 WHERE。

全文索引使用倒排索引實現(xiàn)，它記錄著關鍵詞到其所在文檔的映射。

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

4. 空間數(shù)據(jù)索引

MyISAM 存儲引擎支持空間數(shù)據(jù)索引(R-Tree)，可以用于地理數(shù)據(jù)存儲。空間數(shù)據(jù)索引會從所有維度來索引數(shù)據(jù)，可以有效地使用任意維度來進行組合查詢。

必須使用 GIS 相關的函數(shù)來維護數(shù)據(jù)。

索引優(yōu)化

1. 獨立的列

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

例如下面的查詢不能使用 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. 索引列的順序

讓選擇性最強的索引列放在前面。

索引的選擇性是指：不重復的索引值和記錄總數(shù)的比值。最大值為 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 類型的列，必須使用前綴索引，只索引開始的部分字符。

對于前綴長度的選取需要根據(jù)索引選擇性來確定。

5. 覆蓋索引

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

具有以下優(yōu)點：

索引通常遠小于數(shù)據(jù)行的大小，只讀取索引能大大減少數(shù)據(jù)訪問量。

一些存儲引擎(例如 MyISAM)在內存中只緩存索引，而數(shù)據(jù)依賴于操作系統(tǒng)來緩存。因此，只訪問索引可以不使用系統(tǒng)調用(通常比較費時)。

對于 InnoDB 引擎，若輔助索引能夠覆蓋查詢，則無需訪問主索引。

索引的優(yōu)點

大大減少了服務器需要掃描的數(shù)據(jù)行數(shù)。

幫助服務器避免進行排序和分組，以及避免創(chuàng)建臨時表(B+Tree 索引是有序的，可以用于 ORDER BY 和 GROUP BY 操作。臨時表主要是在排序和分組過程中創(chuàng)建，因為不需要排序和分組，也就不需要創(chuàng)建臨時表)。

將隨機 I/O 變?yōu)轫樞?I/O(B+Tree 索引是有序的，會將相鄰的數(shù)據(jù)都存儲在一起)。

索引的使用條件

對于非常小的表、大部分情況下簡單的全表掃描比建立索引更高效；

對于中到大型的表，索引就非常有效；

但是對于特大型的表，建立和維護索引的代價將會隨之增長。這種情況下，需要用到一種技術可以直接區(qū)分出需要查詢的一組數(shù)據(jù)，而不是一條記錄一條記錄地匹配，例如可以使用分區(qū)技術。

二、查詢性能優(yōu)化

使用 Explain 進行分析

Explain 用來分析 SELECT 查詢語句，開發(fā)人員可以通過分析 Explain 結果來優(yōu)化查詢語句。

比較重要的字段有：

select_type : 查詢類型，有簡單查詢、聯(lián)合查詢、子查詢等

key : 使用的索引

rows : 掃描的行數(shù)

優(yōu)化數(shù)據(jù)訪問

1. 減少請求的數(shù)據(jù)量

只返回必要的列：最好不要使用 SELECT * 語句。

只返回必要的行：使用 LIMIT 語句來限制返回的數(shù)據(jù)。

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

2. 減少服務器端掃描的行數(shù)

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

重構查詢方式

1. 切分大查詢

一個大查詢如果一次性執(zhí)行的話，可能一次鎖住很多數(shù)據(jù)、占滿整個事務日志、耗盡系統(tǒng)資源、阻塞很多小的但重要的查詢。

DELETE 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. 分解大連接查詢

將一個大連接查詢分解成對每一個表進行一次單表查詢，然后在應用程序中進行關聯(lián)，這樣做的好處有：

讓緩存更高效。對于連接查詢，如果其中一個表發(fā)生變化，那么整個查詢緩存就無法使用。而分解后的多個查詢，即使其中一個表發(fā)生變化，對其它表的查詢緩存依然可以使用。

分解成多個單表查詢，這些單表查詢的緩存結果更可能被其它查詢使用到，從而減少冗余記錄的查詢。

減少鎖競爭；

在應用層進行連接，可以更容易對數(shù)據(jù)庫進行拆分，從而更容易做到高性能和可伸縮。

查詢本身效率也可能會有所提升。例如下面的例子中，使用 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);

三、存儲引擎

InnoDB

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

實現(xiàn)了四個標準的隔離級別，默認級別是可重復讀(REPEATABLE READ)。在可重復讀隔離級別下，通過多版本并發(fā)控制(MVCC)+ 間隙鎖(Next-Key Locking)防止幻影讀。

主索引是聚簇索引，在索引中保存了數(shù)據(jù)，從而避免直接讀取磁盤，因此對查詢性能有很大的提升。

內部做了很多優(yōu)化，包括從磁盤讀取數(shù)據(jù)時采用的可預測性讀、能夠加快讀操作并且自動創(chuàng)建的自適應哈希索引、能夠加速插入操作的插入緩沖區(qū)等。

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

MyISAM

設計簡單，數(shù)據(jù)以緊密格式存儲。對于只讀數(shù)據(jù)，或者表比較小、可以容忍修復操作，則依然可以使用它。

提供了大量的特性，包括壓縮表、空間數(shù)據(jù)索引等。

不支持事務。

不支持行級鎖，只能對整張表加鎖，讀取時會對需要讀到的所有表加共享鎖，寫入時則對表加排它鎖。但在表有讀取操作的同時，也可以往表中插入新的記錄，這被稱為并發(fā)插入(CONCURRENT INSERT)。

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

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

比較

事務：InnoDB 是事務型的，可以使用 Commit 和 Rollback 語句。

并發(fā)：MyISAM 只支持表級鎖，而 InnoDB 還支持行級鎖。

外鍵：InnoDB 支持外鍵。

備份：InnoDB 支持在線熱備份。

崩潰恢復：MyISAM 崩潰后發(fā)生損壞的概率比 InnoDB 高很多，而且恢復的速度也更慢。

其它特性：MyISAM 支持壓縮表和空間數(shù)據(jù)索引。

四、數(shù)據(jù)類型

整型

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

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

浮點數(shù)

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

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

字符串

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

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

在進行存儲和檢索時，會保留 VARCHAR 末尾的空格，而會刪除 CHAR 末尾的空格。

時間和日期

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

1. DATETIME

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

它與時區(qū)無關。

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

2. TIMESTAMP

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

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

MySQL 提供了 FROM_UNIXTIME() 函數(shù)把 UNIX 時間戳轉換為日期，并提供了 UNIX_TIMESTAMP() 函數(shù)把日期轉換為 UNIX 時間戳。

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

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

五、切分

水平切分

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

當一個表的數(shù)據(jù)不斷增多時，Sharding 是必然的選擇，它可以將數(shù)據(jù)分布到集群的不同節(jié)點上，從而緩存單個數(shù)據(jù)庫的壓力。

垂直切分

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

在數(shù)據(jù)庫的層面使用垂直切分將按數(shù)據(jù)庫中表的密集程度部署到不同的庫中，例如將原來的電商數(shù)據(jù)庫垂直切分成商品數(shù)據(jù)庫、用戶數(shù)據(jù)庫等。

Sharding 策略

哈希取模：hash(key) % N；

范圍：可以是 ID 范圍也可以是時間范圍；

映射表：使用單獨的一個數(shù)據(jù)庫來存儲映射關系。

Sharding 存在的問題

1. 事務問題

使用分布式事務來解決，比如 XA 接口。

2. 連接

可以將原來的連接分解成多個單表查詢，然后在用戶程序中進行連接。

3. ID 唯一性

使用全局唯一 ID(GUID)

為每個分片指定一個 ID 范圍

分布式 ID 生成器 (如 Twitter 的 Snowflake 算法)

六、復制

主從復制

主要涉及三個線程：binlog 線程、I/O 線程和 SQL 線程。

binlog 線程?：負責將主服務器上的數(shù)據(jù)更改寫入二進制日志(Binary log)中。

I/O 線程?：負責從主服務器上讀取二進制日志，并寫入從服務器的重放日志(Replay log)中。

SQL 線程?：負責讀取重放日志并重放其中的 SQL 語句。

讀寫分離

主服務器處理寫操作以及實時性要求比較高的讀操作，而從服務器處理讀操作。

讀寫分離能提高性能的原因在于：

主從服務器負責各自的讀和寫，極大程度緩解了鎖的爭用；

從服務器可以使用 MyISAM，提升查詢性能以及節(jié)約系統(tǒng)開銷；

增加冗余，提高可用性。

讀寫分離常用代理方式來實現(xiàn)，代理服務器接收應用層傳來的讀寫請求，然后決定轉發(fā)到哪個服務器。

參考資料

總結

以上是生活随笔為你收集整理的MySQL实战面试题_Mysql实战面试题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。