一、SQL語句執(zhí)行流程

MySQL大體上可分為Server層和存儲引擎層兩部分蜂桶。

Server層：

• 連接器：TCP握手后服務(wù)器來驗證登陸用戶身份儡毕，A用戶創(chuàng)建連接后，管理員對A用戶權(quán)限修改了也不會影響到已經(jīng)創(chuàng)建的鏈接權(quán)限扑媚，必須重新登陸腰湾。
• 查詢緩存：查詢后的結(jié)果存儲位置，MySQL8.0版本以后已經(jīng)取消钦购，因為查詢緩存失效太頻繁檐盟，得不償失。
• 分析器：根據(jù)語法規(guī)則押桃，判斷你輸入的這個SQL語句是否滿足MySQL語法葵萎。
• 優(yōu)化器：多種執(zhí)行策略可實現(xiàn)目標(biāo)，系統(tǒng)自動選擇最優(yōu)進行執(zhí)行唱凯。
• 執(zhí)行器：判斷是否有權(quán)限羡忘，將最終任務(wù)提交到存儲引擎。

存儲引擎層

負(fù)責(zé)數(shù)據(jù)的存儲和提取磕昼。其架構(gòu)模式是插件式的卷雕，支持InnoDB、MyISAM票从、Memory等多個存儲引擎÷瘢現(xiàn)在最常用的存儲引擎是InnoDB，它從MySQL 5.5.5版本開始成為了默認(rèn)存儲引擎(經(jīng)常用的也是這個)峰鄙。

SQL執(zhí)行順序

二浸间、BinLog、RedoLog吟榴、UndoLog

BinLog

BinLog是記錄所有數(shù)據(jù)庫表結(jié)構(gòu)變更（例如create魁蒜、alter table）以及表數(shù)據(jù)修改(insert、update吩翻、delete)的二進制日志兜看，主從數(shù)據(jù)庫同步用到的都是BinLog文件。BinLog日志文件有三種模式狭瞎。

STATEMENT 模式

內(nèi)容：binlog 只會記錄可能引起數(shù)據(jù)變更的 sql 語句

優(yōu)勢：該模式下细移，因為沒有記錄實際的數(shù)據(jù)，所以日志量和 IO 都消耗很低熊锭，性能是最優(yōu)的

劣勢：但有些操作并不是確定的葫哗，比如 uuid() 函數(shù)會隨機產(chǎn)生唯一標(biāo)識缔刹，當(dāng)依賴 binlog 回放時，該操作生成的數(shù)據(jù)與原數(shù)據(jù)必然是不同的劣针，此時可能造成無法預(yù)料的后果校镐。

ROW 模式

內(nèi)容：在該模式下，binlog 會記錄每次操作的源數(shù)據(jù)與修改后的目標(biāo)數(shù)據(jù)捺典，StreamSets就要求該模式鸟廓。

優(yōu)勢：可以絕對精準(zhǔn)的還原，從而保證了數(shù)據(jù)的安全與可靠襟己，并且復(fù)制和數(shù)據(jù)恢復(fù)過程可以是并發(fā)進行的

劣勢：缺點在于 binlog 體積會非常大引谜，同時，對于修改記錄多擎浴、字段長度大的操作來說员咽，記錄時性能消耗會很嚴(yán)重。閱讀的時候也需要特殊指令來進行讀取數(shù)據(jù)贮预。

MIXED 模式

內(nèi)容：是對上述STATEMENT 跟 ROW 兩種模式的混合使用贝室。

細(xì)節(jié)：對于絕大部分操作，都使用 STATEMENT 來進行 binlog 的記錄仿吞，只有以下操作使用 ROW 來實現(xiàn)：表的存儲引擎為 NDB滑频，使用了uuid() 等不確定函數(shù)，使用了 insert delay 語句唤冈，使用了臨時表

主從同步流程：

1峡迷、主節(jié)點必須啟用二進制日志，記錄任何修改了數(shù)據(jù)庫數(shù)據(jù)的事件你虹。

2绘搞、從節(jié)點開啟一個線程（I/O Thread)把自己扮演成 mysql 的客戶端，通過 mysql 協(xié)議傅物，請求主節(jié)點的二進制日志文件中的事件 夯辖。

3、主節(jié)點啟動一個線程（dump Thread）挟伙，檢查自己二進制日志中的事件，跟對方請求的位置對比模孩，如果不帶請求位置參數(shù)尖阔，則主節(jié)點就會從第一個日志文件中的第一個事件一個一個發(fā)送給從節(jié)點。

4榨咐、從節(jié)點接收到主節(jié)點發(fā)送過來的數(shù)據(jù)把它放置到中繼日志（Relay log）文件中介却。并記錄該次請求到主節(jié)點的具體哪一個二進制日志文件內(nèi)部的哪一個位置（主節(jié)點中的二進制文件會有多個）。

5块茁、從節(jié)點啟動另外一個線程（sql Thread ）齿坷，把 Relay log 中的事件讀取出來桂肌，并在本地再執(zhí)行一次。

mysql默認(rèn)的復(fù)制方式是異步的永淌，并且復(fù)制的時候是有并行復(fù)制能力的崎场。主庫把日志發(fā)送給從庫后不管了，這樣會產(chǎn)生一個問題就是假設(shè)主庫掛了遂蛀，從庫處理失敗了谭跨，這時候從庫升為主庫后，日志就丟失了李滴。由此產(chǎn)生兩個概念螃宙。

1.全同步復(fù)制

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

2.半同步復(fù)制

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

還可以延伸到由于主從配置不一樣、主庫大事務(wù)周瞎、從庫壓力過大苗缩、網(wǎng)絡(luò)震蕩等造成主備延遲，如何避免這個問題声诸？主備切換的時候用可靠性優(yōu)先原則還是可用性優(yōu)先原則酱讶？如何判斷主庫Crash了？互為主備情況下如何避免主備循環(huán)復(fù)制彼乌？被刪庫跑路了如何正確恢復(fù)泻肯？(⊙o⊙)… 感覺越來越扯到DBA的活兒上去了。

RedoLog

可以先通過下面demo理解：

飯點記賬可以把賬單寫在賬本上也可以寫在粉板上慰照。有人賒賬或者還賬的話灶挟，一般有兩種做法：

1、直接把賬本翻出來毒租，把這次賒的賬加上去或者扣除掉稚铣。

2、先在粉板上記下這次的賬墅垮，等打烊以后再把賬本翻出來核算惕医。

