Mysql

一、數據庫基礎

1.1 sql 語句

1.2 數據庫優化

SQL 優化

1、我們在進行數據庫查詢時首先應該避免的是全表掃描,限定數據的范圍。比如查詢某一段時間的數據。 ? 2、對于使用where 或者 order by 的列，我們應該建立索引。 ? 3、通過explain顯示了mysql如何使用索引來處理select語句以及連接表，可以幫助選擇更好的索引和寫出更優化的查詢語句。 ? 4、同時也應該避免一些索引失效的問題。 ? 5、更多的時候是需要用到一系列的語句來完成某種工作。在這種情況下，當這個語句塊中的某一條語句運行出錯的時候，整個語句塊的操作就會變得不確定起來。要避免這種情況，就應該使用事務。 ?

數據庫優化

當MySQL單表記錄數過大時，數據庫的CRUD性能會明顯下降，一些常見的優化措施如下：1、讀/寫分離：通過主從復制實現讀寫分離，主庫負責寫，從庫負責讀；2、緩存：使用MySQL的緩存，另外對重量級、更新少的數據可以考慮使用應用級別的緩存；3、通過分庫分表的方式進行優化，主要有垂直分表和水平分表

1.3 數據庫范式

1、第一范式：屬性不可分割，每個字段都應該是不可再拆分的。比如一個字段是姓名（NAME）。 ? 2、第二范式：在第一范式的基礎之上更進一層。第二范式需要確保數據庫表中的每一列都和主鍵相關，而不能只與主鍵的某一部分相關（主要針對聯合主鍵而言）記住主鍵約束 3、第三范式：第三范式需要確保數據表中的每一列數據都和主鍵直接相關，而不能間接相關。外鍵約束比如在設計一個訂單數據表的時候，可以將客戶編號作為一個外鍵和訂單表建立相應的關系。而不可以在訂單表中添加關于客戶其它信息（比如姓名、所屬公司等）的字段。如下面這兩個表所示的設計就是一個滿足第三范式的數據庫表。

1.4 分庫分表

垂直拆分 垂直分表:也就是“大表拆小表”，基于列字段進行的。一般是表中的字段較多，將不常用的，數據較大，長度較長的拆分到“擴展表“。一般是針對那種幾百列的大表，也避免查詢時，數據量太大造成的“跨頁”問題。 ?垂直分庫:針對的是一個系統中的不同業務進行拆分，比如用戶User一個庫，商品Producet一個庫，訂單Order一個庫。 切分后，要放在多個服務器上，而不是一個服務器上。 為什么？我們想象一下，一個購物網站對外提供服務，會有用戶，商品，訂單等的CRUD。沒拆分之前,全部都是落到單一的庫上的，這會讓數據庫的單庫處理能力成為瓶頸。按垂直分庫后，如果還是放在一個數據庫服務器上，隨著用戶量增大，這會讓單個數據庫的處理能力成為瓶頸，還有單個服務器的磁盤空間，內存，tps等非常吃緊。所以我們要拆分到多個服務器上，這樣上面的問題都解決了，以后也不會面對單機資源問題。 ? 水平拆分水平分表:針對數據量巨大的單張表（比如訂單表），按照某種規則（RANGE,HASH取模等），切分到多張表里面去。但是這些表還是在同一個庫中，所以庫級別的數據庫操作還是有IO瓶頸。不建議采用。 ?水平分庫:將單張表的數據切分到多個服務器上去，每個服務器具有相應的庫與表，只是表中數據集合不同。水平分庫分表能夠有效的緩解單機和單庫的性能瓶頸和壓力，突破IO、連接數、硬件資源等的瓶頸。 ? 水平分庫分表切分規則 ? 1、RANGE：從0到10000一個表，10001到20000一個表； 2、HASH取模：一個商場系統，一般都是將用戶，訂單作為主表，然后將和它們相關的作為附表，這樣不會造成跨庫事務之類的問題。 取用戶id，然后hash取模，分配到不同的數據庫上。 3、地理區域：比如按照華東，華南，華北這樣來區分業務，七牛云應該就是如此。 4、時間：按照時間切分，就是將6個月前，甚至一年前的數據切出去放到另外的一張表，因為隨著時間流逝，這些表的數據 被查詢的概率變小，所以沒必要和“熱數據”放在一起，這個也是“冷熱數據分離”。 ? ? ? 分庫分表后引入的問題: 1、分布式事務問題 ? 如果我們做了垂直分庫或者水平分庫以后,就必然會涉及到跨庫執行SQL的問題,這樣就引發了互聯網界的老大難問題-"分布式事務"。 ? 2、跨庫join的問題 ?分庫分表后表之間的關聯操作將受到限制，我們無法join位于不同分庫的表，也無法join分表粒度不同的表， 結果原本一次查詢能夠完成的業務，可能需要多次查詢才能完成。 ? 3、橫向擴容與數據遷移的問題 ?當我們使用HASH取模做分表的時候,針對數據量的遞增,可能需要動態的增加表,此時就需要考慮因為reHash導致數據遷移的問題。 ? 4、結果集合并、排序的問題因為我們是將數據分散存儲到不同的庫、表里的,當我們查詢指定數據列表時,數據來源于不同的子庫或者子表,就必然會引發結果集合并、排序的問題。 ? ?

