1. 程式人生 > >揭秘數據庫面試,讓你技術面試一次過

揭秘數據庫面試,讓你技術面試一次過

得此寶典 讓技術面試更簡單

大家可以叫我老張,網名superZS!一直從事數據庫行業10余年,工作於某數據庫服務公司,兼數據庫資深講師,就面試中大家遇到的比較困惑的數據庫問題,和剛進入數據庫領域的同學們,我在這裏給大家做一個詳細的總結,希望對大家在工作或者面試中有所幫助,老師會傾囊相授,道行尚淺,大家相互學習!讓我們努力學習技術,為了拿到高薪,追到心儀的姑娘,而奮鬥吧!


葵花寶典

Question 1:

你目前接觸的mysql版本是什麽?除了官方版本,還接觸過其他的mysql分支版本嘛?

產生分支的原因

許多開發人員認為有必要將其拆分成其他項目,並且每個分支項目都有自己的專長。該需求以及Oracle對核心產品增長緩慢的擔憂,導致出現了許多開發人員感興趣的子項目和分支

三個流行MySQL分支:Drizzle、MariaDB和Percona Server(包括XtraDB引擎)

MariaDB不僅是mysql的替代品,主要還是創新和提高mysql自有技術。

新功能介紹

  1. multi-source replication 多源復制

  2. 表的並行復制

  3. galera cluster集群

  4. spider水平分片

  5. tokuDB存儲引擎

XtraDB是innodb存儲引擎的增強版,可用來更好地發揮最新的計算機硬件系統性能,還包含在高性能模式下的新特性。它可以向下兼容,因為它是在innodb基礎上構建,所以他有更多的指標和擴展功能。而且它在cpu多核的條件下,可以更好地使用內存,時數據庫性能提到更高!

Drizzle與mysql的差別就比較大了,並且不能兼容,如果想運行此環境,就需要重寫一些代碼了!


Question 2:

mysql主要的存儲引擎myisam和innodb的不同之處?

  1. 事務的支持不同(innodb支持事務,myisam不支持事務)

  2. 鎖粒度(innodb行鎖應用,myisam表鎖)

  3. 存儲空間(innodb既緩存索引文件又緩存數據文件,myisam只能緩存索引文件)

  4. 存儲結構

    (myisam:數據文件的擴展名為.MYD myData ,索引文件的擴展名是.MYI myIndex)

(innodb:所有的表都保存在同一個數據文件裏面 即為.Ibd)

5. 統計記錄行數

(myisam:保存有表的總行數,select count(*) from table;會直接取出出該值)

(innodb:沒有保存表的總行數,select count(*) from table;就會遍歷整個表,消耗相當大)


Question 3

Innodb的體系結構簡單介紹一下?

談及到innodb的體系結構,首先要考慮mysql的體系結構,分為兩部分mysql的server層和存儲引擎層

先要跟面試官聊清楚mysql的整體方向,然後再去涉及innodb體系結構

建議從三方面介紹innodb體系結構:內存----線程-----磁盤

內存中包含insert_buffer,data_buffer,index_buffer,redo_log_buffer,double_write

內存刷新到磁盤的機制,redo,臟頁,binlog的刷新條件

各種線程的作用,master_thread,purge_thread,redo log thread,read thread,write thread,page cleaner thread

磁盤中存放著數據文件,redo log,undo log,binlog


Question 4:

mysql有哪些索引類型:

  1. 數據結構角度上可以分:B+tree索引,hash索引,fulltext索引(innodb,myisam都支持)

  2. 存儲角度上可以分:聚集索引,非聚集索引

  3. 邏輯角度上可以分:primary key,normal key,單列,復合,覆蓋索引


Question 5:

mysql binlog有幾種格式:

1. statement

優點:不需要記錄每一行的變化,減少了binlog日誌量,節約了IO,提高性能

缺點:當使用一些特殊函數的時候,或者跨庫操作的時候容易丟失數據

註:在生產中不建議使用

2. row

優點:清晰記錄每行的數據信息,不會出現跨庫丟數據的情況

缺點:內容當記錄到日誌中的時候,都將以每行記錄的修改來記錄,但就會產生大量的binlog,對於網絡開銷也比較大

註:生產中推薦使用

3. mixed

是mysql5.1的時候,一個過渡版本,DDL語句會記錄成statement,DML會記錄row。

註:生產中不建議使用


Qusetion 6:

mysql主從復制的具體原理是什麽?

主服務器把數據更新記錄到二進制日誌中,從服務器通過io thread向主庫發起binlog請求,主服務器通過IO dump thread把二進制日誌傳遞給從庫,從庫通過io thread記錄到自己的中繼日誌中。然後再通過sql thread應用中繼日誌中sql的內容。


Qusetion 7:

數據庫中雙一是什麽?