生意忙時選后者，因為前者太麻煩了算色。得在密密麻麻的記錄中找到這個人的賒賬總額信息抬伺，找到之后再拿出算盤計算，最后再將結(jié)果寫回到賬本上灾梦。

同樣在MySQL中如果每一次的更新操作都需要寫進磁盤峡钓，然后磁盤也要找到對應(yīng)的那條記錄妓笙，然后再更新，整個過程IO成本能岩、查找成本都很高寞宫。而粉板和賬本配合的整個過程就是MySQL用到的是Write-Ahead Logging 技術(shù)，它的關(guān)鍵點就是先寫日志捧灰，再寫磁盤淆九。此時賬本 = BinLog，粉板 = RedoLog毛俏。

1炭庙、 記錄更新時，InnoDB引擎就會先把記錄寫到RedoLog（粉板）里面煌寇，并更新內(nèi)存焕蹄。同時，InnoDB引擎會在空閑時將這個操作記錄更新到磁盤里面阀溶。

2腻脏、 如果更新太多RedoLog處理不了的時候，需先將RedoLog部分?jǐn)?shù)據(jù)寫到磁盤银锻，然后擦除RedoLog部分?jǐn)?shù)據(jù)永品。RedoLog類似轉(zhuǎn)盤。

RedoLog有write pos 跟checkpoint

write pos ：是當(dāng)前記錄的位置击纬，一邊寫一邊后移鼎姐，寫到第3號文件末尾后就回到0號文件開頭。

check point：是當(dāng)前要擦除的位置更振，也是往后推移并且循環(huán)的炕桨，擦除記錄前要把記錄更新到數(shù)據(jù)文件。

write pos和check point之間的是粉板上還空著的部分肯腕，可以用來記錄新的操作献宫。如果write pos追上checkpoint，表示粉板滿了实撒，這時候不能再執(zhí)行新的更新姊途，得停下來先擦掉一些記錄，把checkpoint推進一下知态。

有了redo log捷兰，InnoDB就可以保證即使數(shù)據(jù)庫發(fā)生異常重啟，之前提交的記錄都不會丟失肴甸，這個能力稱為crash-safe寂殉。

redolog兩階段提交：為了讓binlog跟redolog兩份日志之間的邏輯一致囚巴。提交流程大致如下：

1 prepare階段 --> 2 寫binlog --> 3 commit

1. 當(dāng)在2之前崩潰時原在，重啟恢復(fù)后發(fā)現(xiàn)沒有commit友扰，回滾。備份恢復(fù)：沒有binlog 庶柿。一致
2. 當(dāng)在3之前崩潰時村怪，重啟恢復(fù)發(fā)現(xiàn)雖沒有commit，但滿足prepare和binlog完整浮庐，所以重啟后會自動commit甚负。備份：有binlog. 一致

binlog跟redolog區(qū)別：

1. redo log是InnoDB引擎特有的；binlog是MySQL的Server層實現(xiàn)的审残，所有引擎都可以使用梭域。
2. redo log是物理日志，記錄的是在某個數(shù)據(jù)頁上做了什么修改搅轿；binlog是邏輯日志病涨，記錄的是這個語句的原始邏輯，比如給ID=2這一行的c字段加1璧坟。
3. redo log是循環(huán)寫的既穆，空間固定會用完；binlog是可以追加寫入的雀鹃。追加寫是指binlog文件寫到一定大小后會切換到下一個幻工，并不會覆蓋以前的日志。

UndoLog

UndoLog 一般是邏輯日志黎茎，主要分為兩種：

1. insert undo log

代表事務(wù)在insert新記錄時產(chǎn)生的undo log, 只在事務(wù)回滾時需要囊颅，并且在事務(wù)提交后可以被立即丟棄

2. update undo log

事務(wù)在進行update或delete時產(chǎn)生的undo log; 不僅在事務(wù)回滾時需要，在快照讀時也需要工三；所以不能隨便刪除迁酸，只有在快速讀或事務(wù)回滾不涉及該日志時，對應(yīng)的日志才會被purge線程統(tǒng)一清除

三俭正、MySQL中的索引

索引的常見模型有哈希表奸鬓、有序數(shù)組和搜索樹。

哈希表：一種以KV存儲數(shù)據(jù)的結(jié)構(gòu)掸读，只適合等值查詢串远，不適合范圍查詢。

有序數(shù)組：只適用于靜態(tài)存儲引擎儿惫，涉及到插入的時候比較麻煩澡罚。可以參考Java中的ArrayList肾请。

搜索樹：按照數(shù)據(jù)結(jié)構(gòu)中的二叉樹來存儲數(shù)據(jù)留搔，不過此時是N叉樹(B+樹)。廣泛應(yīng)用在存儲引擎層中铛铁。

B+樹比B樹優(yōu)勢在于：

1. B+ 樹非葉子節(jié)點存儲的只是索引隔显，可以存儲的更多却妨。B+樹比B樹更加矮胖，IO次數(shù)更少括眠。
2. B+ 樹葉子節(jié)點前后管理彪标，更加方便范圍查詢。同時結(jié)果都在葉子節(jié)點掷豺，查詢效率穩(wěn)定捞烟。
3. B+樹中更有利于對數(shù)據(jù)掃描，可以避免B樹的回溯掃描当船。

索引的優(yōu)點：

1题画、唯一索引可以保證每一行數(shù)據(jù)的唯一性

2、提高查詢速度

3德频、加速表與表的連接

4婴程、顯著的減少查詢中分組和排序的時間

5、通過使用索引抱婉，可以在查詢的過程中档叔，使用優(yōu)化隱藏器，提高系統(tǒng)的性能蒸绩。

索引的缺點：

1衙四、創(chuàng)建跟維護都需要耗時

2、創(chuàng)建索引時患亿，需要對表加鎖传蹈，在鎖表的同時，可能會影響到其他的數(shù)據(jù)操作

3步藕、 索引需要磁盤的空間進行存儲惦界，磁盤占用也很快。

4咙冗、當(dāng)對表中的數(shù)據(jù)進行CRUD的時沾歪，也會觸發(fā)索引的維護，而維護索引需要時間雾消，可能會降低數(shù)據(jù)操作性能

索引設(shè)計的原則不應(yīng)該：

1灾搏、索引不是越多越好。索引太多立润，維護索引需要時間跟空間狂窑。

2、 頻繁更新的數(shù)據(jù)桑腮，不宜建索引泉哈。

3、數(shù)據(jù)量小的表沒必要建立索引。

應(yīng)該：