1.5 主從復制

什么是主從復制：是用來建立一個和主數據庫完全一樣的數據庫環境，稱為從數據庫，主數據庫一般是準實時的業務數據庫。 主從復制的作用：1、做數據的熱備:作為后備數據庫，主數據庫服務器故障后，可切換到從數據庫繼續工作，避免數據丟失。2、架構的擴展:業務量越來越大，I/O訪問頻率過高，單機無法滿足，此時做多庫的存儲，降低磁盤I/O訪問的頻率，提高單個機器的I/O性能。3、讀寫分離:使數據庫能支撐更大的并發。在報表中尤其重要。由于部分報表sql語句非常的慢，導致鎖表，影響前臺服務。如果前臺使用master，報表使用slave，那么報表sql將不會造成前臺鎖，保證了前臺速度。 主從復制的原理:分為四步走：1、主庫對所有DDL和DML產生的日志寫進binlog；2、主庫生成一個 log dump 線程，用來給從庫I/O線程讀取binlog；3、從庫的I/O Thread去請求主庫的binlog，并將得到的binlog日志寫到relay log文件中；4、從庫的SQL Thread會讀取relay log文件中的日志解析成具體操作，將主庫的DDL和DML操作事件重放。 DML（Data ManipulationLanguage）語句：即數據操縱語句，用來查詢、添加、更新、刪除等 DDL（Data Definition Languages）語句：即數據庫定義語句，用來創建數據庫中的表、索引、視圖、存儲過程、觸發器等 ? ? ? ?

1.6 讀寫分離

數據庫寫入效率要低于讀取效率，一般系統中數據讀取頻率高于寫入頻率，單個數據庫實例在寫入的時候會影響讀取性能，這是做讀寫分離的原因。實現方式主要基于mysql的主從復制，通過路由的方式使應用對數據庫的寫請求只在master上進行，讀請求在slave上進行。 在應用和數據庫之間增加代理層，代理層接收應用對數據庫的請求，根據不同請求類型轉發到不同的實例，在實現讀寫分離的同時可以實現負載均衡。 ? ?

二、索引

2.1 什么是索引

索引是一種數據結構。數據庫索引，是數據庫管理系統中一個排序的數據結構，以協助快速查詢、更新數據庫表中數據，是要占據物理空間的。 索引的實現通常使用B樹及其變種B+樹。

2.2 索引的優缺點

索引的優點：可以大大加快數據的檢索速度，這也是創建索引的最主要的原因。 索引的缺點時間方面：創建索引和維護索引要耗費時間。具體地，當對表中的數據進行增加、刪除和修改的時候，索引也要動態的維護，會降低增/改/刪的執行效率；空間方面：索引需要占物理空間。

