2020校招學習之路分享----MySQL面試總結

零：前言

先向大家道個歉，因爲個人碰到了一些不開心的事情加上實習在學新東西所以延期更新此篇了。本文主要受衆爲開發人員（後臺開發）,所以不涉及到MySQL的服務部署等更加詳細的操作和原理內容；照顧到某些原理基礎差的同學，部分內容楊媽媽會囉嗦一些解釋清楚，所以內容較多,大家準備好耐心和瓜子礦泉水.。

之前相信大家已經系統的學習了一下MySQL,也有一些實際操作經驗,但是筆試代碼能力過關了卻不代表面試可行， 因爲面試的知識點需要串聯起來且有一部分的原理內容擴展， 因此爲大家寫了面試篇應付面試（任何涉及到數據操作的公司都會有mysql面試的環節，只是面試佔比不同，希望大家好好學習）
此文不會事無鉅細的從select的用法開始講解mysql,主要針對的是開發人員需要知道的一些MySQL的知識點,主要包括索引,事務,優化等方面,以在面試中高頻的問句形式給出答案.，還有一點很重要： 基礎較差的同學先要記住，有了一定基礎之後一定要花費一點時間把某些原理搞清楚，可以上mysql官網查看一些原理的基礎。

一定要知道，記住背下來的一定會在面試中露餡，一定要花點時間去搞清楚不理解的地方,基礎差的同學就先記住，面試問道不回了的如實說自己沒有深入研究或者老師沒有講自己以爲不重要沒有深入學習

還有，這是我個人的思路理解，大家面試時根據個人的思路來回答就行啦

一：索引相關

.是一個比較高頻的面試方向，希望大家好好理解

1. 什麼是索引?

類似於書籍的目錄，索引就是一種數據結構,可以幫助我們快速的進行數據的查找.

2. 索引是個什麼樣的數據結構呢?

索引的數據結構和具體存儲引擎的實現有關, 在MySQL中使用較多的索引有Hash索引,B+樹索引等,而我們經常使用的InnoDB存儲引擎的默認索引實現爲:B+樹索引.

3. Hash索引和B+樹所有有什麼區別或者說優劣呢?

首先要知道Hash索引和B+樹索引的底層實現原理:
（我先敘述我個人理解，不要死記硬背，一定要理解，這裏面試官很容易深問）

hash索引底層就是hash表,進行查找時,調用一次hash函數就可以獲取到相應的鍵值,之後進行回表查詢獲得實際數據.B+樹底層實現是多路平衡查找樹.對於每一次的查詢都是從根節點出發,查找到葉子節點方可以獲得所查鍵值,然後根據查詢判斷是否需要回表查詢數據.

那麼可以看出他們有以下的不同:

hash索引進行等值查詢更快(一般情況下),但是卻無法進行範圍查詢.
因爲在hash索引中經過hash函數建立索引之後,索引的順序與原順序無法保持一致,不能支持範圍查詢.而B+樹的的所有節點皆遵循(左節點小於父節點,右節點大於父節點,多叉樹也類似),天然支持範圍.

hash索引不支持使用索引進行排序,原理同上.
hash索引不支持模糊查詢以及多列索引的最左前綴匹配.原理也是因爲hash函數的不可預測.AAAA和AAAAB的索引沒有相關性.
hash索引任何時候都避免不了回表查詢數據,而B+樹在符合某些條件(聚簇索引,覆蓋索引等)的時候可以只通過索引完成查詢.
hash索引雖然在等值查詢上較快,但是不穩定.性能不可預測,當某個鍵值存在大量重複的時候,發生hash碰撞,此時效率可能極差.而B+樹的查詢效率比較穩定,對於所有的查詢都是從根節點到葉子節點,且樹的高度較低.
因此,在大多數情況下,直接選擇B+樹索引可以獲得穩定且較好的查詢速度.而不需要使用hash索引.

4. 上面提到了B+樹在滿足聚簇索引和覆蓋索引的時候不需要回表查詢數據,什麼是聚簇索引?

在B+樹的索引中,葉子節點可能存儲了當前的key值,也可能存儲了當前的key值以及整行的數據,這就是聚簇索引和非聚簇索引. 在InnoDB中,只有主鍵索引是聚簇索引,如果沒有主鍵,則挑選一個唯一鍵建立聚簇索引.如果沒有唯一鍵,則隱式的生成一個鍵來建立聚簇索引.

