想進(jìn)大廠，mysql不會(huì)那可不行，來(lái)接受mysql面試挑戰(zhàn)吧，看看你能堅(jiān)持到哪里？

1. 能說(shuō)下myisam 和 innodb的區(qū)別嗎？

myisam引擎是5.1版本之前的默認(rèn)引擎，支持全文檢索、壓縮、空間函數(shù)等，但是不支持事務(wù)和行級(jí)鎖，所以一般用于有大量查詢少量插入的場(chǎng)景來(lái)使用，而且myisam不支持外鍵，并且索引和數(shù)據(jù)是分開存儲(chǔ)的。

innodb是基于聚簇索引建立的，和myisam相反它支持事務(wù)、外鍵，并且通過(guò)MVCC來(lái)支持高并發(fā)，索引和數(shù)據(jù)存儲(chǔ)在一起。

2. 說(shuō)下mysql的索引有哪些吧，聚簇和非聚簇索引又是什么？

索引按照數(shù)據(jù)結(jié)構(gòu)來(lái)說(shuō)主要包含B+樹和Hash索引。

假設(shè)我們有張表，結(jié)構(gòu)如下：

create table user（ id int（11） not null， age int（11） not null， primary key（id）， key（age））;

B+樹是左小右大的順序存儲(chǔ)結(jié)構(gòu)，節(jié)點(diǎn)只包含id索引列，而葉子節(jié)點(diǎn)包含索引列和數(shù)據(jù)，這種數(shù)據(jù)和索引在一起存儲(chǔ)的索引方式叫做聚簇索引，一張表只能有一個(gè)聚簇索引。假設(shè)沒(méi)有定義主鍵，InnoDB會(huì)選擇一個(gè)唯一的非空索引代替，如果沒(méi)有的話則會(huì)隱式定義一個(gè)主鍵作為聚簇索引。

這是主鍵聚簇索引存儲(chǔ)的結(jié)構(gòu)，那么非聚簇索引的結(jié)構(gòu)是什么樣子呢？非聚簇索引（二級(jí)索引）保存的是主鍵id值，這一點(diǎn)和myisam保存的是數(shù)據(jù)地址是不同的。

最終，我們一張圖看看InnoDB和Myisam聚簇和非聚簇索引的區(qū)別

3. 那你知道什么是覆蓋索引和回表嗎？

覆蓋索引指的是在一次查詢中，如果一個(gè)索引包含或者說(shuō)覆蓋所有需要查詢的字段的值，我們就稱之為覆蓋索引，而不再需要回表查詢。

而要確定一個(gè)查詢是否是覆蓋索引，我們只需要explain sql語(yǔ)句看Extra的結(jié)果是否是“Using index”即可。

以上面的user表來(lái)舉例，我們?cè)僭黾右粋€(gè)name字段，然后做一些查詢?cè)囋嚒?/p>

explain select * from user where age=1; //查詢的name無(wú)法從索引數(shù)據(jù)獲取explain select id，age from user where age=1; //可以直接從索引獲取

4. 鎖的類型有哪些呢

mysql鎖分為共享鎖和排他鎖，也叫做讀鎖和寫鎖。

讀鎖是共享的，可以通過(guò)lock in share mode實(shí)現(xiàn)，這時(shí)候只能讀不能寫。

寫鎖是排他的，它會(huì)阻塞其他的寫鎖和讀鎖。從顆粒度來(lái)區(qū)分，可以分為表鎖和行鎖兩種。

表鎖會(huì)鎖定整張表并且阻塞其他用戶對(duì)該表的所有讀寫操作，比如alter修改表結(jié)構(gòu)的時(shí)候會(huì)鎖表。

行鎖又可以分為樂(lè)觀鎖和悲觀鎖，悲觀鎖可以通過(guò)for update實(shí)現(xiàn)，樂(lè)觀鎖則通過(guò)版本號(hào)實(shí)現(xiàn)。

5. 你能說(shuō)下事務(wù)的基本特性和隔離級(jí)別嗎？

事務(wù)基本特性ACID分別是：

原子性指的是一個(gè)事務(wù)中的操作要么全部成功，要么全部失敗。