2.3 索引的類型

唯一索引：唯一索引是不允許其中任何兩行具有相同索引值的索引；一般要求列值唯一（可以有null）。 主鍵索引：在我們給一個字段設置主鍵的時候，它就會自動創建主鍵索引，用來確保每一個值都是唯一的，且不能為空。 組合索引：多列值組成一個索引，專門用于組合搜索 全文索引：有點像是一個搜索引擎提供模糊查詢，通過對文章中關鍵字建立索引，不是直接與索引中的值相比較。（http://www.360doc.com/content/17/1211/13/33260087_712076317.shtml） 非聚集索引將數據存儲于索引分開結構，索引結構的葉子節點指向了數據的對應行。當定位到索引之后還需要通過索引找到磁盤相應數據。 聚簇索引:將數據存儲與索引放到了一塊，找到索引也就找到了數據。

2.4 索引的創建原則

建立索引： 1、查詢比較頻繁：較頻繁作為查詢條件的字段才去創建索引 2、有外鍵的列：定義有外鍵的數據列一定要建立索引。不建立索引 1、頻繁更改：更新頻繁字段不適合創建索引 2、查詢較少：對于那些查詢中很少涉及的列，重復值比較多的列不要建立索引。 3、區分度比較低：若是不能有效區分數據的列不適合做索引列(如性別，男女未知，最多也就三種，區分度實在太低) 4、對于定義為text、image和bit的數據類型的列不要建立索引。擴展索引 盡量的擴展索引，不要新建索引。比如表中已經有a的索引，現在要加(a,b)的索引，那么只需要修改原來的索引即可。

2.5 索引失效條件

1、如果條件中有or，即使其中有部分條件帶索引也不會使用 2、like以%開頭 3、對于復合索引，如果不使用前列，后續列也將無法使用 4、存在索引列的數據類型隱形轉換，則用不上索引，比如列類型是字符串，那一定要在條件中將數據使用引號引用起來,否則不使用索引 5、where 子句里對索引列上有數學運算，用不上索引 6、where 子句里對有索引列使用函數，用不上索引 7、"如果mysql估計使用全表掃描要比使用索引快,則不使用索引" https://www.cnblogs.com/liehen2046/p/11052666.html

2.6 B樹索引和Hash 索引的區別

B+樹索引：是通過B+樹實現的；B+樹是一個多路平衡查找樹，從根節點到每個葉子節點的高度差值不超過1，而且葉子的節點之按照大小順序從左往右排序并通過指針相連。在B+樹上的常規檢索，"從根節點到葉子節點的搜索效率基本相當，不會出現大幅波動。而且基于索引的順序掃描時，效率非常高"。因此，B+樹索引被廣泛應用于數據庫、文件系統等場景。

Hash 索引：哈希索引就是采用一定的哈希算法，把鍵值換算成新的哈希值，檢索時不需要類似B+樹那樣從根節點到葉子節點逐級查找，只需一次哈希算法即可立刻定位到相應的位置，速度非常快。

B+樹索引和哈希索引的明顯區別是: (1) 如果是等值查詢，那么哈希索引明顯有絕對優勢，因為只需要經過一次算法即可找到相應的鍵值；當然了，這個前提是，鍵值都是唯一的。如果鍵值不是唯一的，就需要先找到該鍵所在位置，然后再根據鏈表往后掃描，直到找到相應的數據； (2)如果是范圍查詢檢索，這時候哈希索引就毫無用武之地了，因為"原先是有序的鍵值，經過哈希算法后，有可能變成不連續的了"(3)同理，哈希索引也沒辦法利用索引完成排序,以及like `xxx%`這樣的模糊查詢（范圍查詢)(4)hash索引不?持多了聯合索引的最左匹配規則,原理也是因為hash函數的不可預測。AAAA和AAAAB的索引沒有相關性。(5)hash索引雖然在"等值查詢上較快，但是不穩定。性能不可預測，當某個鍵值存在大量重復的時候，發生hash碰撞，此時效率可能極差”。而B+樹的查詢效率比較穩定，對于所有的查詢都是從根節點到葉子節點，且樹的高度較低。 因此，在大多數情況下，直接選擇B+樹索引可以獲得穩定且較好的查詢速度。而不需要使用hash索引。