當查詢使用聚簇索引時,在對應的葉子節點,可以獲取到整行數據,因此不用再次進行回表查詢.

5. 非聚簇索引一定會回表查詢嗎?

不一定,這涉及到查詢語句所要求的字段是否全部命中了索引,如果全部命中了索引,那麼就不必再進行回表查詢.

舉個簡單的例子,假設我們在員工表的年齡上建立了索引,那麼當進行select age from employee where age < 20的查詢時,在索引的葉子節點上,已經包含了age信息,不會再次進行回表查詢.

6. 在建立索引的時候,都有哪些需要考慮的因素呢?

建立索引的時候一般要考慮到字段的使用頻率,經常作爲條件進行查詢的字段比較適合.如果需要建立聯合索引的話,還需要考慮聯合索引中的順序.此外也要考慮其他方面,比如防止過多的所有對錶造成太大的壓力.這些都和實際的表結構以及查詢方式有關.

7. 聯合索引是什麼?爲什麼需要注意聯合索引中的順序?

MySQL可以使用多個字段同時建立一個索引,叫做聯合索引.在聯合索引中,如果想要命中索引,需要按照建立索引時的字段順序挨個使用,否則無法命中索引.

具體原因爲:

MySQL使用索引時需要索引有序,假設現在建立了"name,age,school"的聯合索引,那麼索引的排序爲: 先按照name排序,如果name相同,則按照age排序,如果age的值也相等,則按照school進行排序.

當進行查詢時,此時索引僅僅按照name嚴格有序,因此必須首先使用name字段進行等值查詢,之後對於匹配到的列而言,其按照age字段嚴格有序,此時可以使用age字段用做索引查找,以此類推.因此在建立聯合索引的時候應該注意索引列的順序,一般情況下,將查詢需求頻繁或者字段選擇性高的列放在前面.此外可以根據特例的查詢或者表結構進行單獨的調整.

8. 創建的索引有沒有被使用到?或者說怎麼纔可以知道這條語句運行很慢的原因?

MySQL提供了explain命令來查看語句的執行計劃,MySQL在執行某個語句之前,會將該語句過一遍查詢優化器,之後會拿到對語句的分析,也就是執行計劃,其中包含了許多信息. 可以通過其中和索引有關的信息來分析是否命中了索引,例如possilbe_key,key,key_len等字段,分別說明了此語句可能會使用的索引,實際使用的索引以及使用的索引長度.

9. 那麼在哪些情況下會發生針對該列創建了索引但是在查詢的時候並沒有使用呢?

使用不等於查詢,
列參與了數學運算或者函數
在字符串like時左邊是通配符.類似於’%aaa’.
當mysql分析全表掃描比使用索引快的時候不使用索引.
當使用聯合索引,前面一個條件爲範圍查詢,後面的即使符合最左前綴原則,也無法使用索引.
以上情況,MySQL無法使用索引.

10 索引的好處和壞處

先說一下索引的好處：
提高數據的檢索速度，降低數據庫IO成本；索引會降數據排好序，降低了數據排序的成本；通過使用索引可以在查詢的過程中優化使用隱藏器提高系統的性能。
再來索引的缺點：
創建索引和維護索引需要消耗時間，且由數據量決定，數據量很大時間更長；索引會佔用一定的物理空間，若建立聚簇索引會更大，對數據進行增刪改需要維護索引佔用一定空間和效率。

11 什麼時候使用索引呢？

不適用場景：在查詢很少或參考的字段（屬性），數據量比較小，修改性能遠遠大於檢索性能時，
使用 場景：全表掃描效率更高時；中大型的表查詢；增刪改操作較少，查詢操作較多時。

12.索引的類型

索引，都是實現在存儲引擎層的。主要有六種類型：

1、普通索引：最基本的索引，沒有任何約束。
2、唯一索引：與普通索引類似，但具有唯一性約束。
3、主鍵索引：特殊的唯一索引，不允許有空值。
4、複合索引：將多個列組合在一起創建索引，可以覆蓋多個列。
5、外鍵索引：只有InnoDB類型的表纔可以使用外鍵索引，保證數據的一致性、完整性和實現級聯操作。
6、全文索引：MySQL 自帶的全文索引只能用於 InnoDB、MyISAM ，並且只能對英文進行全文檢索，一般使用全文索引引擎。

