Mysql 知識點

1、索引 ----- 二叉樹、平衡二叉樹、b-tree、b+tree詳解

二叉樹具備如下性質：左子樹的鍵值小於根的鍵值，右子樹的鍵值大於根的鍵值。二叉樹的查詢效率就低了。所以若想二叉樹的查詢效率儘量高，須要這棵二叉樹是平衡的。

平衡二叉樹（AVL樹）在符合二叉查找樹的條件下，還知足任何節點的兩個子樹的高度最大差爲1。

 

平衡多路查找樹（B-Tree），系統從磁盤讀取數據到內存時是以磁盤塊（block）爲基本單位的，位於同一個磁盤塊中的數據會被一次性讀取出來。InnoDB存儲引擎中有頁（Page）的概念，頁是其磁盤管理的最小單位，默認16K。InnoDB每次申請磁盤空間時都會是若干地址連續磁盤塊來達到頁的大小16KB。

缺點：每一個節點中不只包含數據的key值，還有data值。而每個頁的存儲空間是有限的，若是data數據較大時將會致使每一個節點（即一個頁）能存儲的key的數量很小，當存儲的數據量很大時一樣會致使B-Tree的深度較大，增大查詢時的磁盤I/O次數，進而影響查詢效率。

B+Tree相對於B-Tree有幾點不一樣：

非葉子節點只存儲鍵值信息。

全部葉子節點之間都有一個鏈指針。

數據記錄都存放在葉子節點中

在數據庫中，B+Tree的高度通常都在2~4層。mysql的InnoDB存儲引擎在設計時是將根節點常駐內存的，也就是說查找某一鍵值的行記錄時最多隻須要1~3次磁盤I/O操做。

2、彙集索引與非彙集索引

    彙集索引：數據行的物理順序與列值（通常是主鍵的那一列）的邏輯順序相同，一個表中只能擁有一個彙集索引,通常指主鍵。

    非彙集索引：除彙集索引外其餘都是的，包括普通索引，惟一索引，全文索引。葉子節點並不包含行記錄的所有數據，而是存儲相應行數據的彙集索引鍵。使用非彙集索引查詢，而查詢列中包含了其餘該索引沒有覆蓋的列，那麼他還要進行第二次的查詢，查詢節點上對應的數據行的數據。

    mysql索引通常建5-8個左右,索引過多，影響數據的操做(insert、update、delete)。優化建議使用聯合索引。大字段值不建議建索引。建立索引和維護索引須要耗費時間，這個時間隨着數據量的增長而增長；索引須要佔用物理空間，不光是表須要佔用數據空間，每一個索引也須要佔用物理空間；當對錶進行增、刪、改、的時候索引也要動態維護，這樣就下降了數據的維護速度。

3、如何解決非彙集索引的二次查詢問題

 

  如創建符複合索引，只查詢複合索引裏的列的數據而不須要進行回表二次查詢，注意最左原則

4、Mysql 索引失效   

    一、索引列不能儲存null值，由於索引是有序的，建索引時沒法肯定位置。

    二、查詢時 採用is Null,只能全表掃描。

    三、數據庫數據量較少時，mysql判斷全表查詢快時將不使用索引。

    四、like查詢以%開頭，類型隱士轉換、列參與函數運算、使用or查詢，聯合索引非最左

 

5、MySQL中Myisam與Innodb的區別

 

InnoDB支持事物、支持行級鎖，Myisam支持表級鎖,不支持事物。

InnoDB支持MVCC、外鍵，Myisam不支持,支持全文索引。

Myisam查詢表較快。

 

6、Innodb引擎四大特色

 

插入緩衝（insert buffer),二次寫(double write),自適應哈希索引(ahi),預讀(read ahead)

參考： http://www.javashuo.com/article/p-mdhengsl-hg.html

7、Innodb的事務與日誌的實現方式

 隔離級別：讀未提交(RU)、讀已提交(RC)、可重複讀(RR)、串行，mysql默承認重複讀，mysql經過MVCC(多版本控制)和 Next-key lock(間隙鎖)解決了幻讀。

MVCC原理：經過在每行紀錄後面保存兩個隱藏的列來實現的。這兩個列，一個保存了行的建立時間，一個保存了行的過時時間（或刪除時間），固然存儲的並非實際的時間值，而是系統版本號。每開始一個新的事務，系統版本號都會自動遞增。事務開始時刻的系統版本號會做爲事務的版本號，用來和查詢到的每行紀錄的版本號進行比較。