一致性指的是數(shù)據(jù)庫(kù)總是從一個(gè)一致性的狀態(tài)轉(zhuǎn)換到另外一個(gè)一致性的狀態(tài)。比如A轉(zhuǎn)賬給B100塊錢，假設(shè)中間sql執(zhí)行過(guò)程中系統(tǒng)崩潰A也不會(huì)損失100塊，因?yàn)槭聞?wù)沒(méi)有提交，修改也就不會(huì)保存到數(shù)據(jù)庫(kù)。

隔離性指的是一個(gè)事務(wù)的修改在最終提交前，對(duì)其他事務(wù)是不可見(jiàn)的。

持久性指的是一旦事務(wù)提交，所做的修改就會(huì)永久保存到數(shù)據(jù)庫(kù)中。

而隔離性有4個(gè)隔離級(jí)別，分別是：

read uncommit 讀未提交，可能會(huì)讀到其他事務(wù)未提交的數(shù)據(jù)，也叫做臟讀。

用戶本來(lái)應(yīng)該讀取到id=1的用戶age應(yīng)該是10，結(jié)果讀取到了其他事務(wù)還沒(méi)有提交的事務(wù)，結(jié)果讀取結(jié)果age=20，這就是臟讀。

read commit 讀已提交，兩次讀取結(jié)果不一致，叫做不可重復(fù)讀。

不可重復(fù)讀解決了臟讀的問(wèn)題，他只會(huì)讀取已經(jīng)提交的事務(wù)。

用戶開啟事務(wù)讀取id=1用戶，查詢到age=10，再次讀取發(fā)現(xiàn)結(jié)果=20，在同一個(gè)事務(wù)里同一個(gè)查詢讀取到不同的結(jié)果叫做不可重復(fù)讀。

repeatable read 可重復(fù)復(fù)讀，這是mysql的默認(rèn)級(jí)別，就是每次讀取結(jié)果都一樣，但是有可能產(chǎn)生幻讀。

serializable 串行，一般是不會(huì)使用的，他會(huì)給每一行讀取的數(shù)據(jù)加鎖，會(huì)導(dǎo)致大量超時(shí)和鎖競(jìng)爭(zhēng)的問(wèn)題。

6. 那ACID靠什么保證的呢？

A原子性由undo log日志保證，它記錄了需要回滾的日志信息，事務(wù)回滾時(shí)撤銷已經(jīng)執(zhí)行成功的sql

C一致性一般由代碼層面來(lái)保證

I隔離性由MVCC來(lái)保證

D持久性由內(nèi)存+redo log來(lái)保證，mysql修改數(shù)據(jù)同時(shí)在內(nèi)存和redo log記錄這次操作，事務(wù)提交的時(shí)候通過(guò)redo log刷盤，宕機(jī)的時(shí)候可以從redo log恢復(fù)

7. 那你說(shuō)說(shuō)什么是幻讀，什么是MVCC？

要說(shuō)幻讀，首先要了解MVCC，MVCC叫做多版本并發(fā)控制，實(shí)際上就是保存了數(shù)據(jù)在某個(gè)時(shí)間節(jié)點(diǎn)的快照。

我們每行數(shù)實(shí)際上隱藏了兩列，創(chuàng)建時(shí)間版本號(hào)，過(guò)期（刪除）時(shí)間版本號(hào)，每開始一個(gè)新的事務(wù)，版本號(hào)都會(huì)自動(dòng)遞增。

還是拿上面的user表舉例子，假設(shè)我們插入兩條數(shù)據(jù)，他們實(shí)際上應(yīng)該長(zhǎng)這樣。

idnamecreate_versiondelete_version

1張三1

2李四2

這時(shí)候假設(shè)小明去執(zhí)行查詢，此時(shí)current_version=3

select * from user where id《=3;

同時(shí)，小紅在這時(shí)候開啟事務(wù)去修改id=1的記錄，current_version=4

update user set name=‘張三三’ where id=1;

執(zhí)行成功后的結(jié)果是這樣的

idnamecreate_versiondelete_version

1張三1

2李四2

1張三三4

如果這時(shí)候還有小黑在刪除id=2的數(shù)據(jù)，current_version=5，執(zhí)行后結(jié)果是這樣的。