13.MyISAM 索引與 InnoDB 索引的區別？

• InnoDB 索引是聚簇索引，MyISAM 索引是非聚簇索引。
• InnoDB 的主鍵索引的葉子節點存儲着行數據，因此主鍵索引非常高效。
• MyISAM 索引的葉子節點存儲的是行數據地址，需要再尋址一次才能得到數據。
• InnoDB 非主鍵索引的葉子節點存儲的是主鍵和其他帶索引的列數據，因此查詢時做到覆蓋索引會非常高效。

14.補充（進大廠的同學需觀看）

MySQL的索引原理比較深，想要去BAT大廠的同學需要看一下相關原理，這裏給大家介紹一下我觀看的鏈接http://blog.codinglabs.org/articles/theory-of-mysql-index.html
https://blog.csdn.net/tongdanping/article/details/79878302

二：事務相關

1. 什麼是事務?

理解什麼是事務最經典的就是轉賬的例子，比較基礎,相信大家也都瞭解,這裏就不再說一邊了.

事務是一系列的操作,他們要符合ACID特性.最常見的理解就是:事務中的操作要麼全部成功,要麼全部失敗.但是隻是這樣還不夠的.

2. ACID是什麼?可以詳細說一下嗎?

A=Atomicity
原子性,就是上面說的,要麼全部成功,要麼全部失敗.不可能只執行一部分操作.
C=Consistency
系統(數據庫)總是從一個一致性的狀態轉移到另一個一致性的狀態,不會存在中間狀態.
I=Isolation
隔離性: 通常來說:一個事務在完全提交之前,對其他事務是不可見的.注意前面的通常來說加了紅色,意味着有例外情況.
D=Durability
持久性,一旦事務提交,那麼就永遠是這樣子了,哪怕系統崩潰也不會影響到這個事務的結果.

3. 同時有多個事務在進行會怎麼樣呢?（併發情況下事務問題）

多事務的併發進行一般會造成以下幾個問題:
髒讀: A事務讀取到了B事務未提交的內容,而B事務後面進行了回滾.
不可重複讀: 當設置A事務只能讀取B事務已經提交的部分,會造成在A事務內的兩次查詢,結果竟然不一樣,因爲在此期間B事務進行了提交操作.
幻讀: A事務讀取了一個範圍的內容,而同時B事務在此期間插入了一條數據.造成"幻覺".

4. 怎麼解決這些問題呢?MySQL的事務隔離級別瞭解嗎?

MySQL的四種隔離級別如下:
未提交讀(READ UNCOMMITTED)
這就是上面所說的例外情況了,這個隔離級別下,其他事務可以看到本事務沒有提交的部分修改.因此會造成髒讀的問題(讀取到了其他事務未提交的部分,而之後該事務進行了回滾).

這個級別的性能沒有足夠大的優勢,但是又有很多的問題,因此很少使用.

已提交讀（不可重複讀）(READ COMMITTED)
其他事務只能讀取到本事務已經提交的部分.這個隔離級別有 不可重複讀的問題,在同一個事務內的兩次讀取,拿到的結果竟然不一樣,因爲另外一個事務對數據進行了修改.

REPEATABLE READ(可重複讀)
可重複讀隔離級別解決了上面不可重複讀的問題(看名字也知道),但是仍然有一個新問題,就是 幻讀,當你讀取id> 10 的數據行時,對涉及到的所有行加上了讀鎖,此時例外一個事務新插入了一條id=11的數據,因爲是新插入的,所以不會觸發上面的鎖的排斥,那麼進行本事務進行下一次的查詢時會發現有一條id=11的數據,而上次的查詢操作並沒有獲取到,再進行插入就會有主鍵衝突的問題.

SERIALIZABLE(可串行化)
這是最高的隔離級別,可以解決上面提到的所有問題,因爲他強制將所以的操作串行執行,這會導致併發性能極速下降,因此也不是很常用.

5. Innodb使用的是哪種隔離級別呢?

InnoDB默認使用的是可重複讀隔離級別.（mysql默認的隔離級別，串行化沒必要）

6. 對MySQL的鎖瞭解嗎?

當數據庫有併發事務的時候,可能會產生數據的不一致,這時候需要一些機制來保證訪問的次序,鎖機制就是這樣的一個機制.