2.7 介紹一下B 樹、B + 樹

B樹是一種平衡的多叉查找樹，通常我們說m階的B樹，它必須滿足如下條件： 1、每個節點最多只有m個子節點。 2、若根節點不是非終端節點，至少有兩個孩子3、除根結點和葉子結點外，其它每個結點至少有[ceil(m / 2)]個孩子（向上取整） 4、中間的節點有k-1個元素和k個孩子5、所有葉子結點都出現在同一層 6、每個節點中元素從小到大排列 B+樹是應文件系統所需而產生的B樹的變形樹，其特征在于1、有m個子樹的中間節點包含有m個元素（B樹中是k-1個元素），每個元素不保存數據，只用來索引；2、葉子節點包含信息，非葉子節點僅起到索引作用。3、葉子節點包含全部的關鍵子信息，且葉子結點本身依關鍵字的大小自小而大的順序鏈接。

2.8 為什么說B+樹比B樹更適合數據庫索引？

1）B+樹的磁盤讀寫代價更低B+樹的內部結點并沒有指向關鍵字具體信息的指針。因此其內部結點相對B 樹更小。那么一個盤塊所能容納的關鍵字數量也越多。一次性讀入內存中的需要查找的關鍵字也就越多。相對來說IO讀寫次數也就降低了；2）B+樹查詢效率更加穩定由于非終結點并不是最終指向文件內容的結點，而只是葉子結點中關鍵字的索引。所以任何關鍵字的查找必須走一條從根結點到葉子結點的路。所有關鍵字查詢的路徑長度相同，導致每一個數據的查詢效率相當； 3）B+樹便于范圍查詢（最重要的原因，范圍查找是數據庫的常態）B樹在提高了IO性能的同時并沒有解決元素遍歷的效率低下的問題，正是為了解決這個問題，B+樹應用而生。B+樹只需要去遍歷葉子節點就可以實現整棵樹的遍歷。而且在數據庫中基于范圍的查詢是非常頻繁的，而B樹不支持這樣的操作或者說效率太低

2.9 最左前綴原則是什么？

在進行組合搜索的時候，我們通常會將建立組合索引。 MySQL中的索引可以按照一定順序引用多列，這種索引叫作聯合索引。如User表的name和city加聯合索引就是(name,city) 而最左前綴原則指的是，如果查詢的時候查詢條件精確匹配索引的左邊連續一列或幾列，則此索引列就可以被用到。如下： select * from user where name=xx and city=xx ; ／／可以命中索引 select * from user where name=xx ; // 可以命中索引 select * from user where city=xx ; // 無法命中索引 這里需要注意的是，查詢的時候如果兩個條件都用上了，但是順序不同，如 city= xx and name ＝xx，那么現在的查詢引擎會自動優化為匹配聯合索引的順序，這樣是能夠命中索引的。

三、事務

3.1 簡單介紹一下事務

事務是一個不可分割的數據庫操作序列，也是數據庫并發控制的基本單位。 事務執行的結果必須使數據庫從一種一致性狀態變到另一種一致性狀態。 事務中包含的這組操作，要么都執行，要么都不執行。

3.2 事務的四大特性

原子性（Atomicity）:原子性是指事務包含的所有操作要么全部成功，要么全部失敗回滾. 一致性（Consistency）:事務開始前和結束后，數據庫的完整性約束沒有被破壞。比如A向B轉賬，不可能A扣了錢，B卻沒收到。 隔離性（Isolation）: 多個事務并發訪問時，事務之間是隔離的，一個事務不應該影響其它事務運行效果。 持久性（Durability）:持久性是指一個事務一旦被提交了，那么對數據庫中的數據的改變就是永久性的