idnamecreate_versiondelete_version

1張三1

2李四25

1張三三4

由于MVCC的原理是查找創(chuàng)建版本小于或等于當(dāng)前事務(wù)版本，刪除版本為空或者大于當(dāng)前事務(wù)版本，小明的真實(shí)的查詢應(yīng)該是這樣

select * from user where id《=3 and create_version《=3 and （delete_version》3 or delete_version is null）;

所以小明最后查詢到的id=1的名字還是‘張三’，并且id=2的記錄也能查詢到。這樣做是為了保證事務(wù)讀取的數(shù)據(jù)是在事務(wù)開始前就已經(jīng)存在的，要么是事務(wù)自己插入或者修改的。

明白MVCC原理，我們來(lái)說(shuō)什么是幻讀就簡(jiǎn)單多了。舉一個(gè)常見(jiàn)的場(chǎng)景，用戶注冊(cè)時(shí)，我們先查詢用戶名是否存在，不存在就插入，假定用戶名是唯一索引。

小明開啟事務(wù)current_version=6查詢名字為‘王五’的記錄，發(fā)現(xiàn)不存在。

小紅開啟事務(wù)current_version=7插入一條數(shù)據(jù)，結(jié)果是這樣：

idNamecreate_versiondelete_version

1張三1

2李四2

3王五7

小明執(zhí)行插入名字‘王五’的記錄，發(fā)現(xiàn)唯一索引沖突，無(wú)法插入，這就是幻讀。

8. 那你知道什么是間隙鎖嗎？

間隙鎖是可重復(fù)讀級(jí)別下才會(huì)有的鎖，結(jié)合MVCC和間隙鎖可以解決幻讀的問(wèn)題。我們還是以u(píng)ser舉例，假設(shè)現(xiàn)在user表有幾條記錄

idAge

110

220

330

當(dāng)我們執(zhí)行：

begin;select * from user where age=20 for update;begin;insert into user（age） values（10）; #成功insert into user（age） values（11）; #失敗insert into user（age） values（20）; #失敗insert into user（age） values（21）; #失敗insert into user（age） values（30）; #失敗

只有10可以插入成功，那么因?yàn)楸淼拈g隙mysql自動(dòng)幫我們生成了區(qū)間（左開右閉）

（negative infinity，10］，（10，20］，（20，30］，（30，positive infinity）

由于20存在記錄，所以（10，20］，（20，30］區(qū)間都被鎖定了無(wú)法插入、刪除。

如果查詢21呢？就會(huì)根據(jù)21定位到（20，30）的區(qū)間（都是開區(qū)間）。

需要注意的是唯一索引是不會(huì)有間隙索引的。

9. 你們數(shù)據(jù)量級(jí)多大？分庫(kù)分表怎么做的？

首先分庫(kù)分表分為垂直和水平兩個(gè)方式，一般來(lái)說(shuō)我們拆分的順序是先垂直后水平。

垂直分庫(kù)

基于現(xiàn)在微服務(wù)拆分來(lái)說(shuō)，都是已經(jīng)做到了垂直分庫(kù)了

垂直分表

如果表字段比較多，將不常用的、數(shù)據(jù)較大的等等做拆分

水平分表

首先根據(jù)業(yè)務(wù)場(chǎng)景來(lái)決定使用什么字段作為分表字段（sharding_key），比如我們現(xiàn)在日訂單1000萬(wàn)，我們大部分的場(chǎng)景來(lái)源于C端，我們可以用user_id作為sharding_key，數(shù)據(jù)查詢支持到最近3個(gè)月的訂單，超過(guò)3個(gè)月的做歸檔處理，那么3個(gè)月的數(shù)據(jù)量就是9億，可以分1024張表，那么每張表的數(shù)據(jù)大概就在100萬(wàn)左右。

比如用戶id為100，那我們都經(jīng)過(guò)hash（100），然后對(duì)1024取模，就可以落到對(duì)應(yīng)的表上了。

10. 那分表后的ID怎么保證唯一性的呢？

因?yàn)槲覀冎麈I默認(rèn)都是自增的，那么分表之后的主鍵在不同表就肯定會(huì)有沖突了。有幾個(gè)辦法考慮：