就像酒店的房間,如果大家隨意進出,就會出現多人搶奪同一個房間的情況,而在房間上裝上鎖,申請到鑰匙的人纔可以入住並且將房間鎖起來,其他人只有等他使用完畢纔可以再次使用.

7. MySQL都有哪些鎖呢?像上面那樣子進行鎖定豈不是有點阻礙併發效率了?

從鎖的類別上來講,有共享鎖和排他鎖.
共享鎖: 又叫做讀鎖. 當用戶要進行數據的讀取時,對數據加上共享鎖.共享鎖可以同時加上多個.
排他鎖: 又叫做寫鎖. 當用戶要進行數據的寫入時,對數據加上排他鎖.排他鎖只可以加一個,他和其他的排他鎖,共享鎖都相斥.

用上面的例子來說就是用戶的行爲有兩種,一種是來看房,多個用戶一起看房是可以接受的. 一種是真正的入住一晚,在這期間,無論是想入住的還是想看房的都不可以.

鎖的粒度取決於具體的存儲引擎,InnoDB實現了行級鎖,頁級鎖,表級鎖.

• 共享鎖/讀鎖：互不阻塞，優先級低
• 排他鎖/寫鎖：阻塞其他鎖，優先級高，即確保在一個事務寫入時不受其他事務的影響。
• 鎖粒度：鎖定的數據量越少（粒度越小），併發程度越高，但相應的加鎖、檢測鎖、釋放鎖用的系統開銷也隨之增大。
• 鎖策略：鎖開銷與數據安全性之間的平衡 主要兩種：1 表鎖：鎖住整張表，讀鎖互不阻塞，寫鎖阻塞其他所有讀寫鎖（同一張表）。開銷最小。2 行級鎖：對每一行數據（記錄）加鎖，開銷大，併發程度高。

8.InnoDB對死鎖的處理

此處死鎖與OS死鎖類似，多個事務互相持有對方所有要申請資源的鎖不釋放，造成環路死鎖。MySQL InnoDB引擎檢測到死鎖循環依賴後，回滾持有最少行級鎖的事務

9.樂觀鎖和悲觀鎖

先介紹一個樂觀鎖：
它指的是對數據被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）修改持保守態度， 因此，在整個數據處理過程中，將數據處於鎖定狀態。悲觀鎖的實現，往往依靠數據庫提供的鎖機制（也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據）。
在悲觀鎖的情況下，爲了保證事務的隔離性，就需要一致性鎖定讀。 讀取數據時給加鎖，其它事務無法修改這些數據。修改刪除數據時也要加鎖，其它事務無法讀取這些數據。
再來說一下樂觀鎖：
相對悲觀鎖而言，樂觀鎖機制採取了更加寬鬆的加鎖機制。悲觀鎖大多數情況下依靠數據庫的鎖機制實現，以保證操作最大程度的獨佔性。但隨之而來的就是數據庫性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。
而樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基於數據版本（ Version ）記錄機制實現。何謂數據版本？即爲數據增加一個版本標識，在基於數據庫表的版本解決方案中，一般是通過爲數據庫表增加一個 “version” 字段來實現。讀取出數據時，將此版本號一同讀出，之後更新時，對此版本號加一。此時，將提交數據的版本數據與數據庫表對應記錄的當前版本信息進行比對，如果提交的數據版本號大於數據庫表當前版本號，則予以更新，否則認爲是過期數據。

三：表結構設計

1. 爲什麼要儘量設定一個主鍵?

主鍵是數據庫確保數據行在整張表唯一性的保障,即使業務上本張表沒有主鍵,也建議添加一個自增長的ID列作爲主鍵.設定了主鍵之後,在後續的刪改查的時候可能更加快速以及確保操作數據範圍安全.

2. 主鍵使用自增ID還是UUID?

推薦使用自增ID,不要使用UUID.（如果看過我之前的筆試內容應該懂）

因爲在InnoDB存儲引擎中,主鍵索引是作爲聚簇索引存在的,也就是說,主鍵索引的B+樹葉子節點上存儲了主鍵索引以及全部的數據(按照順序),如果主鍵索引是自增ID,那麼只需要不斷向後排列即可,如果是UUID,由於到來的ID與原來的大小不確定,會造成非常多的數據插入,數據移動,然後導致產生很多的內存碎片,進而造成插入性能的下降.
總之,在數據量大一些的情況下,用自增主鍵性能會好一些.
關於主鍵是聚簇索引,如果沒有主鍵,InnoDB會選擇一個唯一鍵來作爲聚簇索引,如果沒有唯一鍵,會生成一個隱式的主鍵.