1丛晦、重復(fù)率小的列建議生成索引巨缘。因為重復(fù)數(shù)據(jù)少，索引樹查詢更有效率采呐，等價基數(shù)越大越好。

2搁骑、數(shù)據(jù)具有唯一性斧吐，建議生成唯一性索引。在數(shù)據(jù)庫的層面仲器，保證數(shù)據(jù)正確性

3参淹、頻繁group by截珍、order by的列建議生成索引。可以大幅提高分組和排序效率

4梢薪、經(jīng)常用于查詢條件的字段建議生成索引。通過索引查詢友瘤，速度更快

索引失效的場景

1挤土、模糊搜索：左模糊或全模糊都會導(dǎo)致索引失效，比如'%a'和'%a%'肢扯。但是右模糊是可以利用索引的妒茬，比如'a%' 。

2蔚晨、隱式類型轉(zhuǎn)換：比如select * from t where name = xxx , name是字符串類型乍钻，但是沒有加引號，所以是由MySQL隱式轉(zhuǎn)換的铭腕，所以會讓索引失效 3银择、當(dāng)語句中帶有or的時候：比如select * from t where name=‘sw’ or age=14

4、不符合聯(lián)合索引的最左前綴匹配：(A,B,C)的聯(lián)合索引累舷，你只where了C或B或只有B,C

關(guān)于索引的知識點：

主鍵索引：主鍵索引的葉子節(jié)點存的是整行數(shù)據(jù)信息浩考。在InnoDB里，主鍵索引也被稱為聚簇索引（clustered index）被盈。主鍵自增是無法保證完全自增的哦怀挠，遇到唯一鍵沖突、事務(wù)回滾等都可能導(dǎo)致不連續(xù)害捕。

唯一索引：以唯一列生成的索引绿淋，該列不允許有重復(fù)值，但允許有空值(NULL)

普通索引跟唯一索引查詢性能：InnoDB的數(shù)據(jù)是按數(shù)據(jù)頁為單位來讀寫的尝盼，默認(rèn)每頁16KB吞滞，因此這兩種索引查詢數(shù)據(jù)性能差別微乎其微。

change buffer：普通索引用在更新過程的加速，更新的字段如果在緩存中裁赠，如果是普通索引則直接更新即可殿漠。如果是唯一索引需要將所有數(shù)據(jù)讀入內(nèi)存來確保不違背唯一性，所以盡量用普通索引佩捞。

非主鍵索引：非主鍵索引的葉子節(jié)點內(nèi)容是主鍵的值绞幌。在InnoDB里，非主鍵索引也被稱為二級索引（secondary index）

回表：先通過數(shù)據(jù)庫索引掃描出數(shù)據(jù)所在的行一忱，再通過行主鍵id取出索引中未提供的數(shù)據(jù)莲蜘，即基于非主鍵索引的查詢需要多掃描一棵索引樹。

覆蓋索引：如果一個索引包含（或者說覆蓋）所有需要查詢的字段的值帘营，我們就稱之為覆蓋索引票渠。

聯(lián)合索引：相對單列索引，組合索引是用多個列組合構(gòu)建的索引芬迄，一次性最多聯(lián)合16個问顷。

最左前綴原則：對多個字段同時建立的組合索引(有順序，ABC禀梳，ACB是完全不同的兩種聯(lián)合索引) 以聯(lián)合索引(a,b,c)為例杜窄，建立這樣的索引相當(dāng)于建立了索引a、ab算途、abc三個索引羞芍。另外組合索引實際還是一個索引，并非真的創(chuàng)建了多個索引郊艘，只是產(chǎn)生的效果等價于產(chǎn)生多個索引荷科。

索引下推：MySQL 5.6引入了索引下推優(yōu)化，可以在索引遍歷過程中纱注，對索引中包含的字段先做判斷畏浆，過濾掉不符合條件的記錄，減少回表字?jǐn)?shù)狞贱。

索引維護：B+樹為了維護索引有序性涉及到頁分裂跟頁合并刻获。增刪數(shù)據(jù)時需考慮頁空間利用率。

自增主鍵：一般會建立與業(yè)務(wù)無關(guān)的自增主鍵瞎嬉，不會觸發(fā)葉子節(jié)點分裂蝎毡。

延遲關(guān)聯(lián)：通過使用覆蓋索引查詢返回需要的主鍵，再根據(jù)主鍵關(guān)聯(lián)原表獲得需要的數(shù)據(jù)氧枣。

InnoDB存儲: * .frm文件是一份定義文件沐兵，也就是定義數(shù)據(jù)庫表是一張怎么樣的表。*.ibd文件則是該表的索引便监，數(shù)據(jù)存儲文件扎谎，既該表的所有索引樹碳想，所有行記錄數(shù)據(jù)都存儲在該文件中。

MyISAM存儲：* .frm文件是一份定義文件毁靶，也就是定義數(shù)據(jù)庫表是一張怎么樣的表胧奔。* .MYD文件是MyISAM存儲引擎表的所有行數(shù)據(jù)的文件。* .MYI文件存放的是MyISAM存儲引擎表的索引相關(guān)數(shù)據(jù)的文件预吆。MyISAM引擎下龙填，表數(shù)據(jù)和表索引數(shù)據(jù)是分開存儲的。

MyISAM查詢：在MyISAM下拐叉，主鍵索引和輔助鍵索引都屬于非聚簇索引岩遗。查詢不管是走主鍵索引，還是非主鍵索引巷嚣，在葉子結(jié)點得到的都是目的數(shù)據(jù)的地址，還需要通過該地址钳吟，才能在數(shù)據(jù)文件中找到目的數(shù)據(jù)廷粒。

PS：InnoDB支持聚簇索引，MyISAM不支持聚簇索引

四红且、SQL事務(wù)隔離級別

ACID的四個特性

1. 原子性（Atomicity）：把多個操作放到一個事務(wù)中坝茎，保證這些操作要么都成功，要么都不成功
2. 一致性（Consistency）：理解成一串對數(shù)據(jù)進行操作的程序執(zhí)行下來暇番，不會對數(shù)據(jù)產(chǎn)生不好的影響嗤放，比如憑空產(chǎn)生，或消失
3. 隔離性（Isolation壁酬，又稱獨立性）：隔離性的意思就是多個事務(wù)之間互相不干擾次酌，即使是并發(fā)事務(wù)的情況下，他們只是兩個并發(fā)執(zhí)行沒有交集舆乔，互不影響的東西岳服；當(dāng)然實現(xiàn)中，也不一定需要這么完整隔離性希俩，即不一定需要這么的互不干擾吊宋，有時候還是允許有部分干擾的。所以MySQL可以支持4種事務(wù)隔離性
4. 持久性（Durability）：當(dāng)某個操作操作完畢了颜武，那么結(jié)果就是這樣了璃搜，并且這個操作會持久化到日志記錄中