MVCC是解決讀寫並行的幻讀，而next-key lock 間隙鎖 是解決寫寫並行的幻讀。

Mysql日誌：

慢查詢日誌（slow query log）:記錄慢查詢的日誌文件

查詢日誌（general log）:記錄全部對數據庫請求的信息

重作日誌（redo log）:

回滾日誌（undo log）:

二進制日誌（binlog）:用於複製，在主從複製中，從庫利用主庫上的binlog進行重播，實現主從同步

錯誤日誌（errorlog）:

中繼日誌（relay log）:

 

事務日誌是經過redo和innodb的存儲引擎插入緩衝（Innodb log buffer）來實現的，當開始一個事務的時候，會記錄該事務的lsn(log sequence number)號; 當事務執行時，會往InnoDB存儲引擎的日誌

的日誌緩存裏面插入事務日誌；當事務提交時，必須將存儲引擎的日誌緩衝寫入磁盤（經過innodb_flush_log_at_trx_commit來控制），也就是寫數據前，須要先寫日誌。這種方式稱爲「預寫日誌方式」。

8、MySQL數據庫cpu飆升到500%的話他怎麼處理？

 

列出全部進程，觀察全部進程，多秒沒有狀態變化的(幹掉)

查看超時日誌或者錯誤日誌

9、你是否作過主從一致性校驗，若是有，怎麼作的，若是沒有，你打算怎麼作？

 

主從一致性校驗有多種工具 例如checksum、mysqldiff、pt-table-checksum等

 

10、大家數據庫是否支持emoji表情，若是不支持，如何操做？

 

若是是utf8字符集的話，須要升級至utf8_mb4方可支持

 

11、Mysql索引查詢優化

1.避免在索引列上使用IS NULL和IS NOT NULL，列字段儘可能要有默認值.

2.避免 SELECT *

3.千萬不要 ORDER BY RAND()

4.在Join表的時候使用相同的類型並將其索引

5.當只要一行數據時使用 LIMIT 1

6.EXPLAIN 分析你的 SELECT 查詢

7.每張表都設置ID

8.不要條件列進行函數處理

9.避免使用 or，like 等字段

10.選取最適用的字段屬性，儘量減小定義字段寬度

11.用EXISTS替代IN、用NOT EXISTS替代NOT IN。

 

 

12、分佈式事物理解

 

1.事物的ACID。原子性、一致性、隔離性、持久性

2.分佈式系統中常常出現斷電、網絡異常、應用宕機等問題致使不一致問題。

3.執行事務的時候數據庫首先會記錄下這個事務的redo操做日誌，而後纔開始真正操做數據庫，在操做以前首先會把日誌文件寫入磁盤，那麼當忽然斷電的時候，即便操做沒有完成，在從新啓動數據庫時候，數據庫會根據當前數據的狀況進行undo回滾或者是redo前滾，這樣就保證了數據的強一致性。

4.隨着業務擴展，單庫沒法知足，需對數據庫垂直分庫，此時單個數據庫ACID已經不能適應。

5.CAP定理，一致性，可用性，分區容錯性。

6.程序中追求可用性要高於一致性，此時出現BASE定理,基本可用、軟狀態、最終一致性。

 

解決方案：

   

具體詳解：    http://www.javashuo.com/article/p-ceuwqijs-mu.html

 

• 兩階段提交
• 基於可靠消息服務MQ的分佈式事務，主流MQ不支持，
• TCC（兩階段+補償）二階段提交失敗，嵌入回滾代碼，Confirm/Cancel服務的冪等性保障。增大業務複雜度。
• 本地消息表：將分佈式事務分紅多個本地事物，而後經過異步mq發送消息保證一致性。

 

十3、mysql集羣原理及方案

    採用主從複製，讀寫分離，主備模式

　　 　　　

 

主從複製原理：

   採用異步複製模型 
　　

十3、mysql索引條件下推ICP

       含義：mysql查詢條件列在索引範圍內，能夠根據索引條件直接獲取數據，能夠減小存儲引擎必須訪問基表的次數以及MySQL服務器必須訪問存儲引擎的次數。

1.ICP 只適用於非彙集索引呀

2.只是適用於單表查詢，非子查詢

3.索引下推開關打開。