值得收藏！面試中有哪些經典的數據庫問題？

做者：程序員之言  |  今日頭條號

1、爲何用自增列做爲主鍵

一、若是咱們定義了主鍵(PRIMARY KEY)，那麼InnoDB會選擇主鍵做爲彙集索引、若是沒有顯式定義主鍵，則InnoDB會選擇第一個不包含有NULL值的惟一索引做爲主鍵索引、若是也沒有這樣的惟一索引，則InnoDB會選擇內置6字節長的ROWID做爲隱含的彙集索引(ROWID隨着行記錄的寫入而主鍵遞增，這個ROWID不像ORACLE的ROWID那樣可引用，是隱含的)。

二、數據記錄自己被存於主索引（一顆B+Tree）的葉子節點上。這就要求同一個葉子節點內（大小爲一個內存頁或磁盤頁）的各條數據記錄按主鍵順序存放，所以每當有一條新的記錄插入時，MySQL會根據其主鍵將其插入適當的節點和位置，若是頁面達到裝載因子（InnoDB默認爲15/16），則開闢一個新的頁（節點）

三、若是表使用自增主鍵，那麼每次插入新的記錄，記錄就會順序添加到當前索引節點的後續位置，當一頁寫滿，就會自動開闢一個新的頁

四、若是使用非自增主鍵（若是身份證號或學號等），因爲每次插入主鍵的值近似於隨機，所以每次新紀錄都要被插到現有索引頁得中間某個位置，此時MySQL不得不爲了將新記錄插到合適位置而移動數據，甚至目標頁面可能已經被回寫到磁盤上而從緩存中清掉，此時又要從磁盤上讀回來，這增長了不少開銷，同時頻繁的移動、分頁操做形成了大量的碎片，獲得了不夠緊湊的索引結構，後續不得不經過OPTIMIZE TABLE來重建表並優化填充頁面。

2、爲何使用數據索引能提升效率

一、數據索引的存儲是有序的

二、在有序的狀況下，經過索引查詢一個數據是無需遍歷索引記錄的

三、極端狀況下，數據索引的查詢效率爲二分法查詢效率，趨近於 log2(N)

3、B+樹索引和哈希索引的區別

B+樹是一個平衡的多叉樹，從根節點到每一個葉子節點的高度差值不超過1，並且同層級的節點間有指針相互連接，是有序的

哈希索引就是採用必定的哈希算法，把鍵值換算成新的哈希值，檢索時不須要相似B+樹那樣從根節點到葉子節點逐級查找，只需一次哈希算法便可,是無序的

4、哈希索引的優點：

一、等值查詢。哈希索引具備絕對優點（前提是：沒有大量重複鍵值，若是大量重複鍵值時，哈希索引的效率很低，由於存在所謂的哈希碰撞問題。）

5、哈希索引不適用的場景：

一、不支持範圍查詢

二、不支持索引完成排序

三、不支持聯合索引的最左前綴匹配規則

一般，B+樹索引結構適用於絕大多數場景，像下面這種場景用哈希索引才更有優點：

在HEAP表中，若是存儲的數據重複度很低（也就是說基數很大），對該列數據以等值查詢爲主，沒有範圍查詢、沒有排序的時候，特別適合採用哈希索引，例如這種SQL：

select id,name from table where name='李明'; — 僅等值查詢

而經常使用的InnoDB引擎中默認使用的是B+樹索引，它會實時監控表上索引的使用狀況，若是認爲創建哈希索引能夠提升查詢效率，則自動在內存中的「自適應哈希索引緩衝區」創建哈希索引（在InnoDB中默認開啓自適應哈希索引），經過觀察搜索模式，MySQL會利用index key的前綴創建哈希索引，若是一個表幾乎大部分都在緩衝池中，那麼創建一個哈希索引可以加快等值查詢。

注意：在某些工做負載下，經過哈希索引查找帶來的性能提高遠大於額外的監控索引搜索狀況和保持這個哈希表結構所帶來的開銷。但某些時候，在負載高的狀況下，自適應哈希索引中添加的read/write鎖也會帶來競爭，好比高併發的join操做。like操做和%的通配符操做也不適用於自適應哈希索引，可能要關閉自適應哈希索引。

6、B樹和B+樹的區別

