mysql學習 實踐(1) 普通索引和唯一索引的選擇
問題
1、在不同的業務場景下，應該選擇普通索引，還是唯一索引？
假設你在維護一個市民系統，每個人都有一個唯一的身份證號，而且業務程式碼已經保證了不會寫入兩個重複的身份證號。如果市民系統需要按照身份證號查姓名，就會執行類似這樣的 SQL 語句：
select name from CUser where id_card = 'xxxxxxxyyyyyyzzzzz';
所以，你一定會考慮在 id_card 欄位上建索引。由於身份證號欄位比較大，我不建議你把身份證號當做主鍵。
那麼現在你有兩個選擇，要麼給 id_card 欄位建立唯一索引，要麼建立一個普通索引。如果業務程式碼已經保證了不會寫入重複的身份證號
現在我要問你的是，從效能的角度考慮，你選擇唯一索引還是普通索引呢？選擇的依據是什麼呢？
簡單起見，舉個例子來說明，假設欄位 k 上的值都不重複。
假設，我們有一個主鍵列為 ID 的表，表中有欄位 k，並且在 k 上有索引。
這個表的建表語句是：
1 mysql> create table T(id int primary key, k int not null, name varchar(16),index (k))engine=InnoDB;
表中 R1~R5 的 (ID,k) 值分別為 (100,1)、(200,2)、(300,3)、(500,5) 和 (600,6)，兩棵樹的示例示意圖如下。
查詢過程
假設，執行查詢的語句是 select id from T where k=5。這個查詢語句在索引樹上查詢的過程，先是通過 B+ 樹從樹根開始，按層搜尋到葉子節點，也就是圖中右下角的這個資料頁，然後可以認為資料頁內部通過二分法來定位記錄。
- 對於普通索引來說，查詢到滿足條件的第一個記錄 (5,500) 後，需要查詢下一個記錄，直到碰到第一個不滿足 k=5 條件的記錄。
- 對於唯一索引來說，由於索引定義了唯一性，查詢到第一個滿足條件的記錄後，就會停止繼續檢索。
那麼，這個不同帶來的效能差距會有多少呢？答案是，微乎其微。
你知道的，InnoDB 的資料是按資料頁為單位來讀寫的。也就是說，當需要讀一條記錄的時候，並不是將這個記錄本身從磁碟讀出來，而是以頁為單位，將其整體讀入記憶體。在 InnoDB 中，每個資料頁的大小預設是 16KB。
因為引擎是按頁讀寫的，所以說，當找到 k=5 的記錄的時候，它所在的資料頁就都在記憶體裡了。那麼，對於普通索引來說，要多做的那一次“查詢和判斷下一條記錄”的操作，就只需要一次指標尋找和一次計算。
當然，如果 k=5 這個記錄剛好是這個資料頁的最後一個記錄，那麼要取下一個記錄，必須讀取下一個資料頁，這個操作會稍微複雜一些。
但是，我們之前計算過，對於整型欄位，一個數據頁可以放近千個 key，因此出現這種情況的概率會很低。
所以，我們計算平均效能差異時，仍可以認為這個操作成本對於現在的 CPU 來說可以忽略不計。
更新過程
為了說明普通索引和唯一索引對更新語句效能的影響這個問題，首先要了解一下 change buffer。
當需要更新一個數據頁時，如果資料頁在記憶體中就直接更新，而如果這個資料頁還沒有在記憶體中的話，在不影響資料一致性的前提下，InnoDB 會將這些更新操作快取在 change buffer 中，這樣就不需要從磁碟中讀入這個資料頁了。在下次查詢需要訪問這個資料頁的時候，將資料頁讀入記憶體，然後執行 change buffer 中與這個頁有關的操作。通過這種方式就能保證這個資料邏輯的正確性。
需要說明的是，雖然名字叫作 change buffer，實際上它是可以持久化的資料。也就是說，change buffer 在記憶體中有拷貝，也會被寫入到磁碟上。
將 change buffer 中的操作應用到原資料頁，得到最新結果的過程稱為 merge。除了訪問這個資料頁會觸發 merge 外，系統有後臺執行緒會定期 merge。在資料庫正常關閉（shutdown）的過程中，也會執行 merge 操作。
顯然，如果能夠將更新操作先記錄在 change buffer，減少讀磁碟，語句的執行速度會得到明顯的提升。而且，資料讀入記憶體是需要佔用 buffer pool 的，所以這種方式還能夠避免佔用記憶體，提高記憶體利用率。
那麼，什麼條件下可以使用 change buffer 呢？
對於唯一索引來說，所有的更新操作都要先判斷這個操作是否違反唯一性約束。比如，要插入 (4,400) 這個記錄，就要先判斷現在表中是否已經存在 k=4 的記錄，而這必須要將資料頁讀入記憶體才能判斷。如果都已經讀入到記憶體了，那直接更新記憶體會更快，就沒必要使用 change buffer 了。
因此，唯一索引的更新就不能使用 change buffer，實際上也只有普通索引可以使用。
change buffer 用的是 buffer pool 裡的記憶體，因此不能無限增大。change buffer 的大小，可以通過引數 innodb_change_buffer_max_size 來動態設定。這個引數設定為 50 的時候，表示 change buffer 的大小最多隻能佔用 buffer pool 的 50%。
現在，你已經理解了 change buffer 的機制，那麼我們再一起來看看如果要在這張表中插入一個新記錄 (4,400) 的話，InnoDB 的處理流程是怎樣的。
第一種情況是，這個記錄要更新的目標頁在記憶體中。這時，InnoDB 的處理流程如下：
- 對於唯一索引來說，找到 3 和 5 之間的位置，判斷到沒有衝突，插入這個值，語句執行結束；
- 對於普通索引來說，找到 3 和 5 之間的位置，插入這個值，語句執行結束。
這樣看來，普通索引和唯一索引對更新語句效能影響的差別，只是一個判斷，只會耗費微小的 CPU 時間。
第二種情況是，這個記錄要更新的目標頁不在記憶體中。這時，InnoDB 的處理流程如下：
- 對於唯一索引來說，需要將資料頁讀入記憶體，判斷到沒有衝突，插入這個值，語句執行結束；
- 對於普通索引來說，則是將更新記錄在 change buffer，語句執行就結束了。
將資料從磁碟讀入記憶體涉及隨機 IO 的訪問，是資料庫裡面成本最高的操作之一。change buffer 因為減少了隨機磁碟訪問，所以對更新效能的提升是會很明顯的。
change buffer 的使用場景
通過上面的分析，你已經清楚了使用 change buffer 對更新過程的加速作用，也清楚了 change buffer 只限於用在普通索引的場景下，而不適用於唯一索引。那麼，現在有一個問題就是：普通索引的所有場景，使用 change buffer 都可以起到加速作用嗎？
因為 merge 的時候是真正進行資料更新的時刻，而 change buffer 的主要目的就是將記錄的變更動作快取下來，所以在一個數據頁做 merge 之前，change buffer 記錄的變更越多（也就是這個頁面上要更新的次數越多），收益就越大。
因此，對於寫多讀少的業務來說，頁面在寫完以後馬上被訪問到的概率比較小，此時 change buffer 的使用效果最好。這種業務模型常見的就是賬單類、日誌類的系統。
反過來，假設一個業務的更新模式是寫入之後馬上會做查詢，那麼即使滿足了條件，將更新先記錄在 change buffer，但之後由於馬上要訪問這個資料頁，會立即觸發 merge 過程。這樣隨機訪問 IO 的次數不會減少，反而增加了 change buffer 的維護代價。所以，對於這種業務模式來說，change buffer 反而起到了副作用。
索引選擇和實踐
回到文章開頭的問題，普通索引和唯一索引應該怎麼選擇。其實，這兩類索引在查詢能力上是沒差別的，主要考慮的是對更新效能的影響。所以，建議儘量選擇普通索引。
如果所有的更新後面，都馬上伴隨著對這個記錄的查詢，那麼你應該關閉 change buffer。而在其他情況下，change buffer 都能提升更新效能。
在實際使用中，你會發現，普通索引和 change buffer 的配合使用，對於資料量大的表的更新優化還是很明顯的。特別地，在使用機械硬碟時，change buffer 這個機制的收效是非常顯著的。所以，當你有一個類似“歷史資料”的庫，並且出於成本考慮用的是機械硬碟時，那你應該特別關注這些表裡的索引，儘量使用普通索引，然後把 change buffer 儘量開大，以確保這個“歷史資料”表的資料寫入速度。
change buffer 和 redo log
理解了 change buffer 的原理，你可能會聯想到前面文章中介紹過的 redo log 和 WAL。日常容易混淆了 redo log 和 change buffer。WAL 提升效能的核心機制，也的確是儘量減少隨機讀寫，這兩個概念確實容易混淆。
現在，我們要在表上執行這個插入語句：
1 mysql> insert into t(id,k) values(id1,k1),(id2,k2);
這裡，我們假設當前 k 索引樹的狀態，查詢到位置後，k1 所在的資料頁在記憶體 (InnoDB buffer pool) 中，k2 所在的資料頁不在記憶體中。
如圖 2 所示是帶 change buffer 的更新狀態圖。
圖 2 帶 change buffer 的更新過程
分析這條更新語句，會發現它涉及了四個部分：記憶體、redo log（ib_log_fileX）、 資料表空間（t.ibd）、系統表空間（ibdata1）。
這條更新語句做了如下的操作（按照圖中的數字順序）
- Page 1 在記憶體中，直接更新記憶體；
- Page 2 沒有在記憶體中，就在記憶體的 change buffer 區域，記錄下“我要往 Page 2 插入一行”這個資訊
- 將上述兩個動作記入 redo log 中（圖中 3 和 4）。
做完上面這些，事務就可以完成了。所以，你會看到，執行這條更新語句的成本很低，就是寫了兩處記憶體，然後寫了一處磁碟（兩次操作合在一起寫了一次磁碟），而且還是順序寫的。
同時，圖中的兩個虛線箭頭，是後臺操作，不影響更新的響應時間。
那在這之後的讀請求，要怎麼處理呢？
比如，我們現在要執行
1 select * from t where k in (k1, k2)
如果讀語句發生在更新語句後不久，記憶體中的資料都還在，那麼此時的這兩個讀操作就與系統表空間（ibdata1）和 redo log（ib_log_fileX）無關了。所以，圖中就沒畫出這兩部分。
圖 3 帶 change buffer 的讀過程
從圖中可以看到：
- 讀 Page 1 的時候，直接從記憶體返回。有問到，WAL 之後如果讀資料，是不是一定要讀盤，是不是一定要從 redo log 裡面把資料更新以後才可以返回？其實是不用的。可以看一下圖 3 的這個狀態，雖然磁碟上還是之前的資料，但是這裡直接從記憶體返回結果，結果是正確的。
- 要讀 Page 2 的時候，需要把 Page 2 從磁碟讀入記憶體中，然後應用 change buffer 裡面的操作日誌，生成一個正確的版本並返回結果。
可以看到，直到需要讀 Page 2 的時候，這個資料頁才會被讀入記憶體。
所以，如果要簡單地對比這兩個機制在提升更新效能上的收益的話，redo log 主要節省的是隨機寫磁碟的 IO 消耗（轉成順序寫），而 change buffer 主要節省的則是隨機讀磁碟的 IO 消耗。
問答
1、通過圖 2 你可以看到，change buffer 一開始是寫記憶體的，那麼如果這個時候機器掉電重啟，會不會導致 change buffer 丟失呢？change buffer 丟失可不是小事兒，再從磁碟讀入資料可就沒有了 merge 過程，就等於是資料丟失了。會不會出現這種情況呢？
答：
這個問題的答案是不會丟失。雖然是隻更新記憶體，但是在事務提交的時候，我們把 change buffer 的操作也記錄到 redo log 裡了，所以崩潰恢復的時候，change buffer 也能找回來
有問到，merge 的過程是否會把資料直接寫回磁碟，這是個好問題。
merge 的執行流程是這樣的：
- 從磁碟讀入資料頁到記憶體（老版本的資料頁）
- 從 change buffer 裡找出這個資料頁的 change buffer 記錄 (可能有多個），依次應用，得到新版資料頁；
- 寫 redo log。這個 redo log 包含了資料的變更和 change buffer 的變更。
到這裡 merge 過程就結束了。這時候，資料頁和記憶體中 change buffer 對應的磁碟位置都還沒有修改，屬於髒頁，之後各自刷回自己的物理資料，就是另外一個過程了。
1）change buffer有一部分在記憶體有一部分在ibdata，做purge操作，應該就會把change buffer裡相應的資料持久化到ibdata
2）redo log裡記錄了資料頁的修改以及change buffer新寫入的資訊。如果掉電，持久化的change buffer資料已經purge，不用恢復。
主要分析沒有持久化的資料，情況又分為以下幾種:
- change buffer寫入，redo log雖然做了fsync但未commit，binlog未fsync到磁碟，這部分資料丟失
- change buffer寫入，redo log寫入但沒有commit，binlog以及fsync到磁碟，先從binlog恢復redo log，再從redo log恢復change buffer
- change buffer寫入，redo log和binlog都已經fsync。那麼直接從redo log裡恢復。
2、如果是針對非唯一索引和唯一索引的更新和delete而且條件是where 索引值=這種情況，是否二級索引和唯一索引就沒有區別呢
答：這時候要“先讀後寫”，讀的時候資料會讀入記憶體，更新的時候直接改記憶體，就不需要change buffer了
3、rr模式下，非唯一索引還會加gap，開銷應該也不算小吧
答：Gap鎖取決於業務怎麼用
4、怎麼判斷記憶體命中率的，是hit rate嘛？
答：Hit rate
5、想請教一下老師系統表空間跟資料表空間這兩個概念各是什麼意思
答：系統表空間就是用來放系統資訊的，比如資料字典什麼的，對應的磁碟檔案是ibdata1，資料表空間就是一個個的表資料檔案，對應的磁碟檔案就是 表名.ibd