PS：ACID中C與CAP定理中C的區(qū)別

ACID的C著重強調(diào)單數(shù)據(jù)庫事務(wù)操作時，要保證數(shù)據(jù)的完整和正確性鳞上，數(shù)據(jù)不會憑空消失跟增加这吻。CAP
理論中的C指的是對一個數(shù)據(jù)多個備份的讀寫一致性

事務(wù)操作可能會出現(xiàn)的數(shù)據(jù)問題

1、臟讀(dirty read)：B事務(wù)更改數(shù)據(jù)還未提交篙议，A事務(wù)已經(jīng)看到并且用了橘原。B事務(wù)如果回滾，則A事務(wù)做錯了

2、 不可重復(fù)讀(non-repeatable read)：不可重復(fù)讀的重點是修改: 同樣的條件, 你讀取過的數(shù)據(jù), 再次讀取出來發(fā)現(xiàn)值不一樣了趾断，只需要鎖住滿足條件的記錄

3拒名、 幻讀(phantom read)：事務(wù)A先修改了某個表的所有紀(jì)錄的狀態(tài)字段為已處理，未提交芋酌；事務(wù)B也在此時新增了一條未處理的記錄增显，并提交了；事務(wù)A隨后查詢記錄脐帝，卻發(fā)現(xiàn)有一條記錄是未處理的造成幻讀現(xiàn)象同云，幻讀僅專指新插入的行《赂梗幻讀會造成語義上的問題跟數(shù)據(jù)一致性問題炸站。

4、 在可重復(fù)讀RR隔離級別下疚顷，普通查詢是快照讀旱易，是不會看到別的事務(wù)插入的數(shù)據(jù)的。因此腿堤，幻讀在當(dāng)前讀下才會出現(xiàn)阀坏。要用間隙鎖解決此問題。

在說隔離級別之前笆檀，你首先要知道忌堂，你隔離得越嚴(yán)實，效率就會越低酗洒。因此很多時候士修，我們都要在二者之間尋找一個平衡點。SQL標(biāo)準(zhǔn)的事務(wù)隔離級別由低到高如下：

上圖從上到下的模式會導(dǎo)致系統(tǒng)的并行性能依次降低樱衷，安全性依次提高李命。

讀未提交：別人改數(shù)據(jù)的事務(wù)尚未提交，我在我的事務(wù)中也能讀到箫老。

讀已提交(Oracle默認(rèn))：別人改數(shù)據(jù)的事務(wù)已經(jīng)提交封字，我在我的事務(wù)中才能讀到。

可重復(fù)讀(MySQL默認(rèn))：別人改數(shù)據(jù)的事務(wù)已經(jīng)提交耍鬓，我在我的事務(wù)中也不去讀阔籽，以此保證重復(fù)讀一致性。

串行：我的事務(wù)尚未提交牲蜀，別人就別想改數(shù)據(jù)笆制。

標(biāo)準(zhǔn)跟實現(xiàn)：上面都是關(guān)于事務(wù)的標(biāo)準(zhǔn)，但是每一種數(shù)據(jù)庫都有不同的實現(xiàn)涣达，比如MySQL InnDB 默認(rèn)為RR級別在辆，但是不會出現(xiàn)幻讀证薇。因為當(dāng)事務(wù)A更新了所有記錄的某個字段，此時事務(wù)A會獲得對這個表的表鎖匆篓，因為事務(wù)A還沒有提交浑度，所以事務(wù)A獲得的鎖沒有釋放，此時事務(wù)B在該表插入新記錄鸦概，會因為無法獲得該表的鎖箩张，則導(dǎo)致插入操作被阻塞。只有事務(wù)A提交了事務(wù)后窗市，釋放了鎖先慷，事務(wù)B才能進行接下去的操作。所以可以說 MySQL的RR級別的隔離是已經(jīng)實現(xiàn)解決了臟讀咨察，不可重復(fù)讀和幻讀的论熙。

五、MySQL中的鎖

無論是Java的并發(fā)編程還是數(shù)據(jù)庫的并發(fā)操作都會涉及到鎖摄狱，研發(fā)人員引入了悲觀鎖跟樂觀鎖這樣一種鎖的設(shè)計思想脓诡。

悲觀鎖：

優(yōu)點：適合在寫多讀少的并發(fā)環(huán)境中使用，雖然無法維持非常高的性能二蓝，但是在樂觀鎖無法提更好的性能前提下誉券，可以做到數(shù)據(jù)的安全性

缺點：加鎖會增加系統(tǒng)開銷指厌，雖然能保證數(shù)據(jù)的安全刊愚，但數(shù)據(jù)處理吞吐量低，不適合在讀書寫少的場合下使用

樂觀鎖：

優(yōu)點：在讀多寫少的并發(fā)場景下踩验，可以避免數(shù)據(jù)庫加鎖的開銷鸥诽，提高DAO層的響應(yīng)性能，很多情況下ORM工具都有帶有樂觀鎖的實現(xiàn)箕憾，所以這些方法不一定需要我們?nèi)藶榈娜崿F(xiàn)牡借。

缺點：在寫多讀少的并發(fā)場景下，即在寫操作競爭激烈的情況下袭异，會導(dǎo)致CAS多次重試钠龙，沖突頻率過高，導(dǎo)致開銷比悲觀鎖更高御铃。

實現(xiàn)：數(shù)據(jù)庫層面的樂觀鎖其實跟CAS思想類似碴里， 通數(shù)據(jù)版本號或者時間戳也可以實現(xiàn)。

數(shù)據(jù)庫并發(fā)場景主要有三種：

讀-讀：不存在任何問題上真，也不需要并發(fā)控制

讀-寫：有隔離性問題咬腋，可能遇到臟讀，幻讀睡互，不可重復(fù)讀

寫-寫：可能存更新丟失問題根竿，比如第一類更新丟失陵像，第二類更新丟失

兩類更新丟失問題：

第一類更新丟失：事務(wù)A的事務(wù)回滾覆蓋了事務(wù)B已提交的結(jié)果 第二類更新丟失：事務(wù)A的提交覆蓋了事務(wù)B已提交的結(jié)果

