普通索引可重複，唯一索引和主鍵一樣不能重複。
唯一索引可作為資料的乙個合法驗證手段，例如學生表的身份證號碼字段，我們人為規定該欄位不得重複，那麼就使用唯一索引。（一般設定學號字段為主鍵）
主鍵保證db的每一行都是唯
一、不重複，比如身份證，學號等，不重複。
唯一索引的作用跟主鍵一樣。
不同的是，在一張表裡面只能有乙個主鍵，主鍵不能為空，但唯一索引可以有多個。唯一索引可以有一條記錄為null。
比如學生表：
所以選誰做主鍵，取決於業務需求。
某居民系統，每人有唯一身份證號。若系統要按身份證號查姓名：
select name from cuser where id_card =
'ooxx'
;
id_card建立唯一索引
建立乙個普通索引
假定業務**已經確保不會寫入重複身份證號，這兩個選擇邏輯上都是正確的。
效能優化角度考慮，選擇唯一索引還是普通索引呢？
假設字段 k 上的值都不重複。
接下來分析效能。
select id from t where k=
4
看起來效能差距很小。
innodb資料按資料頁單位讀寫。即讀一條記錄時，並非將該乙個記錄從磁碟讀出，而以頁為單位，將其整體讀入記憶體。
所以普通索引，多了一次「查詢和判斷下一條記錄」的操作，即一次指標尋找和一次計算。
若k=4記錄恰為該資料頁的最後乙個記錄，則此時要取下個記錄，還得讀取下個資料頁。
對整型字段，乙個資料頁可存近千個key，因此這種情況概率其實也很低。因此計算平均效能差異時，可認為該操作成本對現在cpu開銷忽略不計。
往表中插入乙個新記錄(4,400)，innodb會有什麼反應？
這要看該記錄要更新的目標頁是否在記憶體：
將資料從磁碟讀入記憶體涉及隨機i/o訪問，是db裡成本最高的操作之一。而change buffer可以減少隨機磁碟訪問，所以更新效能提公升明顯。
普通索引、唯一索引在查詢效能上無差別，主要考慮更新效能。所以，推薦盡量選擇普通索引。
若所有更新後面，都緊跟對該記錄的查詢，那就該關閉change buffer。其它情況下，change buffer都能提公升更新效能。
普通索引和change buffer的配合使用，對於資料量大的表的更新優化還是明顯的。
在使用機械硬碟時，change buffer的收益也很大。
所以，當你有個類似「歷史資料」的庫，並且出於成本考慮用機械硬碟，應該關注這些表裡的索引，盡量使用普通索引，把change buffer 開大，確保「歷史資料」表的資料寫效能。
wal 提公升效能的核心機制，也是儘量減少隨機讀寫，它們有啥區別呢？
insert
into t(id,k)
values
(id1,k1)
,(id2,k2)
;
看如下流程：
圖中箭頭都是後台操作，不影響更新的響應。該更新做了如下操作：
page1在記憶體，直接更新記憶體
page2不在記憶體，就在change buffer區，快取乙個「往page2插一行記錄」的資訊
將前兩個動作記入redo log
之後事務完成。執行該更新語句成本很低，只寫兩處記憶體，然後寫一處磁碟（前兩次操作合在一起寫了一次磁碟），還是順序寫。
讀語句緊隨更新語句，記憶體中的資料都還在，所以此時這倆讀操作就與系統表空間和 redo log 無關。select*from t where k in
(k1, k2)
;
讀page1時，直接從記憶體返回。
要讀page2時，需把page2從磁碟讀入記憶體，然後應用change buffer裡的操作日誌，生成乙個正確版本並返回結果。可見直到需讀page2時，該資料頁才被讀入記憶體。
綜上，這倆機制的更新效能：
由於唯一索引用不了change buffer，若業務可以接受，從效能角度，優先考慮非唯一索引。
問題在於「業務可能無法確保」。本文前提是「業務**已經保證不會寫入重複資料」，才討論效能問題。
不會丟失。
雖然是只更新記憶體，但在事務提交時，change buffer的操作也被記錄到了redo log。
所以崩潰恢復時，change buffer也能找回。
從磁碟讀入資料頁到記憶體（老版本資料頁）
從change buffer找出該資料頁的change buffer 記錄(可能多個），依次應用，得到新版資料頁
寫redo log
該redo log包含資料的變更和change buffer的變更
至此merge結束。
這時，資料頁和記憶體中change buffer對應磁碟位置都尚未修改，是髒頁，之後各自刷回自己物理資料，就是另外一過程。
在構造第乙個例子的過程，通過session a的配合，讓session b刪除資料後又重新插入一遍資料，然後就發現explain結果中，rows欄位從10001變成37000多。
而如果沒有session a的配合，只是單獨執行delete from t 、call idata()、explain這三句話，會看到rows欄位其實還是10000左右。這是什麼原因呢？
如果沒有復現，檢查
為什麼經過這個操作序列，explain的結果就不對了？
delete 語句刪掉了所有的資料，然後再通過call idata()插入了10萬行資料，看上去是覆蓋了原來10萬行。
但session a開啟了事務並沒有提交，所以之前插入的10萬行資料是不能刪除的。這樣，之前的資料每行資料都有兩個版本，舊版本是delete之前資料，新版本是標記deleted的資料。
這樣，索引a上的資料其實有兩份。
不對啊，主鍵上的資料也不能刪，那沒有使用force index的語句，使用explain命令看到的掃瞄行數為什麼還是100000左右？（潛台詞，如果這個也翻倍，也許優化器還會認為選字段a作為索引更合適）
是的，不過這個是主鍵，主鍵是直接按照表的行數來估計的。而表的行數，優化器直接用的是
show table status的值。大家的機器如果io能力比較差的話，做這個驗證的時候，可以把
innodb_flush_log_at_trx_commit和sync_binlog都設成0。參考MySQL 普通索引 唯一索引和主索引
1 普通索引 普通索引 由關鍵字key或index定義的索引 的唯一任務是加快對資料的訪問速度。因此，應該只為那些最經常出現在查詢條件 wherecolumn 或排序條件 orderbycolumn 中的資料列建立索引。只要有可能，就應該選擇乙個資料最整齊 最緊湊的資料列 如乙個整數型別的資料列 來...
MySQL 普通索引 唯一索引和主索引
1.普通索引 普通索引 由關鍵字key或index定義的索引 的唯一任務是加快對資料的訪問速度。因此，應該只為那些最經常出現在查詢條件 where column 或排序條件 order by column 中的資料列建立索引。只要有可能，就應該選擇乙個資料最整齊 最緊湊的資料列 如乙個整數型別的資料...
MySQL 普通索引 唯一索引和主索引
1 普通索引 普通索引 由關鍵字key或index定義的索引 的唯一任務是加快對資料的訪問速度。因此，應該只為那些最經常出現在查詢條件 wherecolumn 或排序條件 orderbycolumn 中的資料列建立索引。只要有可能，就應該選擇乙個資料最整齊 最緊湊的資料列 如乙個整數型別的資料列 來...