一、B樹，每一個節點都存儲key和data，全部節點組成這棵樹，而且葉子節點指針爲nul，葉子結點不包含任何關鍵字信息。

二、B+樹，全部的葉子結點中包含了所有關鍵字的信息，及指向含有這些關鍵字記錄的指針，且葉子結點自己依關鍵字的大小自小而大的順序連接，全部的非終端結點能夠當作是索引部分，結點中僅含有其子樹根結點中最大（或最小）關鍵字。 (而B 樹的非終節點也包含須要查找的有效信息)

7、爲何說B+比B樹更適合實際應用中操做系統的文件索引和數據庫索引？

一、B+的磁盤讀寫代價更低B+的內部結點並無指向關鍵字具體信息的指針。所以其內部結點相對B樹更小。若是把全部同一內部結點的關鍵字存放在同一盤塊中，那麼盤塊所能容納的關鍵字數量也越多。一次性讀入內存中的須要查找的關鍵字也就越多。相對來講IO讀寫次數也就下降了。

二、B+-tree的查詢效率更加穩定因爲非終結點並非最終指向文件內容的結點，而只是葉子結點中關鍵字的索引。因此任何關鍵字的查找必須走一條從根結點到葉子結點的路。全部關鍵字查詢的路徑長度相同，致使每個數據的查詢效率至關。

8、MySQL聯合索引

一、聯合索引是兩個或更多個列上的索引。對於聯合索引:Mysql從左到右的使用索引中的字段，一個查詢能夠只使用索引中的一部份，但只能是最左側部分。例如索引是key index (a,b,c). 能夠支持a 、 a,b 、 a,b,c 3種組合進行查找，但不支持 b,c進行查找 .當最左側字段是常量引用時，索引就十分有效。

二、利用索引中的附加列，您能夠縮小搜索的範圍，但使用一個具備兩列的索引 不一樣於使用兩個單獨的索引。複合索引的結構與電話簿相似，人名由姓和名構成，電話簿首先按姓氏對進行排序，而後按名字對有相同姓氏的人進行排序。若是您知 道姓，電話簿將很是有用；若是您知道姓和名，電話簿則更爲有用，但若是您只知道名不姓，電話簿將沒有用處。

9、什麼狀況下應不建或少建索引

一、表記錄太少

二、常常插入、刪除、修改的表

三、數據重複且分佈平均的表字段，假如一個表有10萬行記錄，有一個字段A只有T和F兩種值，且每一個值的分佈機率大約爲50%，那麼對這種表A字段建索引通常不會提升數據庫的查詢速度。

四、常常和主字段一塊查詢但主字段索引值比較多的表字段

10、什麼是表分區？

表分區，是指根據必定規則，將數據庫中的一張表分解成多個更小的，容易管理的部分。從邏輯上看，只有一張表，可是底層倒是由多個物理分區組成。

11、表分區與分表的區別

分表：指的是經過必定規則，將一張表分解成多張不一樣的表。好比將用戶訂單記錄根據時間成多個表。

分表與分區的區別在於：分區從邏輯上來說只有一張表，而分表則是將一張表分解成多張表。

12、表分區有什麼好處？

一、分區表的數據能夠分佈在不一樣的物理設備上，從而高效地利用多個硬件設備。 2. 和單個磁盤或者文件系統相比，能夠存儲更多數據

二、優化查詢。在where語句中包含分區條件時，能夠只掃描一個或多個分區表來提升查詢效率；涉及sum和count語句時，也能夠在多個分區上並行處理，最後彙總結果。

三、分區表更容易維護。例如：想批量刪除大量數據能夠清除整個分區。

四、可使用分區表來避免某些特殊的瓶頸，例如InnoDB的單個索引的互斥訪問，ext3問價你係統的inode鎖競爭等。

十3、分區表的限制因素

一、一個表最多隻能有1024個分區

二、MySQL5.1中，分區表達式必須是整數，或者返回整數的表達式。在MySQL5.5中提供了非整數表達式分區的支持。

三、若是分區字段中有主鍵或者惟一索引的列，那麼多有主鍵列和惟一索引列都必須包含進來。即：分區字段要麼不包含主鍵或者索引列，要麼包含所有主鍵和索引列。

四、分區表中沒法使用外鍵約束