為了合理貫徹落實鎖的思想，MySQL中引入了雜七雜八的各種鎖：

鎖分類

MySQL支持三種層級的鎖定寇壳，分別為

1.表級鎖定

MySQL中鎖定粒度最大的一種鎖醒颖，最常使用的MYISAM與INNODB都支持表級鎖定。

2.頁級鎖定

是MySQL中鎖定粒度介于行級鎖和表級鎖中間的一種鎖九巡，表級鎖速度快图贸，但沖突多，行級沖突少冕广，但速度慢疏日。所以取了折衷的頁級，一次鎖定相鄰的一組記錄撒汉。

3.行級鎖定

Mysql中鎖定粒度最細(xì)的一種鎖沟优，表示只針對當(dāng)前操作的行進行加鎖。行級鎖能大大減少數(shù)據(jù)庫操作的沖突睬辐。其加鎖粒度最小挠阁，但加鎖的開銷也最大行級鎖不一定比表級鎖要好：鎖的粒度越細(xì)，代價越高溯饵，相比表級鎖在表的頭部直接加鎖侵俗，行級鎖還要掃描找到對應(yīng)的行對其上鎖，這樣的代價其實是比較高的丰刊，所以表鎖和行鎖各有所長隘谣。

MyISAM中的鎖

1. 雖然MySQL支持表，頁啄巧，行三級鎖定寻歧，但MyISAM存儲引擎只支持表鎖。所以MyISAM的加鎖相對比較開銷低秩仆，但數(shù)據(jù)操作的并發(fā)性能相對就不高码泛。但如果寫操作都是尾插入，那還是可以支持一定程度的讀寫并發(fā)

2. 從MyISAM所支持的鎖中也可以看出澄耍，MyISAM是一個支持讀讀并發(fā)噪珊，但不支持通用讀寫并發(fā)，寫寫并發(fā)的數(shù)據(jù)庫引擎齐莲，所以它更適合用于讀多寫少的應(yīng)用場合痢站，一般工程中也用的較少。

InnoDB中的鎖

該模式下支持的鎖實在是太多了铅搓，具體如下：

共享鎖和排他鎖 (Shared and Exclusive Locks)

意向鎖（Intention Locks）

記錄鎖（Record Locks）

間隙鎖（Gap Locks）

臨鍵鎖 （Next-Key Locks）

插入意向鎖（Insert Intention Locks）

主鍵自增鎖 (AUTO-INC Locks)

空間索引斷言鎖（Predicate Locks for Spatial Indexes）

舉個栗子瑟押，比如行鎖里的共享鎖跟排它鎖：lock in share modle 共享讀鎖：

為了確保自己查到的數(shù)據(jù)沒有被其他的事務(wù)正在修改，也就是說確保查到的數(shù)據(jù)是最新的數(shù)據(jù)星掰，并且不允許其他人來修改數(shù)據(jù)多望。但是自己不一定能夠修改數(shù)據(jù)嫩舟，因為有可能其他的事務(wù)也對這些數(shù)據(jù)使用了 in share mode 的方式上了S 鎖。如果不及時的commit 或者rollback 也可能會造成大量的事務(wù)等待怀偷。

for update排它寫鎖:

為了讓自己查到的數(shù)據(jù)確保是最新數(shù)據(jù)家厌，并且查到后的數(shù)據(jù)只允許自己來修改的時候，需要用到for update椎工。相當(dāng)于一個 update 語句饭于。在業(yè)務(wù)繁忙的情況下，如果事務(wù)沒有及時的commit或者rollback 可能會造成其他事務(wù)長時間的等待维蒙，從而影響數(shù)據(jù)庫的并發(fā)使用效率掰吕。

Gap Lock間隙鎖：

1、行鎖只能鎖住行颅痊，如果在記錄之間的間隙插入數(shù)據(jù)就無法解決了殖熟，因此MySQL引入了間隙鎖(Gap Lock)。間隙鎖是左右開區(qū)間斑响。間隙鎖之間不會沖突菱属。

2、間隙鎖和行鎖合稱NextKeyLock舰罚，每個NextKeyLock是前開后閉區(qū)間纽门。

間隙鎖加鎖原則(學(xué)完忘那種)：

1、加鎖的基本單位是 NextKeyLock营罢，是前開后閉區(qū)間赏陵。

2、查找過程中訪問到的對象才會加鎖愤钾。

3瘟滨、索引上的等值查詢候醒，給唯一索引加鎖的時候能颁，NextKeyLock退化為行鎖。

4倒淫、索引上的等值查詢伙菊，向右遍歷時且最后一個值不滿足等值條件的時候，NextKeyLock退化為間隙鎖敌土。

5镜硕、唯一索引上的范圍查詢會訪問到不滿足條件的第一個值為止。

六返干、MVCC

MVCC：

1兴枯、全稱Multi-Version Concurrency Control，即多版本并發(fā)控制矩欠。MVCC是一種并發(fā)控制的理念财剖，維持一個數(shù)據(jù)的多個版本悠夯，使得讀寫操作沒有沖突。

2躺坟、MVCC在MySQL InnoDB中實現(xiàn)目的主要是為了提高數(shù)據(jù)庫并發(fā)性能沦补，用更好的方式去處理讀-寫沖突，做到即使有讀寫沖突時咪橙，也能做到不加鎖夕膀，非阻塞并發(fā)讀。

MySQL InnoDB下的當(dāng)前讀和快照讀

1.當(dāng)前讀

1美侦、像select lock in share mode(共享鎖)产舞、select for update 、update菠剩、insert庞瘸、delete(排他鎖)這些操作都是一種當(dāng)前讀，就是它讀取的是記錄的最新版本赠叼，讀取時還要保證其他并發(fā)事務(wù)不能修改當(dāng)前記錄擦囊，會對讀取的記錄進行加鎖。

2嘴办、當(dāng)前讀可以認(rèn)為是悲觀鎖的具體功能實現(xiàn)

2.快照讀

1瞬场、不加鎖的select就是快照讀，即不加鎖的非阻塞讀涧郊；快照讀的前提是隔離級別不是串行級別贯被，串行級別下的快照讀會退化成當(dāng)前讀；之所以出現(xiàn)快照讀的情況妆艘，是基于提高并發(fā)性能的考慮彤灶，快照讀的實現(xiàn)是基于多版本并發(fā)控制，即MVCC批旺，可以認(rèn)為MVCC是行鎖的一個變種幌陕，但它在很多情況下，避免了加鎖操作汽煮，降低了開銷搏熄；既然是基于多版本，即快照讀可能讀到的并不一定是數(shù)據(jù)的最新版本暇赤，而有可能是之前的歷史版本心例。