3. 字段爲什麼要求定義爲not null?

MySQL官網這樣介紹:
NULL columns require additional space in the rowto record whether their values are NULL. For MyISAM tables, each NULL columntakes one bit extra, rounded up to the nearest byte.
null值會佔用更多的字節,且會在程序中造成很多與預期不符的情況.

4. 如果要存儲用戶的密碼散列,應該使用什麼字段進行存儲?

密碼散列,鹽,用戶身份證號等固定長度的字符串應該使用char而不是varchar來存儲,這樣可以節省空間且提高檢索效率.

四：存儲引擎相關

1. MySQL支持哪些存儲引擎?

MySQL支持多種存儲引擎,比如InnoDB,MyISAM, Memory,Archive等等.在大多數的情況下,直接選擇使用InnoDB引擎都是最合適的,InnoDB也是MySQL的默認存儲引擎.

2.說一下MySQL的引擎（瞭解即可）

因爲這個我個人沒有理解，沒有深入研究，大家自行百度吧就。

3.InnoDB和MyISAM有什麼區別?

4.補充（面試中碰到的一些細節問題，透露給大家）

爲什麼 SELECT COUNT() FROM table 在 InnoDB 比 MyISAM 慢？
對於 SELECT COUNT() FROM table 語句，在沒有 WHERE 條件的情況下，InnoDB 比 MyISAM 可能會慢很多，尤其在大表的情況下。因爲，InnoDB 是去實時統計結果，會全表掃描；而 MyISAM 內部維持了一個計數器，預存了結果，所以直接返回即可。
說說InnoDB的4大特性（華爲二面時問到的，我也不會但是給大家百度了一下）

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

五：零散問題常問知識點總結

1. 說一說三個範式

第一範式: 每個列都不可以再拆分（屬性不可分）. 第二範式: 非主鍵列完全依賴於主鍵,而不能是依賴於主鍵的一部分（主鍵依賴性）. 第三範式: 非主鍵列只依賴於主鍵,不依賴於其他非主鍵（傳遞依賴性）

2.反模式

範式可以避免數據冗餘，減少數據庫的空間，減輕維護數據完整性的麻煩。然而，通過數據庫範式化設計，將導致數據庫業務涉及的表變多，並且可能需要將涉及的業務表進行多表連接查詢，這樣將導致性能變差，且不利於分庫分表。因此，出於性能優先的考量，可能在數據庫的結構中需要使用反模式的設計，即空間換取時間，採取數據冗餘的方式避免表之間的關聯查詢。至於數據一致性問題，因爲難以滿足數據強一致性，一般情況下，使存儲數據儘可能達到用戶一致，保證系統經過一段較短的時間的自我恢復和修正，數據最終達到一致
需要謹慎使用反模式設計數據庫。一般情況下，儘可能使用範式化的數據庫設計，因爲範式化的數據庫設計能讓產品更加靈活，並且能在數據庫層保持數據完整性。

3. MySQL中的varchar和char有什麼區別.

這個大家如果仔細觀看了我之前的文章很容易就答出來，但是還是總結一下吧，給新來的小盆友。
char是一個定長字段,假如申請了char(10)的空間,那麼無論實際存儲多少內容.該字段都佔用10個字符,而varchar是變長的,也就是說申請的只是最大長度,佔用的空間爲實際字符長度+1,最後一個字符存儲使用了多長的空間.
在檢索效率上來講,char > varchar,因此在使用中,如果確定某個字段的值的長度,可以使用char,否則應該儘量使用varchar.例如存儲用戶MD5加密後的密碼,則應該使用char.

4.關係型數據庫和非關係型數據庫的區別

很簡單的啦，這裏製作一個表格方便大家直觀瞭解

5.一條sql語句如何在mysql中執行

這一個問題比較熱門（研發的需要了解一下，這是我實習公司數據庫程序員面試的時候問的），給大家一個github的大佬的鏈接
https://github.com/Snailclimb/JavaGuide/blob/master/docs/database/%E4%B8%80%E6%9D%A1sql%E8%AF%AD%E5%8F%A5%E5%9C%A8mysql%E4%B8%AD%E5%A6%82%E4%BD%95%E6%89%A7%E8%A1%8C%E7%9A%84.md
還有我個人的理解：

