您好,登錄后才能下訂單哦!
MySQL 事務(wù),是我們?nèi)ッ嬖囍懈呒?jí)開(kāi)發(fā)經(jīng)常會(huì)被問(wèn)到的問(wèn)題,很多人雖然經(jīng)常使用 MySQL,SQL 語(yǔ)句也寫得很溜,但是面試的時(shí)候,被問(wèn)到這些問(wèn)題,總是不知從何說(shuō)起。下面我們先來(lái)了解一下什么是 MySQL事務(wù),再給大家分享10道面試必備的MySQL題。
MySQL事務(wù)是數(shù)據(jù)處理的最小操作單元,是一組不可在分割的操作集合,這個(gè)操作單元里的一系列操作要么都成功,要么都失敗。
1、MySQL主從復(fù)制的原理。
(1)、主庫(kù)必須開(kāi)啟二進(jìn)制日志
(2)、當(dāng)有增刪改的語(yǔ)句時(shí),會(huì)記錄到主庫(kù)的binlog中
(3)、主庫(kù)通過(guò)IO線程把binlog里面的內(nèi)容傳給從庫(kù)的relay binlog(中繼日志)(這是msyql復(fù)制是異步復(fù)制的原因)
(4)、從庫(kù)的sql線程負(fù)責(zé)讀取它的relay log里的信息并應(yīng)用到數(shù)據(jù)庫(kù)中
2、Seconds_Behind_Master的原理。
表示sql線程和io線程之間的時(shí)間差
具體的計(jì)算:從庫(kù)服務(wù)器當(dāng)前的時(shí)間戳與二進(jìn)制日志中的事件的時(shí)間戳相對(duì)比得到的,所以只有在執(zhí)行事件時(shí)才能報(bào)告延遲。
不足:
一些錯(cuò)誤(例如主備的max_allowed_packet不匹配,或者網(wǎng)絡(luò)不穩(wěn)定)可能中斷復(fù)制,由于主從復(fù)制是異步操作,Seconds_Behind_Master可能顯示為0
3、主從延遲的主要原因有哪些?
(1)、慢SQL語(yǔ)句過(guò)多
(2)、從庫(kù)的硬件比主庫(kù)差
(3)、同一個(gè)主庫(kù)下有過(guò)多的從庫(kù)
(4)、網(wǎng)絡(luò)延遲
(5)、表分區(qū)過(guò)多
(還有一些原因,歡迎補(bǔ)充)
4、MySQL常見(jiàn)存儲(chǔ)引擎及各自特點(diǎn)。
(1)、InnoDB
支持事務(wù)、行級(jí)鎖、支持外鍵約束,主要面向OLTP的應(yīng)用,使用next-key locking 的策略來(lái)避免幻讀現(xiàn)象的產(chǎn)生.
(2)、MyISAM
不支持事務(wù)、表鎖設(shè)計(jì)、支持全文索引、讀寫互相阻塞、不支持外鍵約束;主要面向OLAP應(yīng)用場(chǎng)景;緩存池只緩存索引文件,不緩存數(shù)據(jù)文件
(3)、Memory
將所有數(shù)據(jù)保存在RAM中,在需要快速查找引用和其他類似數(shù)據(jù)的環(huán)境下,可提供極快的訪問(wèn)。如果數(shù)據(jù)庫(kù)重啟或者奔潰,數(shù)據(jù)都將丟失。
(4)、TokuDB
支持事務(wù)、高壓縮、告訴讀寫、基于稀疏樹(shù)索引設(shè)計(jì);支持大多數(shù)在線修改索引、添加字段。
(5)、Inforbright/infinidb
列式存儲(chǔ)、高壓縮、單列查詢快
5、innodb_flush_log_at_trx_commit參數(shù)0、1和2分別代表什么?
innodb_flush_log_at_trx_commit參數(shù)可以控制將redo log buffer中的更新記錄寫入到日志文件以及日志文件刷新到磁盤的操作時(shí)機(jī)。
0
每秒一次觸發(fā)log buffer寫入log file中,并且log file刷新到磁盤。
(由于進(jìn)程調(diào)度問(wèn)題,不能保證每秒100%刷新;如果mysql進(jìn)程崩潰,可能會(huì)丟失1s的事務(wù);效率最高,但最不安全)
1
每次事務(wù)提交觸發(fā)log buffer寫入log file中,并且log file刷新到磁盤。
2
每次事務(wù)提交,log buffer寫入log file中;每秒log file刷新到磁盤。
(如果操作系統(tǒng)崩潰或者停電,可能會(huì)丟失1s的事務(wù))
6、Mysql中varchar和char的區(qū)別
CHAR列的長(zhǎng)度固定為創(chuàng)建表時(shí)聲明的長(zhǎng)度,范圍(0-255)
VARCHAR列的長(zhǎng)度不固定,范圍(0-65535)
7、varchar(50)中的50代表的含義、int(20)中20的含義。
varchar(50)中的50代表最多能存放50個(gè)字符
int(20)中20的含義表示顯示寬度,跟著zerofill一起才有意義
8、MySQL binlog的幾種日志錄入格式的涵義、適用場(chǎng)景和在復(fù)制中的優(yōu)劣。
(1)、statement level模式
每一條會(huì)修改數(shù)據(jù)的sql都會(huì)記錄到master的binlog中,slave在復(fù)制時(shí)sql進(jìn)程會(huì)解析成和原來(lái)master端執(zhí)行過(guò)的相同的sql再次執(zhí)行。
適用場(chǎng)景:對(duì)主從數(shù)據(jù)一致性要求不太高,并且很少用到函數(shù)、存儲(chǔ)過(guò)程、觸發(fā)器等場(chǎng)景
優(yōu)點(diǎn):bin-log日志量少
缺點(diǎn):部分新功能(函數(shù)、存儲(chǔ)過(guò)程、觸發(fā)器)同步會(huì)有障礙,比如now()
(2)、row level模式
日志中會(huì)記錄成每一行數(shù)據(jù)被修改的形式,然后再slave端再對(duì)相同的數(shù)據(jù)進(jìn)行修改
適用場(chǎng)景:對(duì)主從數(shù)據(jù)一致性要求比較高的場(chǎng)景。
優(yōu)點(diǎn):記錄的詳細(xì)
缺點(diǎn):binlog日志量過(guò)大
(3)、mixed模式
MySQL默認(rèn)采用statement格式進(jìn)行二進(jìn)制日志文件的記錄,但是在一些情況下會(huì)使用row格式,可能的情況有:
1)、表的存儲(chǔ)引擎為NDB,此時(shí)對(duì)表的DML操作都會(huì)以ROW格式記錄
2)、使用了UUID(),USER(),CURRENT_USER(),FOUND_ROWS(),ROW_count()等不確定函數(shù)時(shí)
3)、使用了insert delay語(yǔ)句
4)、使用了用戶定義函數(shù)(UDF)
5)、使用了臨時(shí)表
適用場(chǎng)景:對(duì)主從數(shù)據(jù)一致性要求不太高,可能會(huì)用到函數(shù)、存儲(chǔ)過(guò)程、觸發(fā)器等場(chǎng)景
優(yōu)缺點(diǎn)介于statement和row模式之間
9、重做日志和二進(jìn)制日志的區(qū)別(至少三點(diǎn))
(1)涉及存儲(chǔ)引擎不一樣:
binlog記錄的是所有存儲(chǔ)引擎的操作記錄
redo log只記錄innodb存儲(chǔ)引擎的日志
(2)記錄內(nèi)容不一樣:
binlog記錄的是關(guān)于一個(gè)事務(wù)的具體操作內(nèi)容。為邏輯日志
而redo log記錄的是每個(gè)頁(yè)更改的物理情況
(3)寫的時(shí)間不一樣:
binlog文件僅在事務(wù)提交前進(jìn)行提交,即只寫磁盤一次
而在事務(wù)進(jìn)行過(guò)程中,卻不斷有重做日志條目被寫入到重做日志文件中。
10、Explain執(zhí)行計(jì)劃中要關(guān)注哪些要素?
(1)、type:本次查詢表聯(lián)接類型,從這里可以看到本次查詢大概的效率
(2)、key:最終選擇的索引,如果沒(méi)有索引的話,本次查詢效率通常很差
(3)、key_len:本次查詢用于結(jié)果過(guò)濾的索引實(shí)際長(zhǎng)度
(4)、rows:預(yù)計(jì)需要掃描的記錄數(shù),預(yù)計(jì)需要掃描的記錄數(shù)越小越好
(5)、extra:額外附加信息,主要確認(rèn)是否出現(xiàn) Using filesort、Using temporary 類似情況
以上10道MySQL面試題,只是眾多MySQL面試題中的部分,個(gè)人認(rèn)為是比較典型的,出現(xiàn)頻率也比較高的試題,希望對(duì)你們有幫助!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。