五、MySQL的分區適用於一個表的全部數據和索引，不能只對表數據分區而不對索引分區，也不能只對索引分區而不對錶分區，也不能只對表的一部分數據分區。

十4、如何判斷當前MySQL是否支持分區？

命令：show variables like '%partition%' 運行結果:

mysql> show variables like '%partition%';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| have_partitioning | YES   |
+-------------------+-------+
1 row in set (0.00 sec)

have_partintioning 的值爲YES，表示支持分區。

十5、MySQL支持的分區類型有哪些？

一、RANGE分區： 這種模式容許將數據劃分不一樣範圍。例如能夠將一個表經過年份劃分紅若干個分區

二、LIST分區： 這種模式容許系統經過預約義的列表的值來對數據進行分割。按照List中的值分區，與RANGE的區別是，range分區的區間範圍值是連續的。

三、HASH分區 ：這中模式容許經過對錶的一個或多個列的Hash Key進行計算，最後經過這個Hash碼不一樣數值對應的數據區域進行分區。例如能夠創建一個對錶主鍵進行分區的表。

四、KEY分區 ：上面Hash模式的一種延伸，這裏的Hash Key是MySQL系統產生的。

十6、四種隔離級別

一、Serializable (串行化)：可避免髒讀、不可重複讀、幻讀的發生。

二、Repeatable read (可重複讀)：可避免髒讀、不可重複讀的發生。

三、Read committed (讀已提交)：可避免髒讀的發生。

四、Read uncommitted (讀未提交)：最低級別，任何狀況都沒法保證。

十7、關於MVVC

MySQL InnoDB存儲引擎，實現的是基於多版本的併發控制協議——MVCC (Multi-Version Concurrency Control) (注：與MVCC相對的，是基於鎖的併發控制，Lock-Based Concurrency Control)。MVCC最大的好處：讀不加鎖，讀寫不衝突。在讀多寫少的OLTP應用中，讀寫不衝突是很是重要的，極大的增長了系統的併發性能，現階段幾乎全部的RDBMS，都支持了MVCC。

一、LBCC：Lock-Based Concurrency Control，基於鎖的併發控制。

二、MVCC：Multi-Version Concurrency Control，基於多版本的併發控制協議。純粹基於鎖的併發機制併發量低，MVCC是在基於鎖的併發控制上的改進，主要是在讀操做上提升了併發量。

十8、在MVCC併發控制中，讀操做能夠分紅兩類：

一、快照讀 (snapshot read)：讀取的是記錄的可見版本 (有多是歷史版本)，不用加鎖（共享讀鎖s鎖也不加，因此不會阻塞其餘事務的寫）。

二、當前讀 (current read)：讀取的是記錄的最新版本，而且，當前讀返回的記錄，都會加上鎖，保證其餘事務不會再併發修改這條記錄。

十9、行級鎖定的優勢：

一、當在許多線程中訪問不一樣的行時只存在少許鎖定衝突。

二、回滾時只有少許的更改

三、能夠長時間鎖定單一的行。

二10、行級鎖定的缺點：

一、比頁級或表級鎖定佔用更多的內存。

二、當在表的大部分中使用時，比頁級或表級鎖定速度慢，由於你必須獲取更多的鎖。

三、若是你在大部分數據上常常進行GROUP BY操做或者必須常常掃描整個表，比其它鎖定明顯慢不少。

四、用高級別鎖定，經過支持不一樣的類型鎖定，你也能夠很容易地調節應用程序，由於其鎖成本小於行級鎖定。

二11、MySQL優化

一、開啓查詢緩存，優化查詢

二、explain你的select查詢，這能夠幫你分析你的查詢語句或是表結構的性能瓶頸。EXPLAIN 的查詢結果還會告訴你你的索引主鍵被如何利用的，你的數據表是如何被搜索和排序的

三、當只要一行數據時使用limit 1，MySQL數據庫引擎會在找到一條數據後中止搜索，而不是繼續日後查少下一條符合記錄的數據

四、爲搜索字段建索引

五、使用 ENUM 而不是 VARCHAR，若是你有一個字段，好比「性別」，「國家」，「民族」，「狀態」或「部門」，你知道這些字段的取值是有限並且固定的，那麼，你應該使用 ENUM 而不是VARCHAR。