2、快照讀就是MVCC思想在MySQL的具體非阻塞讀功能實現(xiàn)鞋囊，MVCC的目的就是為了實現(xiàn)讀-寫沖突不加鎖止后，提高并發(fā)讀寫性能，而這個讀指的就是快照讀溜腐。

3译株、快照讀就是MySQL為我們實現(xiàn)MVCC理想模型的其中一個具體非阻塞讀功能微饥。

因為大佬不滿意只讓數(shù)據(jù)庫采用悲觀鎖這樣性能不佳的形式去解決讀-寫沖突問題，而提出了MVCC古戴，所以我們可以形成兩個組合：

MVCC + 悲觀鎖：MVCC解決讀寫沖突欠橘，悲觀鎖解決寫寫沖突

MVCC + 樂觀鎖：MVCC解決讀寫沖突，樂觀鎖解決寫寫沖突

MVCC的實現(xiàn)原理

MVCC實現(xiàn)原理主要是依賴記錄中的 四個隱式字段现恼、undo日志 肃续、Consistent Read View來實現(xiàn)的。

四個隱式字段：

1.DB_TRX_ID：

6byte叉袍，最近修改(修改/插入)事務(wù)ID：記錄創(chuàng)建這條記錄/最后一次修改該記錄的事務(wù)ID

2.DB_ROLL_PTR

7byte始锚，回滾指針，指向這條記錄的上一個版本（存儲于rollback segment里）

3.DB_ROW_ID

6byte喳逛，隱含的自增ID（隱藏主鍵）瞧捌，如果數(shù)據(jù)表沒有主鍵，InnoDB會自動以DB_ROW_ID產(chǎn)生一個聚簇索引

4.FLAG

一個刪除flag隱藏字段, 既記錄被更新或刪除并不代表真的刪除润文，而是刪除flag變了

事務(wù)對一條記錄的修改姐呐，會導(dǎo)致該記錄的undo log成為一條記錄版本線性表(鏈表)，undo log的鏈?zhǔn)拙褪亲钚碌呐f記錄典蝌，鏈尾就是最早的舊記錄曙砂。

undo日志：此知識點上文已經(jīng)說過了，對MVCC有幫助的實質(zhì)是update undo log骏掀，undo log實際上就是存在rollback segment中舊記錄鏈鸠澈。

一致讀視圖 Consistent Read View：Read View是事務(wù)進行快照讀操作的時候生產(chǎn)的讀視圖(Read View)，在該事務(wù)執(zhí)行的快照讀的那一刻截驮，會生成數(shù)據(jù)庫系統(tǒng)當(dāng)前的一個快照笑陈，記錄并維護系統(tǒng)當(dāng)前活躍事務(wù)的ID(InnoDB里面每個事務(wù)有一個唯一的事務(wù)ID，叫作transaction id葵袭。它是在事務(wù)開始的時候向InnoDB的事務(wù)系統(tǒng)申請的涵妥，是按申請順序嚴(yán)格遞增的)。拿著這個ID跟記錄中ID對比進行選擇性展示眶熬，這里說下大致的思維妹笆。

你可以簡單的理解為MVCC為每一行增加了兩個隱藏字段块请，兩個字段分別保存了這個行的當(dāng)前事務(wù)ID跟行的刪除事務(wù)ID娜氏。

1.insert時：

InnoDB為新插入的每一行保存當(dāng)前系統(tǒng)版本號作為版本號。

2.select時：

1墩新、 InnoDB只會查找版本早于當(dāng)前事務(wù)版本的數(shù)據(jù)行(也就是行的系統(tǒng)版本號<=事務(wù)的系統(tǒng)版本號)贸弥，這樣可以確保事務(wù)讀取的行，要么是在事務(wù)開始前已經(jīng)存在的海渊，要么是事務(wù)自身插入或者修改過的绵疲。

2哲鸳、行的刪除版本要么未定義，要么大于當(dāng)前事務(wù)版本號盔憨，這可以確保事務(wù)讀取到的行在事務(wù)開始之前未被刪除徙菠。

3、只有1郁岩，2 同時滿足的記錄婿奔，才能返回作為查詢結(jié)果。

3.delete時：

InnoDB會為刪除的每一行保存當(dāng)前系統(tǒng)的版本號(事務(wù)的ID)作為刪除標(biāo)識.

4.update時：

InnoDB執(zhí)行update问慎，實際上是新插入了一行記錄萍摊，并保存其創(chuàng)建時間為當(dāng)前事務(wù)的ID，同時保存當(dāng)前事務(wù)ID到要update的行的刪除時間如叼。

上面只是一個淺顯的講解MVCC選擇標(biāo)準(zhǔn)流程冰木，源碼層面應(yīng)該是根據(jù)低水位跟高水位來截取的。具體實現(xiàn)可自行百度笼恰。

重點：

1踊沸、事務(wù)中快照讀的結(jié)果是非常依賴該事務(wù)首次出現(xiàn)快照讀的地方，即某個事務(wù)中首次出現(xiàn)快照讀的地方非常關(guān)鍵社证，它有決定該事務(wù)后續(xù)快照讀結(jié)果的能力雕沿。

2、在RC隔離級別下猴仑，是每個快照讀都會生成并獲取最新的Read View审轮；而在RR隔離級別下，則是同一個事務(wù)中的第一個快照讀才會創(chuàng)建Read View, 之后的快照讀獲取的都是同一個Read View辽俗。

七疾渣、緩沖池（buffer pool）

應(yīng)用系統(tǒng)分層架構(gòu)，為了加速數(shù)據(jù)訪問崖飘，會把最常訪問的數(shù)據(jù)榴捡，放在緩存(cache)里，避免每次都去訪問數(shù)據(jù)庫朱浴。操作系統(tǒng)吊圾，會有緩沖池(buffer pool)機制，避免每次訪問磁盤翰蠢，以加速數(shù)據(jù)的訪問项乒。MySQL作為一個存儲系統(tǒng)，同樣具有緩沖池(buffer pool)機制梁沧，以避免每次查詢數(shù)據(jù)都進行磁盤IO檀何，主要作用：

1、存在的意義是加速查詢

2、緩沖池(buffer pool) 是一種常見的降低磁盤訪問 的機制频鉴；

3栓辜、緩沖池通常以頁(page 16K)為單位緩存數(shù)據(jù)；