3.3 事務之間的相互影響（事務并發）

臟讀：事務A讀取了事務B更新的數據，然后B回滾操作，那么A讀取到的數據是臟數據.不可重復讀：事務A多次讀取同一數據，事務B在事務A多次讀取的過程中，對數據作了更新并提交，導致事務A多次讀取同一數據時，結果事務先后兩次讀到的數據結果會不一致。幻讀：幻讀，是指當事務不是獨立執行時發生的一種現象，例如第一個事務對一個表中的數據進行了修改，這種修改涉及到表中的全部數據行。同時，第二個事務也修改這個表中的數據，這種修改是向表中插入一行新數據。那么，以后就會發生操作第一個事務的用戶發現表中還有沒有修改的數據行，就好象發生了幻覺一樣.

3.4 事務的隔離級別

隔離級別共4種 1、讀未提交:即能夠讀取到沒有被提交的數據，所以很明顯這個級別的隔離機制無法解決臟讀、不可重復讀、幻讀中的任何一種 2、讀已提交:即能夠讀到那些已經提交的數據，自然能夠防止臟讀，但是無法限制不可重復讀和幻讀 3、重復讀取:即在數據讀出來之后加鎖。這樣就解決了臟讀、不可重復讀的問題，但是幻讀的問題還是無法解決。 4、串行化:最高的事務隔離級別，不管多少事務，挨個運行完一個事務的所有子事務之后才可以執行另外一個事務里面的所有子事務，這樣就解決了臟讀、不可重復讀和幻讀的問題。MySQL 支持4種事務隔離級別;MySQL默認的事務隔離級別為可重復讀。事務隔離機制的實現基于鎖機制和并發調度。

3.5 事務的傳播行為

事務傳播行為:指的就是當一個事務方法被另一個事務方法調用時，這個事務方法應該如何運行。 事務的7種傳播行為: mandatory強制性，有事務則加入，沒有異常； supports支持，有則加入，沒有就不管了，非事務運行； required需要，沒有新建，有加入 requires_new需要新的，不管有沒有，直接創建新事務 not supported不支持事務，存在就掛起 never不支持事務，存在就異常 nested:存在就在嵌套的執行，沒有就找是否存在外面的事務，有則加入，沒有則新建 對事務的要求程度可以從大到小排序：mandatory / supports / required / requires_new / nested / not supported / never

3.6 事務的隔離級別和鎖之間的關系

在Read Uncommitted級別下，讀取數據不需要加共享鎖，這樣就不會跟被修改的數據上的排他鎖沖突在Read Committed級別下，讀操作需要加共享鎖，但是在語句執行完以后釋放共享鎖；在Repeatable Read級別下，讀操作需要加共享鎖，必須等待事務執行完畢以后才釋放共享鎖。SERIALIZABLE 是限制性最強的隔離級別，因為該級別鎖定整個范圍的鍵，并一直持有鎖，直到事務完成。

四、數據庫存儲引擎

4.1 Mysql 最常用的存儲引擎

Innodb引擎：Innodb引擎提供了對數據庫事務的支持。并且還提供了行級鎖和外鍵的約束。它的設計的目標就是處理大數據容量的數據庫系統。 MyIASM引擎(原本Mysql的默認引擎)：不提供事務的支持，也不支持行級鎖和外鍵。 MEMORY引擎：所有的數據都在內存中，數據的處理速度快，但是安全性不高。

4.2 MyISAM與InnoDB區別