• 客戶端發送查詢到服務器；
• 服務器檢查查詢緩存query 大小寫敏感的哈希查找，常數時間）。如果命中，返回緩存中的結果，否則下一步；
• 解析語句，生成執行計劃；（SQL解析，預處理，優化器生成執行計劃）；
• 根據執行計劃，根據存儲引擎的不同調用API，執行查詢（一棵指令樹）；
• 結果返回客戶端

6.聊一聊MySQL的查詢優化

這個不是常考點，但是挺有意思的，就給大家放在這裏了。給一個大佬的鏈接：https://www.jianshu.com/p/ab958a4823d1

7.優化distinct

distinct在所有列上轉換爲group by，並與order by結合使用

8.SQL語言包括哪幾部分？每部分都有哪些操作關鍵字？

SQL語言包括數據定義(DDL)、數據操縱(DML),數據控制(DCL)和數據查詢（DQL）四個部分。
數據定義：Create Table,Alter Table,Drop Table, Craete/Drop Index等
數據操縱：Select ,insert,update,delete,
數據控制：grant,revoke
數據查詢：select

9.完整性約束包括哪些？

實體完整性、域完整性、參照完整性、用戶定義的完整性（比較基礎，就不詳細解釋了）

10.介紹一下mysql的三種刪除操作

就是三個關鍵字：drop、deete、truncate
區別：

• delete和truncate只刪除表的數據不刪除表的結構。
• 速度的話，是drop>truncate>delete
  drop和truncate都是dll，操作立即生效，不能回滾，操作不觸發trigger。delete是dml，事務提交之後纔會生效，如果有相應的trigger，執行的時候也會觸發。

使用場景：
不再需要表時，用drop；
刪除部分數據，用帶where的delete；
保留表而刪除所有數據時用truncate；

11.還有一些高頻小問題

像如何只顯示查詢數據的前十行啊、null的具體含義啊、左外連接和內聯區別啊，大家只需仔細觀看我之前的筆試總結就會拉，一定要仔細觀看哦

六：零散基礎問題（有些不重要，看看即可）

1. varchar(10)和int(10)代表什麼含義?

varchar的10代表了申請的空間長度,也是可以存儲的數據的最大長度,而int的10只是代表了展示的長度,不足10位以0填充.也就是說,int(1)和int(10)所能存儲的數字大小以及佔用的空間都是相同的,只是在展示時按照長度展示.

2.什麼是視圖

視圖是一個虛表，它的行列數據是從別的基礎表中獲得的，某幾個字段可能來自於基礎表A，某幾個字段可能來自於基礎表B。操作視圖的時候，實際上操作的就是基礎表。視圖整個的建立和刪除不影響基礎表，而對視圖內容的刪除、增加、修改直接影響基本表。當視圖來自於多個基本表時，不允許刪除和增加數據。視圖在物理上是不存在的，數據庫系統沒有專門的位置爲視圖存儲數據，視圖的數據來源於查詢語句。

視圖的作用：

提高了sql語句的複用性，就像一個函數；對數據庫進行了重構，卻不影響程序的運行；針對不同用戶來說，提高了安全性能；

3. MySQL的binlog有有幾種錄入格式?分別有什麼區別?

有三種格式,statement,row和mixed.
statement模式下,記錄單元爲語句.即每一個sql造成的影響會記錄.由於sql的執行是有上下文的,因此在保存的時候需要保存相關的信息,同時還有一些使用了函數之類的語句無法被記錄複製.
row級別下,記錄單元爲每一行的改動,基本是可以全部記下來但是由於很多操作,會導致大量行的改動(比如alter table),因此這種模式的文件保存的信息太多,日誌量太大.
mixed. 一種折中的方案,普通操作使用statement記錄,當無法使用statement的時候使用row.
此外,新版的MySQL中對row級別也做了一些優化,當表結構發生變化的時候,會記錄語句而不是逐行記錄.

4. 超大分頁怎麼處理?