4垛孔、緩沖池的常見管理算法是LRU藕甩，memcache，OS周荐，InnoDB都使用了這種算法辛萍；

5、InnoDB對普通LRU進行了優(yōu)化：將緩沖池分為老生代和新生代羡藐，入緩沖池的頁贩毕，優(yōu)先進入老生代，該頁被訪問仆嗦，才進入新生代辉阶，以解決預(yù)讀失效的問題頁被訪問。且在老生代停留時間超過配置閾值的瘩扼，才進入新生代谆甜，以解決批量數(shù)據(jù)訪問，大量熱數(shù)據(jù)淘汰的問題

預(yù)讀失效：

由于預(yù)讀(Read-Ahead)集绰，提前把頁放入了緩沖池规辱，但最終MySQL并沒有從頁中讀取數(shù)據(jù)，稱為預(yù)讀失效

緩沖池污染：

當(dāng)某一個SQL語句栽燕，要批量掃描大量數(shù)據(jù)時罕袋，可能導(dǎo)致把緩沖池的所有頁都替換出去，導(dǎo)致大量熱數(shù)據(jù)被換出碍岔，MySQL性能急劇下降弥锄，這種情況叫緩沖池污染类早。解決辦法：加入老生代停留時間窗口策略后予跌，短時間內(nèi)被大量加載的頁动遭，并不會立刻插入新生代頭部，而是優(yōu)先淘汰那些捏肢，短期內(nèi)僅僅訪問了一次的頁奈籽。

八、table瘦身

空洞：

MySQL執(zhí)行delete命令其實只是把記錄的位置鸵赫，或者數(shù)據(jù)頁標(biāo)記為了可復(fù)用衣屏，但磁盤文件的大小是不會變的。通過delete命令是不能回收表空間的奉瘤。這些可以復(fù)用勾拉，而沒有被使用的空間煮甥，看起來就像是空洞盗温。插入時候引發(fā)分裂同樣會產(chǎn)生空洞藕赞。

重建表思路：

1、新建一個跟A表結(jié)構(gòu)相同的表B

2卖局、按照主鍵ID將A數(shù)據(jù)一行行讀取同步到表B

3斧蜕、用表B替換表A實現(xiàn)效果上的瘦身。

重建表指令：

1砚偶、alter table A engine=InnoDB批销，慎重用，牛逼的DBA都用下面的開源工具染坯。

2均芽、推薦Github：gh-ost

九、SQL Joins单鹿、統(tǒng)計掀宋、 隨機查詢

7種join具體如下：

統(tǒng)計：

1、MyISAM模式下把一個表的總行數(shù)存在了磁盤上仲锄，直接拿來用即可

2劲妙、InnoDB引擎由于 MVCC的原因，需要把數(shù)據(jù)讀出來然后累計求和

3儒喊、性能來說 由壞到好：count(字段) < count(主鍵id) < count(1) ≈ count(*)镣奋，盡量用count(*)即可。

隨機查詢：

mysql> select word from words order by rand() limit 3;

直接使用order by rand()怀愧，explain 這個語句發(fā)現(xiàn)需要 Using temporary和 Using filesort侨颈，查詢的執(zhí)行代價往往是比較大的。所以在設(shè)計的時要避開這種寫法芯义。

mysql> select count(*) into @C from t;
set @Y1 = floor(@C * rand());
set @Y2 = floor(@C * rand());
set @Y3 = floor(@C * rand());
select * from t limit @Y1,1; 
select * from t limit @Y2,1;
select * from t limit @Y3,1;

這樣可以避免臨時表跟排序的產(chǎn)生肛搬，最終查詢行數(shù) = C + (Y1+1) + (Y2+1) + (Y3+1)

exist 和 in 對比：

1、in查詢時首先查詢子查詢的表毕贼，然后將內(nèi)表和外表做一個笛卡爾積温赔，然后按照條件進行篩選。

2鬼癣、子查詢使用 exists陶贼，會先進行主查詢，將查詢到的每行數(shù)據(jù)循環(huán)帶入子查詢校驗是否存在待秃，過濾出整體的返回數(shù)據(jù)拜秧。

3、兩表大小相當(dāng)章郁，in 和 exists 差別不大枉氮。內(nèi)表大志衍，用 exists 效率較高；內(nèi)表小聊替，用 in 效率較高楼肪。

4、查詢用not in 那么內(nèi)外表都進行全表掃描惹悄，沒有用到索引春叫；而not exists 的子查詢依然能用到表上的索引。not exists比not in要快泣港。

十暂殖、MySQL優(yōu)化

SQL優(yōu)化主要分4個方向：SQL語句跟索引、表結(jié)構(gòu)当纱、系統(tǒng)配置呛每、硬件。

總優(yōu)化思路就是最大化利用索引坡氯、盡可能避免全表掃描晨横、減少無效數(shù)據(jù)的查詢：

1、減少數(shù)據(jù)訪問：設(shè)置合理的字段類型廉沮，啟用壓縮颓遏，通過索引訪問等減少磁盤 IO。

2滞时、返回更少的數(shù)據(jù)：只返回需要的字段和數(shù)據(jù)分頁處理叁幢，減少磁盤 IO 及網(wǎng)絡(luò) IO。

3坪稽、減少交互次數(shù)：批量 DML 操作曼玩，函數(shù)存儲等減少數(shù)據(jù)連接次數(shù)。

4窒百、減少服務(wù)器 CPU 開銷：盡量減少數(shù)據(jù)庫排序操作以及全表查詢黍判，減少 CPU 內(nèi)存占用 。

5篙梢、分表分區(qū)：使用表分區(qū)顷帖，可以增加并行操作，更大限度利用 CPU 資源渤滞。

SQL語句優(yōu)化大致舉例：

1贬墩、合理建立覆蓋索引：可以有效減少回表。

2妄呕、union陶舞，or，in都能命中索引绪励，建議使用in

3肿孵、負(fù)向條件(!=唠粥、<>、not in停做、not exists晤愧、not like 等) 索引不會使用索引，建議用in雅宾。

4养涮、在列上進行運算或使用函數(shù)會使索引失效葵硕，從而進行全表掃描

5眉抬、小心隱式類型轉(zhuǎn)換，原字符串用整型會觸發(fā)CAST函數(shù)導(dǎo)致索引失效懈凹。原int用字符串則會走索引蜀变。

6、不建議使用%前綴模糊查詢介评。

