1.如何定位慢查詢?

????????1.1.介紹一下當時產生問題的場景(我們當時的接口測試的時候非常的慢，壓測的結果大概5秒鐘))，可以監測出哪個接口，最終因為是sql的問題

?????????1.2.我們系統中當時采用了運維工具(Skywalking就是2秒，一旦sql執行超過2秒就會記錄到日志中(調試階段)

? ? ? ? 1.3.在mysql中開啟了慢日志查詢，我們設置的值就是2秒，一旦sql執行超過2秒就會記錄到日志中(調試階段)

2. 這個SQL語句執行很慢,如何分析呢?

可以采用MySQL自帶的分析工具 EXPLAIN
????????2.1通過key和key len檢查是否命中了索引(索引本身存在是否有失效的情況)

????????2.2通過type字段查看sql是否有進一步的優化空間，是否存在全索引掃描或全盤掃描

????????2.3通過extra建議判斷，是否出現了回表的情況，如果出現了，可以嘗試添加索引或修改返回字段來修復

3.(什么是索引)了解過索引嗎?

????????索引(index)是幫助MySQL高效獲取數據的數據結構(有序)

????????它提高數據檢索的效率，降低數據庫的IO成本(不需要全表掃描)

????????通過索引列對數據進行排序，降低數據排序的成本，降低了CPU的消耗

4.索引的底層數據結構了解過嘛 ?

????????MySQL的InnoDB引擎采用的B+樹的數據結構來存儲索引
????????階數更多，路徑更短
????????磁盤讀寫代價B+樹更低，非葉子節點只存儲指針，葉子階段存儲數據B+樹便于掃庫和區間查詢，葉子節點是一個雙向鏈表

5.什么是聚簇索引什么是非聚簇索引?

????????聚簇索引(聚集索引):數據與索引放到一塊，B+樹的葉子節點保存了整行數據，有且只有一個

????????非聚簇索引(二級索引):數據與索引分開存儲，B+樹的葉子節點保存對應的主鍵，可以有多個

6.知道什么是回表查詢嘛 ?

????????通過二級索引找到對應的主鍵值，到聚集索引中查找整行數據，這個過程就是回表

7.知道什么叫覆蓋索引嘛 ?

????????覆蓋索引是指查詢使用了索引，返回的列，必須在索引中全部能夠找到

? ? ? ? 7.1 使用id查詢，直接走聚集索引查詢，一次索引掃描，直接返回數據，性能高。

? ? ? ?7.2??如果返回的列中沒有創建索引，有可能會觸發回表查詢，盡量避免使用select*

8.MYSQL超大分頁怎么處理?

????????問題:在數據量比較大時，limit分頁查詢，需要對數據進行排序，效率低

????????解決方案:覆蓋索引+子查詢

9.索引創建原則有哪些?

????????1).數據量較大，且查詢比較頻繁的表

????????2).常作為查詢條件、排序、分組的字段

????????3).字段內容區分度高

????????4).內容較長，使用前綴索引

????????5).盡量聯合索引

????????6).要控制索引的數量

????????7).如果索引列不能存儲NULL值，請在創建表時使用NOT NULL約束它

10.什么情況下索引會失效 ?

????????違反最左前綴法則
????????范圍查詢右邊的列，不能使用索引
????????不要在索引列上進行運算操作，索引將失效字符串不加單引號，造成索引失效。(類型轉換)
????????以%開頭的Like模糊查詢，索引失效

11.談談你對sql的優化的經驗

? ? ? ?11.1 表的設計優化(參考阿里開發手冊《嵩山版》)
????????????????① 比如設置合適的數值(tinyint int bigint)，要根據實際情況選擇
????????????????② 比如設置合適的字符串類型(char和varchar)char定長效率高，varchar可變長度，效率稍低

? ? ? ?11.2 SQL語句優化
????????????????SELECT語句務必指明字段名稱(避免直接使用select*)

????????????????SQL語句要避免造成索引失效的寫法

????????????????盡量用union all代替union union會多一次過濾，效率低

????????????????避免在where子句中對字段進行表達式操作

????????????????Join優化 能用innerjoin 就不用left join right join，如必須使用 一定要以小表為驅動內連接會對兩個表進行優化，優先把小表放到外邊，把大表放到里邊。leftjoin 或 right join，不會重新調整順序

???????11.3·主從復制、讀寫分離
????????????????如果數據庫的使用場景讀的操作比較多的時候，為了避免寫的操作所造成的性能影響 可以采用讀寫分離的架構。讀寫分離解決的是，數據庫的寫入，影響了查詢的效率.

????????11.4. 索引優化，索引創建原則

????????11.5 分庫分表

12. 事務是什么

????????事務是一組操作的集合，它是一個不可分割的工作單位，事務會把所有的操作作為一個整體一起向系統提交或撤銷操作請求，即這些操作要么同時成功，要么同時失敗。