超大的分頁一般從兩個方向上來解決.
數據庫層面,這也是我們主要集中關注的(雖然收效沒那麼大),類似於select * from table where age > 20 limit 1000000,10這種查詢其實也是有可以優化的餘地的. 這條語句需要load1000000數據然後基本上全部丟棄,只取10條當然比較慢. 當時我們可以修改爲select * from table where id in (select id from table where age > 20 limit 1000000,10).這樣雖然也load了一百萬的數據,但是由於索引覆蓋,要查詢的所有字段都在索引中,所以速度會很快. 同時如果ID連續的好,我們還可以select * from table where id > 1000000 limit 10,效率也是不錯的,優化的可能性有許多種,但是核心思想都一樣,就是減少load的數據.
從需求的角度減少這種請求….主要是不做類似的需求(直接跳轉到幾百萬頁之後的具體某一頁.只允許逐頁查看或者按照給定的路線走,這樣可預測,可緩存)以及防止ID泄漏且連續被人惡意攻擊.
解決超大分頁,其實主要是靠緩存,可預測性的提前查到內容,緩存至redis等k-V數據庫中,直接返回即可.

在阿里巴巴《Java開發手冊》中,對超大分頁的解決辦法是類似於上面提到的第一種.

5. 關心過業務系統裏面的sql耗時嗎?統計過慢查詢嗎?對慢查詢都怎麼優化過?

在業務系統中,除了使用主鍵進行的查詢,其他的我都會在測試庫上測試其耗時,慢查詢的統計主要由運維在做,會定期將業務中的慢查詢反饋給我們.
慢查詢的優化首先要搞明白慢的原因是什麼? 是查詢條件沒有命中索引?是load了不需要的數據列?還是數據量太大?
所以優化也是針對這三個方向來的,
首先分析語句,看看是否load了額外的數據,可能是查詢了多餘的行並且拋棄掉了,可能是加載了許多結果中並不需要的列,對語句進行分析以及重寫.
分析語句的執行計劃,然後獲得其使用索引的情況,之後修改語句或者修改索引,使得語句可以儘可能的命中索引.
如果對語句的優化已經無法進行,可以考慮表中的數據量是否太大,如果是的話可以進行橫向或者縱向的分表.

6. 什麼是存儲過程？有哪些優缺點？

存儲過程是一些預編譯的SQL語句。1、更加直白的理解：存儲過程可以說是一個記錄集，它是由一些T-SQL語句組成的代碼塊，這些T-SQL語句代碼像一個方法一樣實現一些功能（對單表或多表的增刪改查），然後再給這個代碼塊取一個名字，在用到這個功能的時候調用他就行了。2、存儲過程是一個預編譯的代碼塊，執行效率比較高,一個存儲過程替代大量T_SQL語句 ，可以降低網絡通信量，提高通信速率,可以一定程度上確保數據安全

但是,在互聯網項目中,其實是不太推薦存儲過程的,比較出名的就是阿里的《Java開發手冊》中禁止使用存儲過程,我個人的理解是,在互聯網項目中,迭代太快,項目的生命週期也比較短,人員流動相比於傳統的項目也更加頻繁,在這樣的情況下,存儲過程的管理確實是沒有那麼方便,同時,複用性也沒有寫在服務層那麼好.

7.什麼是觸發器

觸發器是監聽某種情況，觸發某種操作。
創建觸發器有四元素：一個監聽地點（table）、一個監聽事件（insert、update、delete）、一個觸發時間（before、after）、一個觸發事件（insert、delete、update）。
觸發器是數據庫對象之一，與函數非常類似，需要聲明、執行。但是觸發器的執行是由事件來觸發的。
當表發生更改時，需要自動進行一些處理，比如每增加一條學生的記錄，學生的總數就需要同時改變，這時候就要執行一次計算學生總數的操作。
觸發器的操作包括創建觸發器、查看觸發器及刪除觸發器。

題外話

沒錯，大家熟悉的卑微小編環節又來了，因爲編寫量和個人生活問題，時間很緊湊，給大家總結的有一些缺陷但是相對還是不錯的,MySQL的篇章到此爲止，如果喜歡，就給小編點個贊各一個關注哦！之後的計算機基礎知識會免費分享個大家，但是最爲重要的算法和數據結構的總結因爲個人是買了衆多資料，花費大量時間總結，所以將開放權限給關注我的人，或者支付一定C幣，大家如果覺得可以關注一下就行啦，免費給粉絲觀看的呢！