1.事務：InnoDB支持事務，MyISAM不支持， 這一點是非常之重要。事務是一種高級的處理方式，如在一些列增刪改中只要哪個出錯還可以回滾還原，而MyISAM就不可以了。 2.外鍵：InnoDB支持外鍵，MyISAM不支持。 3.鎖：鎖是避免資源爭用的機制，MYIASM只支持表級鎖，InnoDB支持行級鎖，鎖定力度小并發能力高 。4.增刪改查：MyISAM適合查詢以及插入為主的應用，InnoDB適合頻繁修改以及涉及到安全性較高的應用。 5.存儲結構：MYIASM每張表被存放在3個文件中（表格定義，數據文件，索引文件）；InnoDB所有的表都存放在同一個文件中6.存儲空間：MYIASM可被壓縮，存儲空間小；InnoDB需要更多的內存和存儲。 7.索引：兩者都是使用B+樹作為存儲結構，但是在實現方式上面差別很大。 MyIASM:索引結構為非聚簇索引,索引和數據文件是分離的，索引保存的是數據文件的指針。 InnoDB:索引結構為聚簇索引,數據文件是和（主鍵）索引綁在一起的,必須要有主鍵，通過主鍵索引效率很高。Innodb不支持全文索引，而MyISAM支持全文索引。 Innodb支持HASh索引，而MyISAM不支持HASH索引。

4.3 InnoDB引擎的4大特性

插入緩沖（insert buffer)、二次寫(double write)、自適應哈希索引(ahi)、預讀(read ahead) https://www.jianshu.com/p/dcc0dc450a2c

4.4 存儲引擎選擇

如果沒有特別的需求，使用默認的Innodb即可。 MyISAM：以讀寫插入為主的應用程序，比如博客系統、新聞門戶網站。 Innodb：更新操作頻率也高，或者要保證數據的完整性；并發量高，支持事務和外鍵。比如OA自動化辦公系統。

五、數據庫的鎖

5.1、談一下對于MySQL鎖的了解

當數據庫有并發事務的時候，可能會產生數據的不一致，這時候需要一些機制來保證訪問的次序，鎖機制就是這樣的一個機制。就像酒店的房間，如果大家隨意進出，就會出現多人搶奪同一個房間的情況，而在房間上裝上鎖，申請到鑰匙的人才可以入住并且將房間鎖起來，其他人只有等他使用完畢才可以再次使用。

5.2、按照鎖的粒度劃分數據庫鎖有哪些？

在關系型數據庫中，可以按照鎖的粒度把數據庫鎖分為行級鎖(INNODB引擎)、表級鎖(MYISAM引擎)和頁級鎖(BDB引擎 )。 行級鎖，表級鎖和頁級鎖對比1、行級鎖：行級鎖是Mysql中鎖定粒度最細的一種鎖，表示只針對當前操作的行進行加鎖。行級鎖分為共享鎖 和 排他鎖。 特點：鎖定粒度最小，加鎖慢，開銷大，會出現死鎖；發生鎖沖突的概率最低，并發度也最高。 2、表級鎖：表級鎖是MySQL中鎖定粒度最大的一種鎖，表示對當前操作的整張表加鎖。它實現簡單，資源消耗較少，被大部分MySQL引擎支持。最常使用的MYISAM與INNODB都支持表級鎖定。表級鎖定分為表共享讀鎖（共享鎖）與表獨占寫鎖（排他鎖）。 特點：鎖定粒度最大，加鎖快，開銷小，不會出現死鎖；發出鎖沖突的概率最高，并發度最低。3、頁級鎖：頁級鎖是MySQL中鎖定粒度介于行級鎖和表級鎖中間的一種鎖，一次鎖定相鄰的一組記錄。特點：鎖定粒度界于表鎖和行鎖之間，開銷和加鎖時間界于表鎖和行鎖之間，會出現死鎖；并發度一般 MyISAM和InnoDB存儲引擎使用的鎖：MyISAM采用表級鎖(table-level locking)。InnoDB支持行級鎖(row-level locking)和表級鎖，默認為行級鎖

5.3、從鎖的類別上分MySQL都有哪些鎖呢？