sync_binlog=1

innodb_flush_log_at_trx_commit=1

innodb_flush_log_at_trx_commit和sync_binlog 兩個參數是控制MySQL 磁盤寫入策略以及數據安全性的關鍵參數

innodb_flush_log_at_trx_commit設置為1,每次事務提交時MySQL都會把log buffer的數據寫入log file,並且刷到磁盤中去。

sync_binlog =N (N>0) ,MySQL 在每寫 N次 二進制日誌binary log時,會使用fdatasync()函數將它的寫二進制日誌binary log同步到磁盤中去


Qusetion 8:

如何監控mysql replication復制延遲?

  1. 可以通過第三方工具 業界中的瑞士軍刀percona-toolkit中的命令,pt-heartbeat進行主從延遲監控。

  2. 傳統方法,通過比較主從服務器之間的position號的差異值。

  3. 還可以通過查看seconds_behind_master估算一下主從延遲時間


Qusetion 9:

大表DDL語句,如何實施,才能把性能影響降到最低?

  1. 可以通過傳統方法導入導出數據,新建一張與原表一樣的表結構,把需要執行的ddl語句在無數據的新表執行,然後把老表中的數據導入到新表中,把新表改成老表的名字

  2. 通過第三方工具 業界中的瑞士軍刀percona-toolkit中的命令,pt-online-schema-change進行在線操作

  3. 對於新版本的mysql(5.7)可以直接在線online ddl


Qusetion 10:

為什麽要為innodb表設置自增列做主鍵?

1.使用自增列做主鍵,寫入順序是自增的,和B+數葉子節點分裂順序一致

2.表不指定自增列做主鍵,同時也沒有可以被選為主鍵的唯一索引,InnoDB就會選擇內置的rowid作為主鍵,寫入順序和rowid增長順序一致

所以InnoDB表的數據寫入順序能和B+樹索引的葉子節點順序一致的話,這時候存取效率是最高


Qusetion 11:

如何優化一條有問題的sql語句?

針對sql語句的優化,我們不要上來就回答添加索引,這樣顯得太不專業。我們可以從如下幾個角度去分析

  1. 回歸到表的設計層面,數據類型選擇是否合理

  2. 大表碎片的整理是否完善

  3. 表的統計信息,是不是準確的

  4. 審查表的執行計劃,判斷字段上面有沒有合適的索引

  5. 針對索引的選擇性,建立合適的索引(就又涉及到大表DDL的操作問題)


Qusetion 12:

服務器負載過高或者網頁打開緩慢,簡單說說你的優化思路 ?

  1. 首先我們要發現問題的過程,通過操作系統,數據庫,程序設計,硬件角度四個維度找到問題所在

  2. 找到瓶頸點的位置

  3. 制定好優化方案,形成處理問題的體系

  4. 體系制定好之後,在測試環境進行優化方案的測試

  5. 測試環境如果優化效果很好,再實施到生產環境

  6. 做好處理問題的記錄


Qusetion 13:

接觸過哪些mysql的主流架構?架構應用中有哪些問題需要考慮

  1. M-S

  2. MHA

  3. MM keepalived

  4. PXC

共同存在的問題:主從延遲問題的存在,在主庫宕機,切換過程中要考慮數據一致性的問題,避免出現主從復制不一致


Qusetion14:

什麽是死鎖?鎖等待?如何優化這類問題?通過數據庫哪些表可以監控?

死鎖是指兩個或多個事務在同一資源上互相占用,並請求加鎖時,而導致的惡性循環現象。當多個事務以不同順序試圖加鎖同一資源時,就會產生死鎖。

鎖等待:mysql數據庫中,不同session在更新同行數據中,會出現鎖等待

重要的三張鎖的監控表innodb_trx,innodb_locks,innodb_lock_waits


Qusetion 15:

處理過mysql哪些案例

我們可以簡單從mysql四個知識模塊跟他聊聊mysql體系結構,數據備份恢復,優化,高可用集群架構

  1. mysql版本的升級

  2. 處理mysql集群的各種坑和問題

  3. 根據公司業務類型,設計合理mysql庫,表,架構。

  4. 定期進行災備恢復演練

  5. 誤刪除數據之後,恢復數據

簡單先從這幾個方向說說,每個問題再展開分析。


當然還會有一些人事上面的問題,例如為啥選我們的公司,你覺得你自己的優勢是什麽?你期望的薪資大概是多少?這些問題,就很簡單了。我們只要過了技術面試,這些都不是啥問題了!


今後還會逐漸展開某個問題的具體剖析,和詳細步驟處理方法!望大家繼續關註後期創作


本文出自 “DBA成長之路” 博客,請務必保留此出處http://sumongodb.blog.51cto.com/4979448/1948631

揭秘數據庫面試,讓你技術面試一次過