B+樹索引和Hash索引區別
哈希索引適合等值查詢，但是無法進行範圍查詢
哈希索引沒辦法利用索引完成排序
哈希索引不支持多列聯合索引的最左匹配規則
如果有大量重複鍵值的情況下，哈希索引的效率會很低，因爲存在哈希碰撞問題
索引失效的情況
-
對於創建的多列索引（複合索引），不是使用的第一部分就不會使用索引
-
對於使用 like 查詢， 查詢如果是 ‘%aaa’ 不會使用索引，而 ‘aaa%’ 會使用到索引
-
如果條件中有 or， 有條件沒有使用索引，即使其中有條件帶索引也不會使用，換言之， 就是要求使用的所有字段，都必須單獨使用時能使用索引。
-
如果列類型是字符串，那麼一定要在條件中使用引號引用起來，否則不使用索引。
-
.如果mysql估計使用全表掃描要比使用索引快,則不使用索引
-
索引字段使用函數則不使用索引
先重建索引，再重建主鍵索引
不合理，先重建索引沒問題，但是主鍵索引，無論刪除還是創建，都會將整個表重建，所以重建索引就做了無用功。
更新索引最好的辦法就是刷新引擎
alter table T engine=InnoDB
唯一索引和普通索引區別
數據庫更新時，並不一定會直接更新，而是會將更新放在change buffer中，等下一次讀取該內存頁或者定時任務執行時，纔將更新同步到磁盤中。
-
如果這個記錄要更新的目標頁在內存中，那麼基本沒有區別
-
這個記錄要更新的目標頁不在內存中，那麼唯一性索引需要將數據也讀入內存，判斷索引是否衝突，然後更新。
對於普通索引，直接將更新記錄記錄在change buffer中即可。
將數據從磁盤讀入內存涉及隨機 IO 的訪問，是數據庫裏面成本最高的操作之一。change buffer 因爲減少了隨機磁盤訪問，所以對更新性能的提升是會很明顯的。
對於寫多讀少的業務來說，頁面在寫完以後馬上被訪問到的概率比較小，此時 change buffer 的使用效果最好。這種業務模型常見的就是賬單類、日誌類的系統。
假設一個業務的更新模式是寫入之後馬上會做查詢，那麼即使滿足了條件，將更新先記 錄在 change buffer，但之後由於馬上要訪問這個數據頁，會立即觸發 purge 過程。這樣隨機訪問 IO 的次數不會減少，反而增加了 change buffer 的維護代價。所以，對於這種業務模式來說，change buffer 反而起到了副作用。
redo log 和 change buffer區別
redo log主要節省的是隨機寫磁盤的IO消耗(轉成順序寫)，多個事務合併爲一個事務落盤。
change buffer主要節省的則是隨機讀磁盤的IO消耗。多次讀取磁盤至內存合併爲一次讀取。