設(shè)定步長(zhǎng)，比如1-1024張表我們分別設(shè)定1-1024的基礎(chǔ)步長(zhǎng)，這樣主鍵落到不同的表就不會(huì)沖突了。

分布式ID，自己實(shí)現(xiàn)一套分布式ID生成算法或者使用開源的比如雪花算法這種

分表后不使用主鍵作為查詢依據(jù)，而是每張表單獨(dú)新增一個(gè)字段作為唯一主鍵使用，比如訂單表訂單號(hào)是唯一的，不管最終落在哪張表都基于訂單號(hào)作為查詢依據(jù)，更新也一樣。

11. 分表后非sharding_key的查詢?cè)趺刺幚砟兀?/p>

可以做一個(gè)mapping表，比如這時(shí)候商家要查詢訂單列表怎么辦呢？不帶user_id查詢的話你總不能掃全表吧？所以我們可以做一個(gè)映射關(guān)系表，保存商家和用戶的關(guān)系，查詢的時(shí)候先通過(guò)商家查詢到用戶列表，再通過(guò)user_id去查詢。

打?qū)挶?，一般而言，商戶端?duì)數(shù)據(jù)實(shí)時(shí)性要求并不是很高，比如查詢訂單列表，可以把訂單表同步到離線（實(shí)時(shí)）數(shù)倉(cāng)，再基于數(shù)倉(cāng)去做成一張寬表，再基于其他如es提供查詢服務(wù)。

數(shù)據(jù)量不是很大的話，比如后臺(tái)的一些查詢之類的，也可以通過(guò)多線程掃表，然后再聚合結(jié)果的方式來(lái)做?；蛘弋惒降男问揭彩强梢缘摹?/p>

List》》 taskList = Lists.newArrayList（）;for （int shardingIndex = 0; shardingIndex 《 1024; shardingIndex++） { taskList.add（（） -》 （userMapper.getProcessingAccountList（shardingIndex）））;}List list = null;try { list = taskExecutor.executeTask（taskList）;} catch （Exception e） { //do something}public class TaskExecutor { public List executeTask（Collection》 tasks） throws Exception { List result = Lists.newArrayList（）; List》 futures = ExecutorUtil.invokeAll（tasks）; for （Future future ： futures） { result.add（future.get（））; } return result; }}

12. 說(shuō)說(shuō)mysql主從同步怎么做的吧？

首先先了解mysql主從同步的原理

master提交完事務(wù)后，寫入binlog

slave連接到master，獲取binlog

master創(chuàng)建dump線程，推送binglog到slave

slave啟動(dòng)一個(gè)IO線程讀取同步過(guò)來(lái)的master的binlog，記錄到relay log中繼日志中

slave再開啟一個(gè)sql線程讀取relay log事件并在slave執(zhí)行，完成同步

slave記錄自己的binglog

由于mysql默認(rèn)的復(fù)制方式是異步的，主庫(kù)把日志發(fā)送給從庫(kù)后不關(guān)心從庫(kù)是否已經(jīng)處理，這樣會(huì)產(chǎn)生一個(gè)問(wèn)題就是假設(shè)主庫(kù)掛了，從庫(kù)處理失敗了，這時(shí)候從庫(kù)升為主庫(kù)后，日志就丟失了。由此產(chǎn)生兩個(gè)概念。

全同步復(fù)制

主庫(kù)寫入binlog后強(qiáng)制同步日志到從庫(kù)，所有的從庫(kù)都執(zhí)行完成后才返回給客戶端，但是很顯然這個(gè)方式的話性能會(huì)受到嚴(yán)重影響。

半同步復(fù)制

和全同步不同的是，半同步復(fù)制的邏輯是這樣，從庫(kù)寫入日志成功后返回ACK確認(rèn)給主庫(kù)，主庫(kù)收到至少一個(gè)從庫(kù)的確認(rèn)就認(rèn)為寫操作完成。

13. 那主從的延遲怎么解決呢？

這個(gè)問(wèn)題貌似真的是個(gè)無(wú)解的問(wèn)題，只能是說(shuō)自己來(lái)判斷了，需要走主庫(kù)的強(qiáng)制走主庫(kù)查詢。