MySQL高頻面試題的靈魂拷問

唯一索引比普通索引快嗎, 為什麼？

唯一索引不一定比普通索引快, 還可能慢。

1. 查詢時, 在未使用limit 1的情況下, 在匹配到一條資料後, 唯一索引即返回, 普通索引會繼續匹配下一條資料, 發現不匹配後返回. 如此看來唯一索引少了一次匹配, 但實際上這個消耗微乎其微.

2. 更新時, 這個情況就比較複雜了. 普通索引將記錄放到change buffer中語句就執行完畢了. 而對唯一索引而言, 它必須要校驗唯一性, 因此, 必須將資料頁讀入記憶體確定沒有衝突, 然後才能繼續操作. 對於 寫多讀少的情況, 普通索引利用change buffer有效減少了對磁碟的訪問次數, 因此普通索引效能要高於唯一索引.

3. 加q群：478052716 免費領取（Java架構資料，影片資料，BATJ面試資料）

MySQL由哪些部分組成, 分別用來做什麼

1. Server
2. 聯結器: 管理連線, 許可權驗證.
3. 分析器: 詞法分析, 語法分析.
4. 最佳化器: 執行計劃生成, 索引的選擇.
5. 執行器: 操作儲存引擎, 返回執行結果.

6. 儲存引擎: 儲存資料, 提供讀寫介面.

7. 加q群：478052716 免費領取（Java架構資料，影片資料，BATJ面試資料）

MySQL查詢快取有什麼弊端, 應該什麼情況下使用, 8.0版本對查詢快取有什麼變更.

• 查詢快取可能會失效非常頻繁, 對於一個表, 只要有更新, 該表的全部查詢快取都會被清空. 因此對於頻繁更新的表來說, 查詢快取不一定能起到正面效果.
• 對於讀遠多於寫的表可以考慮使用查詢快取.
• 8.0版本的查詢快取功能被刪了 (￣.￣).

MyISAM和InnoDB的區別有哪些

• InnoDB支援事務, MyISAM不支援.
• InnoDB支援行級鎖, MyISAM支援表級鎖.
• InnoDB支援多版本併發控制(MVVC), MyISAM不支援.
• InnoDB支援外來鍵, MyISAM不支援.
• MyISAM支援全文索引, InnoDB不支援(但可以使用Sphinx外掛)

MySQL怎麼恢復半個月前的資料

透過整庫備份+binlog進行恢復. 前提是要有定期整庫備份且儲存了binlog日誌.

MySQL事務的隔離級別, 分別有什麼特點

1. 讀未提交(RU): 一個事務還沒提交時, 它做的變更就能被別的事務看到.
2. 讀提交(RC): 一個事務提交之後, 它做的變更才會被其他事務看到.
3. 可重複讀(RR): 一個事務執行過程中看到的資料, 總是跟這個事務在啟動時看到的資料是一致的. 當然在可重複讀隔離級別下, 未提交變更對其他事務也是不可見的.
4. 序列化(S): 對於同一行記錄, 讀寫都會加鎖. 當出現讀寫鎖衝突的時候, 後訪問的事務必須等前一個事務執行完成才能繼續執行.

做過哪些MySQL索引相關最佳化

• 儘量使用主鍵查詢: 聚簇索引上儲存了全部資料, 相比普通索引查詢, 減少了回表的消耗.
• MySQL5.6之後引入了索引下推最佳化, 透過適當的使用聯合索引, 減少回表判斷的消耗.
• 若頻繁查詢某一列資料, 可以考慮利用覆蓋索引避免回表.
• 聯合索引將高頻欄位放在最左邊.

簡要說一下資料庫正規化

• 第一正規化: 屬性不可再分.
• 第二正規化: 在一正規化的基礎上, 要求資料庫表中的每個例項或行必須可以被惟一地區分. 通常需要為表加上一個列, 以儲存各個例項的惟一標識. 這個惟一屬性列被稱為主關鍵字或主鍵.
• 第三正規化: 在二正規化的基礎上, 要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字資訊. 所以第三正規化具有如下特徵：1). 每一列只有一個值. 2). 每一行都能區分. 3). 每一個表都不包含其他表已經包含的非主關鍵字資訊.

一千萬條資料的表, 如何分頁查詢

資料量過大的情況下, limit offset分頁會由於掃描資料太多而越往後查詢越慢. 可以配合當前頁最後一條ID進行查詢, SELECT * FROM T WHERE id > #{ID} LIMIT #{LIMIT}. 當然, 這種情況下ID必須是有序的, 這也是有序ID的好處之一.

訂單表資料量越來越大導致查詢緩慢, 如何處理

分庫分表. 由於歷史訂單使用率並不高, 高頻的可能只是近期訂單, 因此, 將訂單表按照時間進行拆分, 根據資料量的大小考慮按月分表或按年分表. 訂單ID最好包含時間(如根據雪花演算法生成), 此時既能根據訂單ID直接獲取到訂單記錄, 也能按照時間進行查詢。