7库北、多表關(guān)聯(lián)查詢時，小表在前们陆，大表在后寒瓦。在 MySQL 中，執(zhí)行 from 后的表關(guān)聯(lián)查詢是從左往右執(zhí)行的(Oracle 相反)坪仇，第一張表會涉及到全表掃描杂腰。

8、調(diào)整 Where 字句中的連接順序椅文，MySQL 采用從左往右喂很，自上而下的順序解析 where 子句。根據(jù)這個原理皆刺，應(yīng)將過濾數(shù)據(jù)多的條件往前放少辣，最快速度縮小結(jié)果集。

SQL調(diào)優(yōu)大致思路：

1羡蛾、先用慢查詢?nèi)罩径ㄎ痪唧w需要優(yōu)化的sql

2漓帅、使用 explain 執(zhí)行計劃查看索引使用情況

3、重點關(guān)注(一般情況下根據(jù)這4列就能找到索引問題)：

1痴怨、key（查看有沒有使用索引）

2忙干、key_len（查看索引使用是否充分）

3、type（查看索引類型）

4腿箩、Extra（查看附加信息：排序豪直、臨時表、where條件為false等）

4珠移、根據(jù)上1步找出的索引問題優(yōu)化sql 5弓乙、再回到第2步

表結(jié)構(gòu)優(yōu)化：

1末融、盡量使用TINYINT、SMALLINT暇韧、MEDIUM_INT作為整數(shù)類型而非INT勾习，如果非負(fù)則加上UNSIGNED 。

2懈玻、VARCHAR的長度只分配真正需要的空間 巧婶。

3、盡量使用TIMESTAMP而非DATETIME 涂乌。

4艺栈、單表不要有太多字段，建議在20以內(nèi)湾盒。

5湿右、避免使用NULL字段，很難查詢優(yōu)化且占用額外索引空間罚勾。字符串默認(rèn)為''毅人。

讀寫分離：

只在主服務(wù)器上寫，只在從服務(wù)器上讀尖殃。對應(yīng)到數(shù)據(jù)庫集群一般都是一主一從丈莺、一主多從。業(yè)務(wù)服務(wù)器把需要寫的操作都寫到主數(shù)據(jù)庫中送丰，讀的操作都去從庫查詢缔俄。主庫會同步數(shù)據(jù)到從庫保證數(shù)據(jù)的一致性。一般 讀寫分離 的實現(xiàn)方式有兩種：代碼封裝跟數(shù)據(jù)庫中間件蚪战。

分庫分表：分庫分表 分為垂直和水平兩個方式牵现，一般是先垂直后水平。

1邀桑、垂直分庫：將應(yīng)用分為若干模塊瞎疼，比如訂單模塊、用戶模塊壁畸、商品模塊贼急、支付模塊等等。其實就是微服務(wù)的理念捏萍。

2太抓、垂直分表：一般將不常用字段跟數(shù)據(jù)較大的字段做拆分。

3令杈、水平分表：根據(jù)場景選擇什么字段作分表字段走敌，比如淘寶日訂單1000萬，用userId作分表字段逗噩，數(shù)據(jù)查詢支持到最近6個月的訂單掉丽，超過6個月的做歸檔處理跌榔，那么6個月的數(shù)據(jù)量就是18億，分1024張表捶障，每個表存200W數(shù)據(jù)僧须，hash(userId)%100找到對應(yīng)表格。

4项炼、ID生成器：分布式ID 需要跨庫全局唯一方便查詢存儲-檢索數(shù)據(jù)担平，確保唯一性跟數(shù)字遞增性。

目前主要流行的分庫分表工具 就是Mycat和sharding-sphere锭部。

TiDB：開源分布式數(shù)據(jù)庫暂论，結(jié)合了傳統(tǒng)的 RDBMS 和NoSQL 的最佳特性。TiDB 兼容 MySQL空免，支持無限的水平擴展空另，具備強一致性和高可用性盆耽。TiDB 的目標(biāo)是為 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 場景提供一站式的解決方案蹋砚。TiDB 具備如下核心特點

1、支持 MySQL 協(xié)議（開發(fā)接入成本低）摄杂。

2坝咐、100% 支持事務(wù)（數(shù)據(jù)一致性實現(xiàn)簡單、可靠）析恢。

3墨坚、無限水平拓展（不必考慮分庫分表），不停服務(wù)映挂。

4泽篮、TiDB 支持和 MySQL 的互備。

5柑船、遵循jdbc原則帽撑，學(xué)習(xí)成本低，強關(guān)系型鞍时，強一致性亏拉，不用擔(dān)心主從配置，不用考慮分庫分表逆巍，還可以無縫動態(tài)擴展及塘。

適合：

1、原業(yè)務(wù)的 MySQL 的業(yè)務(wù)遇到單機容量或者性能瓶頸時锐极，可以考慮使用 TiDB 無縫替換 MySQL笙僚。

2、大數(shù)據(jù)量下灵再，MySQL 復(fù)雜查詢很慢肋层。

3庇勃、大數(shù)據(jù)量下，數(shù)據(jù)增長很快槽驶，接近單機處理的極限责嚷，不想分庫分表或者使用數(shù)據(jù)庫中間件等對業(yè)務(wù)侵入性較大、對業(yè)務(wù)有約束的 Sharding 方案掂铐。

4罕拂、大數(shù)據(jù)量下，有高并發(fā)實時寫入全陨、實時查詢爆班、實時統(tǒng)計分析的需求。5辱姨、有分布式事務(wù)柿菩、多數(shù)據(jù)中心的數(shù)據(jù) 100% 強一致性、auto-failover 的高可用的需求雨涛。

不適合：

1枢舶、單機 MySQL 能滿足的場景也用不到 TiDB。

2替久、數(shù)據(jù)條數(shù)少于 5000w 的場景下通常用不到 TiDB凉泄，TiDB 是為大規(guī)模的數(shù)據(jù)場景設(shè)計的。

3蚯根、如果你的應(yīng)用數(shù)據(jù)量泻笾凇（所有數(shù)據(jù)千萬級別行以下），且沒有高可用颅拦、強一致性或者多數(shù)據(jù)中心復(fù)制等要求蒂誉，那么就不適合使用 TiDB。

寫在最后

歡迎大家關(guān)注我的公眾號【風(fēng)平浪靜如碼】距帅，海量Java相關(guān)文章右锨，學(xué)習(xí)資料都會在里面更新，整理的資料也會放在里面锥债。

覺得寫的還不錯的就點個贊陡蝇，加個關(guān)注唄！點關(guān)注哮肚，不迷路登夫，持續(xù)更新！Ｔ侍恕恼策！