六、Prepared StatementsPrepared Statements很像存儲過程，是一種運行在後臺的SQL語句集合，咱們能夠從使用 prepared statements 得到不少好處，不管是性能問題仍是安全問題。Prepared Statements 能夠檢查一些你綁定好的變量，這樣能夠保護你的程序不會受到「SQL注入式」攻擊

七、垂直分表

八、選擇正確的存儲引擎

二12、key和index的區別

一、key 是數據庫的物理結構，它包含兩層意義和做用，一是約束（偏重於約束和規範數據庫的結構完整性），二是索引（輔助查詢用的）。包括primary key, unique key, foreign key 等

二、index是數據庫的物理結構，它只是輔助查詢的，它建立時會在另外的表空間（mysql中的innodb表空間）以一個相似目錄的結構存儲。索引要分類的話，分爲前綴索引、全文本索引等；

二十3、Mysql 中 MyISAM 和 InnoDB 的區別有哪些？

區別：

一、InnoDB支持事務，MyISAM不支持，對於InnoDB每一條SQL語言都默認封裝成事務，自動提交，這樣會影響速度，因此最好把多條SQL語言放在begin和commit之間，組成一個事務；

二、InnoDB支持外鍵，而MyISAM不支持。對一個包含外鍵的InnoDB錶轉爲MYISAM會失敗；

三、InnoDB是彙集索引，數據文件是和索引綁在一塊兒的，必需要有主鍵，經過主鍵索引效率很高。可是輔助索引須要兩次查詢，先查詢到主鍵，而後再經過主鍵查詢到數據。所以，主鍵不該該過大，由於主鍵太大，其餘索引也都會很大。而MyISAM是非彙集索引，數據文件是分離的，索引保存的是數據文件的指針。主鍵索引和輔助索引是獨立的。

四、InnoDB不保存表的具體行數，執行select count(*) from table時須要全表掃描。而MyISAM用一個變量保存了整個表的行數，執行上述語句時只須要讀出該變量便可，速度很快；

五、Innodb不支持全文索引，而MyISAM支持全文索引，查詢效率上MyISAM要高；

如何選擇：

一、是否要支持事務，若是要請選擇innodb，若是不須要能夠考慮MyISAM；

二、若是表中絕大多數都只是讀查詢，能夠考慮MyISAM，若是既有讀寫也挺頻繁，請使用InnoDB。

三、系統奔潰後，MyISAM恢復起來更困難，可否接受；

四、MySQL5.5版本開始Innodb已經成爲Mysql的默認引擎(以前是MyISAM)，說明其優點是有目共睹的，若是你不知道用什麼，那就用InnoDB，至少不會差。

二十4、數據庫表建立注意事項

一、字段名及字段配製合理性

• 剔除關係不密切的字段；
• 字段命名要有規則及相對應的含義（不要一部分英文，一部分拼音，還有相似a.b.c這樣不明含義的字段）；
• 字段命名儘可能不要使用縮寫（大多數縮寫都不能明確字段含義）；
• 字段不要大小寫混用（想要具備可讀性，多個英文單詞可以使用下劃線形式鏈接）；
• 字段名不要使用保留字或者關鍵字；
• 保持字段名和類型的一致性；
• 慎重選擇數字類型；
• 給文本字段留足餘量；

二、系統特殊字段處理及建成後建議

• 添加刪除標記（例如操做人、刪除時間）；
• 創建版本機制；

三、表結構合理性配置

• 多型字段的處理，就是表中是否存在字段可以分解成更小獨立的幾部分（例如：人能夠分爲男人和女人）；
• 多值字段的處理，能夠將表分爲三張表，這樣使得檢索和排序更加有調理，且保證數據的完整性！

四、其它建議

• 對於大數據字段，獨立表進行存儲，以便影響性能（例如：簡介字段）；
• 使用varchar類型代替char，由於varchar會動態分配長度，char指定長度是固定的；
• 給表建立主鍵，對於沒有主鍵的表，在查詢和索引定義上有必定的影響；
• 避免表字段運行爲null，建議設置默認值（例如：int類型設置默認值爲0）在索引查詢上，效率立顯；
• 創建索引，最好創建在惟一和非空的字段上，創建太多的索引對後期插入、更新都存在必定的影響（考慮實際狀況來建立）；