在關系型數據庫中，可以按照鎖的的類別分為：有共享鎖和排他鎖。 共享鎖: 又叫做讀鎖。當用戶要進行數據的讀取時，對數據加上共享鎖。共享鎖可以同時加上多個。 排他鎖: 又叫做寫鎖。當用戶要進行數據的寫入時，對數據加上排他鎖。排他鎖只可以加一個，他和其他的排他鎖，共享鎖都相斥。

5.4 、InnoDB引擎的行鎖是怎么實現的？

答：InnoDB是基于索引來完成行鎖 例: select * from tab_with_index where id = 1 for update; for update 可以根據條件來完成行鎖鎖定，并且 id 是有索引鍵的列，如果 id 不是索引鍵那么InnoDB將完成表鎖，并發將無從談起

5.5、 InnoDB存儲引擎的鎖的算法有三種

Record lock：單個行記錄上的鎖 Gap lock：間隙鎖，鎖定一個范圍，不包括記錄本身 Next-key lock：record+gap 鎖定一個范圍，包含記錄本身

5.6 什么是死鎖？怎樣解決？

死鎖是指兩個或多個事務在同一資源上相互占用，并請求鎖定對方的資源，從而導致惡性循環的現象。 常見的解決死鎖的方法: 1、 2、如果不同程序會并發存取多個表，盡量約定以相同的順序訪問表，可以大大降低死鎖機會。 3、對于非常容易產生死鎖的業務部分，可以嘗試使用升級鎖定顆粒度，通過表級鎖定來減少死鎖產生的概率；

5.7、數據庫的樂觀鎖和悲觀鎖是什么？怎么實現的？

數據庫管理系統中的并發控制的任務:是確保在多個事務同時存取數據庫中同一數據時不破壞事務的隔離性和一致性以及數據庫的統一性。 樂觀并發控制（樂觀鎖）和悲觀并發控制（悲觀鎖）是并發控制主要采用的技術手段。 悲觀鎖：當我們要對一個數據庫中的一條數據進行修改的時候，假設數據會造成沖突，最好的辦法就是直接對該數據進行加鎖以防止并發。這種借助數據庫鎖機制，在修改數據之前先鎖定，再修改的方式被稱之為悲觀并發控制 悲觀鎖的實現方式：借助數據庫鎖機制 樂觀鎖：當我們要對一個數據庫中的一條數據進行修改的時候，假設數據不會造成沖突，在對數據進行提交更新的時候，才會正式對數據的沖突與否進行檢測，如果發現沖突了，則返回給用戶錯誤的信息，讓用戶決定如何去做。 樂觀鎖的實現方式：一般會使用版本號機制或CAS算法實現。 兩種鎖的使用場景 我們知道兩種鎖各有優缺點，不可認為一種好于另一種。 樂觀鎖適用于寫比較少的情況下（多讀場景），即沖突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。 悲觀鎖適用于寫比較多的情況下（多寫場景），即沖突經常發生的時候。這就會導致上層應用會不斷的進行retry，這樣反倒是降低了性能，

六、視圖& 觸發器

6.1 為什么要使用視圖？什么是視圖？

為了提高"復雜SQL語句的復用性"和"表操作的安全性"，MySQL數據庫管理系統提供了視圖特性。 1、視圖是由基本表產生的虛表。 2、視圖的列可以來自不同的表。 3、視圖的建立和刪除不影響基本表。 4、對視圖內容的增刪改直接影響基本表。

6.2 視圖的使用場景有哪些？

1、重用SQL語句 2、簡化復雜的SQL操作。在編寫查詢后，可以方便的重用它而不必知道它的基本查詢細節； 3、使用表的組成部分而不是整個表； 4、保護數據。可以給用戶授予表的特定部分的訪問權限而不是整個表的訪問權限；

6.3 觸發器

觸發器是定義在關系表上的"一類由事件驅動"的特殊的存儲過程。 使用場景：1、實時監控某張表中的某個字段的更改而需要做出相應的處理。2、可以通過數據庫中的相關表實現級聯更改。

總結

以上是生活随笔為你收集整理的MSQL常见面试问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。