13.事務的ACID是什么?可以詳細說一下嗎?

原子性(Atomicity):事務是不可分割的最小操作單元，要么全部成功，要么全部失敗。
一致性(Consistency):事務完成時，必使所有的數據都保持一致狀態。
隔離性(lsolation):數據庫系統提供的機制，保證事務在不受外部并發操作影響的獨立環境下運行。持久性(Durability):事務一旦提交或回它對數據庫中的數據的改變就是永久的。

14.并發事務的問題有什么？

????????臟讀：一個事務讀到另外一個事務還沒有提交的數據
????????不可重復讀：一個事務先后讀取同一條記錄，但兩次讀取的數據不同，稱之為不可重復讀。
????????幻讀：一個事務按照條件查詢數據時，沒有對應的數據行，但是在插入數據時，又發現這行數據已經存在，好像出現了“幻影”

15.事務的隔離級別有哪些？

Read uncommitted 讀未提交:三種并發事務都不能解決
Read committed 讀已提交：能解決臟讀
Repeatable Read(默認) 可重復讀（mysql的默認隔離級別）：能解決臟讀和不可重復讀
Serializable 串行化：三種并發事務都能解決

16.redo log

重做日志，記錄的是事務提交時數據頁的物理修改，redo log是用來實現事務的持久性

該日志文件由兩部分組成:重做日志緩沖(redologbuffer)以及重做日志文件(redolog file),前者是在內存中，后者在磁盤中。當事務提交之后會把所有修改信息都存到該日志文件中,用于在刷新臟頁到磁盤,發生錯誤時,進行數據恢復使用。

17. undo log

回滾日志，用于記錄數據被修改前的信息,作用包含兩個:提供回滾 和 MVCC(多版本并發控制)。undolog和redo loq記錄物理日志不一樣，它是邏輯日志
可以認為當delete一條記錄時，undolog中會記條對應的insert記錄，反之亦然
當update一條記錄時，它記錄一條對應相反的upate記錄。當執行rolback時，就可以從undolog中的邏輯記錄讀取到相應的內容并進行回滾。undolog可以實現事務的一致性和原子性

18.undo log和redo log的區別

redo log:記錄的是數據頁的物理變化，服務宕機可用來同步數據

undo log:記錄的是邏輯日志，當事務回滾時，通過逆操作恢復原來的數據

redo log保證了事務的持久性，undolog保證了事務的原子性和一致性

19.解釋-下MVCC

全稱 Multi-Version Concurrency Control，多版本并發控制。指維護一個數據的多個版本，使得讀寫操作沒有沖突， MVCC的具體實現，主要依賴于數據庫記錄中的隱式字段、undolog日志、readView。

20.好的，事務中的隔離性是如何保證的呢?(你解釋一下MVCC)

MySQL中的多版本并發控制。指維護一個數據的多個版本，使得讀寫操作沒有沖突
20.1隱藏字段:
① trx id(事務id)，記錄每一次操作的事務id，是自增的
② roll pointer(回滾指針)，指向上一個版本的事務版本記錄地址

20.2 undo log:
① 回滾日志，存儲老版本數據
② 版本鏈:多個事務并行操作某一行記錄，記錄不同事務修改數據的版本，通過roll_pointer指針形成一個鏈表

20.3 readView解決的是一個事務查詢選擇版本的問題
根據readView的匹配規則和當前的一些事務id判斷該訪問那個版本的數據
不同的隔離級別快照讀是不一樣的，最終的訪問的結果不一樣

RC:每一次執行快照讀時生成ReadView
RR:僅在事務中第一次執行快照讀時生成ReadView，后續復用

21.mysql主從同步原理?

MySQL主從復制的核心就是二進制日志binlog(DDL(數據定義語言)語句和 DML(數據操縱語言)語句)

① 主庫在事務提交時，會把數據變更記錄在二進制日志文件 Binlog 中。
② 從庫讀取主庫的二進制日志文件 Binlog ，寫入到從庫的中繼日志 Relay Log 。
③ 從庫重做中繼日志中的事件，將改變反映它自己的數據

22.你們項目用過分庫分表嗎

業務介紹
1，根據自己簡歷上的項目，想一個數據量較大業務(請求數多或業務累積大)
2，達到了什么樣的量級(單表1000萬或超過20G)
具體拆分策略
1，水平分庫，將一個庫的數據拆分到多個庫中，解決海量數據存儲和高并發的問題(sharding-???????????????????????sphere、mycat)
2，水平分表，解決單表存儲和性能的問題(sharding-sphere、mycat)
3，垂直分庫，根據業務進行拆分，高并發下提高磁盤10和網絡連接數
4，垂直分表，冷熱數據分離，多表互不影響