層按順序執行 SQL 的步驟為：
索引相關3、MySQL 使用索引的原因？
根本原因
擴展
4、索引的三種常見底層數據結構以及優缺點
三種常見的索引底層數據結構：分別是哈希表、有序數組和搜索樹。
5、索引的常見類型以及它是如何發揮作用的？
根據葉子節點的內容，索引類型分為主鍵索引和非主鍵索引。
6、 和 實現 B 樹索引方式的區別是什么？7、 為什么設計 B+ 樹索引？
兩個考慮因素：
為什么選擇 B+ 樹：
8、什么是覆蓋索引和索引下推？
覆蓋索引：
索引下推：
9、哪些操作會導致索引失效？10、字符串加索引日志相關11、MySQL 的 是什么？12、MySQL 是如何判斷一行掃描數的？13、MySQL 的 redo log 和 區別？
14、為什么需要 redo log？15、為什么 redo log 具有 crash-safe 的能力，是 無法替代的？
第一點：redo log 可確保 判斷哪些數據已經刷盤，哪些數據還沒有
第二點：如果 redo log 寫入失敗，說明此次操作失敗，事務也不可能提交
16、當數據庫 crash 后，如何恢復未刷盤的數據到內存中？
根據 redo log 和 的兩階段提交，未持久化的數據分為幾種情況：
17、redo log 寫入方式？
redo log包括兩部分內容，分別是內存中的日志緩沖(redo log )和磁盤上的日志文件(redo log file)。
MySQL 每執行一條 DML 語句，會先把記錄寫入 redo log （用戶空間） ，再保存到內核空間的緩沖區 OS- 中，后續某個時間點再一次性將多個操作記錄寫到 redo log file（刷盤） 。這種先寫日志，再寫磁盤的技術，就是WAL。
可以發現，redo log 寫入到redo log file，是經過OS 中轉的。其實可以通過參數進行配置，參數值含義如下：
18、redo log 的執行流程?
我們來看下Redo log的執行流程，假設執行的 SQL 如下：
update?T?set?a?=1?where?id?=666
MySQL 客戶端將請求語句 T set a =1 where id =666，發往 MySQL 層。MySQL 層接收到 SQL 請求后，對其進行分析、優化、執行等處理工作，將生成的 SQL 執行計劃發到 存儲引擎層執行。 存儲引擎層將a修改為1的這個操作記錄到內存中。記錄到內存以后會修改 redo log 的記錄，會在添加一行記錄，其內容是需要在哪個數據頁上做什么修改。此后，將事務的狀態設置為 ，說明已經準備好提交事務了。等到 MySQL 層處理完事務以后，會將事務的狀態設置為 ，也就是提交該事務。在收到事務提交的請求以后，redo log 會把剛才寫入內存中的操作記錄寫入到磁盤中，從而完成整個日志的記錄過程。19、 的概念是什么，起到什么作用， 可以保證 crash-safe 嗎?20、什么是兩階段提交？
MySQL 將 redo log 的寫入拆成了兩個步驟： 和 ，中間再穿插寫入，這就是"兩階段提交"。
而兩階段提交就是讓這兩個狀態保持邏輯上的一致。 用于恢復主機故障時的未更新的物理數據， 用于備份操作。兩者本身就是兩個獨立的個體，要想保持一致，就必須使用分布式事務的解決方案來處理。
為什么需要兩階段提交呢?
在恢復數據時， 狀態為 則說明 也成功，直接恢復數據；如果 是 ，則需要查詢對應的 事務是否成功，決定是回滾還是執行。
21、MySQL 怎么知道 是完整的?
一個事務的 是有完整格式的：
22、什么是 WAL 技術，有什么優點？
WAL，中文全稱是 Write-Ahead ，它的關鍵點就是日志先寫內存，再寫磁盤。MySQL 執行更新操作后，在真正把數據寫入到磁盤前，先記錄日志。
好處是不用每一次操作都實時把數據寫盤，就算 crash 后也可以通過redo log 恢復，所以能夠實現快速響應 SQL 語句。
23、 日志的三種格式
日志有三種格式
格式
每一條會修改數據的 SQL 都會記錄在 中
Row格式
不記錄 SQL 語句上下文相關信息，僅保存哪條記錄被修改。
Mixed格式
實際上就是 與 Row 的結合。一般的語句修改使用 格式保存mysql 查詢數據庫狀態，如一些函數， 無法完成主從復制的操作，則采用 row 格式保存 ，MySQL 會根據執行的每一條具體的 SQL 語句來區分對待記錄的日志形式。
24、redo log日志格式
redo log (內存中)是由首尾相連的四個文件組成的，它們分別是：、、、。
25、原本可以執行得很快的 SQL 語句，執行速度卻比預期的慢很多，原因是什么？如何解決？
原因：從大到小可分為四種情況
解決：
26、 數據頁結構
一個數據頁大致劃分七個部分
數據相關27、MySQL 是如何保證數據不丟失的？28、誤刪數據怎么辦？
DBA 的最核心的工作就是保證數據的完整性，先要做好預防，預防的話大概是通過這幾個點：
29、drop、 和 的區別30、在 MySQL 中有兩個 kill 命令
kill 不掉的原因
31、如何理解 MySQL 的邊讀邊發32、MySQL 的大表查詢為什么不會爆內存？33、MySQL 臨時表的用法和特性34、MySQL 存儲引擎介紹（、、）35、都說 好，那還要不要使用 引擎？36、如果數據庫誤操作, 如何執行數據恢復?
數據庫在某個時候誤操作，就可以找到距離誤操作最近的時間節點的bin log，重放到臨時數據庫里，然后選擇誤刪的數據節點，恢復到線上數據庫。
主從備份相關37、MySQL 是如何保證主備同步？
主備關系的建立：
MySQL 主備切換流程：
一個事務完整的同步過程：
38、什么是主備延遲
主庫和備庫在執行同一個事務的時候出現時間差的問題，主要原因有：
39、為什么要有多線程復制策略？40、MySQL 的并行策略有哪些？41、MySQL的一主一備和一主多從有什么區別？
在一主一備的雙 M 架構里，主備切換只需要把客戶端流量切到備庫；而在一主多從架構里，主備切換除了要把客戶端流量切到備庫外，還需要把從庫接到新主庫上。
42、主庫出問題如何解決?43、MySQL 讀寫分離涉及到過期讀問題的幾種解決方案?44、MySQL的并發鏈接和并發查詢有什么區別？性能相關45、短時間提高 MySQL 性能的方法46、為什么 MySQL 自增主鍵 ID 不連續？47、 為什么要用自增 ID 作為主鍵？48、如何最快的復制一張表？49、grant 和 flush 語句50、要不要使用分區表？51、join 用法52、MySQL 有哪些自增ID？各自場景是什么？53、Xid 在 MySQL 內部是怎么生成的呢？
MySQL 內部維護了一個全局變量 ，每次執行語句（包括語句）的時候將它賦值給 ，然后給這個變量加 1。如果當前語句是這個事務執行的第一條語句，那么 MySQL 還會同時把 賦值給這個事務的 Xid。
而 是一個純內存變量，重啟之后就清零了。所以你就知道了，在同一個數據庫實例中，不同事務的 Xid 也是有可能相同的。但是 MySQL 重啟之后會重新生成新的 文件，這就保證了，同一個 文件里mysql 查詢數據庫狀態，Xid 一定是惟一的。
鎖相關54、說一下 MySQL 的鎖55、什么是幻讀？
值在同一個事務中，存在前后兩次查詢同一個范圍的數據，第二次看到了第一次沒有查詢到的數據。
幻讀出現的場景：
幻讀帶來的問題：
解決：
其它為什么系列56、為什么 MySQL 會抖一下？57、為什么刪除了表，表文件的大小還是沒變？58、count(*)實現方式以及各種 count 對比59、 排序內部原理60、如何高效的使用 MySQL 顯式隨機消息
持續更新中。
參考：
今天的嘮嗑就到這里了，我們下期再見。
重磅推薦
磊哥的正式上線了，這次的課程誠意滿滿，共計 19 大模塊，并首次加入了 Cloud 相關面試內容，共計 20 余萬字，是我目前見過最好的 Java 面試課了。
一句話概括：最全的面試題沒我新，最新的面試題沒我全。且這次配套了 6 大增值服務：簡歷輔導、一對一答疑、專屬復習規劃、項目評審、模擬面試、職業規劃，價格非常低，一次性購買，永久閱讀，點擊查看詳情：。