MySQL中你必须知道的10件事，1.5万字！
1、SQL語句執行流程
MySQL大體上可分為Server層和存儲引擎層兩部分。
Server層：
連接器：TCP握手后服務器來驗證登陸用戶身份，A用戶創建連接后，管理員對A用戶權限修改了也不會影響到已經創建的鏈接權限，必須重新登陸。
查詢緩存：查詢后的結果存儲位置，MySQL8.0版本以后已經取消，因為查詢緩存失效太頻繁，得不償失。
分析器：根據語法規則，判斷你輸入的這個SQL語句是否滿足MySQL語法。
優化器：多種執行策略可實現目標，系統自動選擇最優進行執行。
執行器：判斷是否有權限，將最終任務提交到存儲引擎。
存儲引擎層
負責數據的存儲和提取。其架構模式是插件式的，支持InnoDB、MyISAM、Memory等多個存儲引擎。現在最常用的存儲引擎是InnoDB，它從MySQL 5.5.5版本開始成為了默認存儲引擎(經常用的也是這個)。
SQL執行順序
2、BinLog、RedoLog、UndoLog
BinLog
BinLog是記錄所有數據庫表結構變更（例如create、alter table）以及表數據修改(insert、update、delete)的二進制日志，主從數據庫同步用到的都是BinLog文件。BinLog日志文件有三種模式。
STATEMENT 模式
內容：binlog 只會記錄可能引起數據變更的 sql 語句
優勢：該模式下，因為沒有記錄實際的數據，所以日志量和 IO 都消耗很低，性能是最優的
劣勢：但有些操作并不是確定的，比如 uuid() 函數會隨機產生唯一標識，當依賴 binlog 回放時，該操作生成的數據與原數據必然是不同的，此時可能造成無法預料的后果。
ROW 模式
內容：在該模式下，binlog 會記錄每次操作的源數據與修改后的目標數據，StreamSets就要求該模式。
優勢：可以絕對精準的還原，從而保證了數據的安全與可靠，并且復制和數據恢復過程可以是并發進行的
劣勢：缺點在于 binlog 體積會非常大，同時，對于修改記錄多、字段長度大的操作來說，記錄時性能消耗會很嚴重。閱讀的時候也需要特殊指令來進行讀取數據。
MIXED 模式
內容：是對上述STATEMENT 跟 ROW ?兩種模式的混合使用。
細節：對于絕大部分操作，都使用 STATEMENT 來進行 binlog 的記錄，只有以下操作使用 ROW 來實現：表的存儲引擎為 NDB，使用了uuid() 等不確定函數，使用了 insert delay 語句，使用了臨時表
主從同步流程：
1、主節點必須啟用二進制日志，記錄任何修改了數據庫數據的事件。
2、從節點開啟一個線程（I/O Thread)把自己扮演成 mysql 的客戶端，通過 mysql 協議，請求主節點的二進制日志文件中的事件 。
3、主節點啟動一個線程（dump Thread），檢查自己二進制日志中的事件，跟對方請求的位置對比，如果不帶請求位置參數，則主節點就會從第一個日志文件中的第一個事件一個一個發送給從節點。
4、從節點接收到主節點發送過來的數據把它放置到中繼日志（Relay log）文件中。并記錄該次請求到主節點的具體哪一個二進制日志文件內部的哪一個位置（主節點中的二進制文件會有多個）。
5、從節點啟動另外一個線程（sql Thread ），把 Relay log 中的事件讀取出來，并在本地再執行一次。
mysql默認的復制方式是異步的，并且復制的時候是有并行復制能力的。主庫把日志發送給從庫后不管了，這樣會產生一個問題就是假設主庫掛了，從庫處理失敗了，這時候從庫升為主庫后，日志就丟失了。由此產生兩個概念。
全同步復制
主庫寫入binlog后強制同步日志到從庫，所有的從庫都執行完成后才返回給客戶端，但是很顯然這個方式的話性能會受到嚴重影響。
半同步復制
半同步復制的邏輯是這樣，從庫寫入日志成功后返回ACK確認給主庫，主庫收到至少一個從庫的確認就認為寫操作完成。
還可以延伸到由于主從配置不一樣、主庫大事務、從庫壓力過大、網絡震蕩等造成主備延遲，如何避免這個問題？主備切換的時候用可靠性優先原則還是可用性優先原則？如何判斷主庫Crash了？互為主備情況下如何避免主備循環復制？被刪庫跑路了如何正確恢復？(⊙o⊙)… 感覺越來越扯到DBA的活兒上去了。
RedoLog
可以先通過下面demo理解：
飯點記賬可以把賬單寫在賬本上也可以寫在粉板上。有人賒賬或者還賬的話，一般有兩種做法：
1、直接把賬本翻出來，把這次賒的賬加上去或者扣除掉。
2、先在粉板上記下這次的賬，等打烊以后再把賬本翻出來核算。
生意忙時選后者，因為前者太麻煩了。得在密密麻麻的記錄中找到這個人的賒賬總額信息，找到之后再拿出算盤計算，最后再將結果寫回到賬本上。
同樣在MySQL中如果每一次的更新操作都需要寫進磁盤，然后磁盤也要找到對應的那條記錄，然后再更新，整個過程IO成本、查找成本都很高。而粉板和賬本配合的整個過程就是MySQL用到的是Write-Ahead Logging 技術，它的關鍵點就是先寫日志，再寫磁盤。此時賬本 = BinLog，粉板 = RedoLog。
1、 記錄更新時，InnoDB引擎就會先把記錄寫到RedoLog（粉板）里面，并更新內存。同時，InnoDB引擎會在空閑時將這個操作記錄更新到磁盤里面。
2、 如果更新太多RedoLog處理不了的時候，需先將RedoLog部分數據寫到磁盤，然后擦除RedoLog部分數據。RedoLog類似轉盤。
RedoLog有write pos 跟checkpoint
write pos ：是當前記錄的位置，一邊寫一邊后移，寫到第3號文件末尾后就回到0號文件開頭。
check point：是當前要擦除的位置，也是往后推移并且循環的，擦除記錄前要把記錄更新到數據文件。
write pos和check point之間的是粉板上還空著的部分，可以用來記錄新的操作。如果write pos追上checkpoint，表示粉板滿了，這時候不能再執行新的更新，得停下來先擦掉一些記錄，把checkpoint推進一下。
有了redo log，InnoDB就可以保證即使數據庫發生異常重啟，之前提交的記錄都不會丟失，這個能力稱為crash-safe。redolog兩階段提交：為了讓binlog跟redolog兩份日志之間的邏輯一致。提交流程大致如下：
1 prepare階段 --> ?2 寫binlog ?--> 3 commit
當在2之前崩潰時，重啟恢復后發現沒有commit，回滾。備份恢復：沒有binlog 。一致
當在3之前崩潰時，重啟恢復發現雖沒有commit，但滿足prepare和binlog完整，所以重啟后會自動commit。備份：有binlog. 一致
binlog跟redolog區別：
redo log是InnoDB引擎特有的；binlog是MySQL的Server層實現的，所有引擎都可以使用。
redo log是物理日志，記錄的是在某個數據頁上做了什么修改；binlog是邏輯日志，記錄的是這個語句的原始邏輯，比如給ID=2這一行的c字段加1。
redo log是循環寫的，空間固定會用完；binlog是可以追加寫入的。追加寫是指binlog文件寫到一定大小后會切換到下一個，并不會覆蓋以前的日志。
UndoLog
UndoLog 一般是邏輯日志，主要分為兩種：
insert undo log
代表事務在insert新記錄時產生的undo log, 只在事務回滾時需要，并且在事務提交后可以被立即丟棄
update undo log
事務在進行update或delete時產生的undo log; 不僅在事務回滾時需要，在快照讀時也需要；所以不能隨便刪除，只有在快速讀或事務回滾不涉及該日志時，對應的日志才會被purge線程統一清除
3、MySQL中的索引
索引的常見模型有哈希表、有序數組和搜索樹。
哈希表：一種以KV存儲數據的結構，只適合等值查詢，不適合范圍查詢。
有序數組：只適用于靜態存儲引擎，涉及到插入的時候比較麻煩。可以參考Java中的ArrayList。
搜索樹：按照數據結構中的二叉樹來存儲數據，不過此時是N叉樹(B+樹)。廣泛應用在存儲引擎層中。
B+樹比B樹優勢在于：
B+ 樹非葉子節點存儲的只是索引，可以存儲的更多。B+樹比B樹更加矮胖，IO次數更少。
B+ 樹葉子節點前后管理，更加方便范圍查詢。同時結果都在葉子節點，查詢效率穩定。
B+樹中更有利于對數據掃描，可以避免B樹的回溯掃描。
索引的優點：
1、唯一索引可以保證每一行數據的唯一性?
2、提高查詢速度?
3、加速表與表的連接?
4、顯著的減少查詢中分組和排序的時間
5、通過使用索引，可以在查詢的過程中，使用優化隱藏器，提高系統的性能。
索引的缺點：
1、創建跟維護都需要耗時?
2、創建索引時，需要對表加鎖，在鎖表的同時，可能會影響到其他的數據操作?
3、 索引需要磁盤的空間進行存儲，磁盤占用也很快。
4、當對表中的數據進行CRUD的時，也會觸發索引的維護，而維護索引需要時間，可能會降低數據操作性能
索引設計的原則不應該：
1、索引不是越多越好。索引太多，維護索引需要時間跟空間。
2、 頻繁更新的數據，不宜建索引。
3、數據量小的表沒必要建立索引。
應該：
1、重復率小的列建議生成索引。因為重復數據少，索引樹查詢更有效率，等價基數越大越好。
2、數據具有唯一性，建議生成唯一性索引。在數據庫的層面，保證數據正確性?
3、頻繁group by、order by的列建議生成索引。可以大幅提高分組和排序效率?
4、經常用于查詢條件的字段建議生成索引。通過索引查詢，速度更快
索引失效的場景
1、模糊搜索：左模糊或全模糊都會導致索引失效，比如'%a'和'%a%'。但是右模糊是可以利用索引的，比如'a%' 。
2、隱式類型轉換：比如select * from t where name = xxx , name是字符串類型，但是沒有加引號，所以是由MySQL隱式轉換的，所以會讓索引失效 3、當語句中帶有or的時候：比如select * from t where name=‘sw’ or age=14
4、不符合聯合索引的最左前綴匹配：(A,B,C)的聯合索引，你只where了C或B或只有B,C
關于索引的知識點：
主鍵索引：主鍵索引的葉子節點存的是整行數據信息。在InnoDB里，主鍵索引也被稱為聚簇索引（clustered index）。主鍵自增是無法保證完全自增的哦，遇到唯一鍵沖突、事務回滾等都可能導致不連續。
唯一索引：以唯一列生成的索引，該列不允許有重復值，但允許有空值(NULL)
普通索引跟唯一索引查詢性能：InnoDB的數據是按數據頁為單位來讀寫的，默認每頁16KB，因此這兩種索引查詢數據性能差別微乎其微。
change buffer：普通索引用在更新過程的加速，更新的字段如果在緩存中，如果是普通索引則直接更新即可。如果是唯一索引需要將所有數據讀入內存來確保不違背唯一性，所以盡量用普通索引。
非主鍵索引：非主鍵索引的葉子節點內容是主鍵的值。在InnoDB里，非主鍵索引也被稱為二級索引（secondary index）
回表：先通過數據庫索引掃描出數據所在的行，再通過行主鍵id取出索引中未提供的數據，即基于非主鍵索引的查詢需要多掃描一棵索引樹。
覆蓋索引：如果一個索引包含（或者說覆蓋）所有需要查詢的字段的值，我們就稱之為覆蓋索引。
聯合索引：相對單列索引，組合索引是用多個列組合構建的索引，一次性最多聯合16個。
最左前綴原則：對多個字段同時建立的組合索引(有順序，ABC，ACB是完全不同的兩種聯合索引) 以聯合索引(a,b,c)為例，建立這樣的索引相當于建立了索引a、ab、abc三個索引。另外組合索引實際還是一個索引，并非真的創建了多個索引，只是產生的效果等價于產生多個索引。
索引下推：MySQL 5.6引入了索引下推優化，可以在索引遍歷過程中，對索引中包含的字段先做判斷，過濾掉不符合條件的記錄，減少回表字數。
索引維護：B+樹為了維護索引有序性涉及到頁分裂跟頁合并。增刪數據時需考慮頁空間利用率。
自增主鍵：一般會建立與業務無關的自增主鍵，不會觸發葉子節點分裂。
延遲關聯：通過使用覆蓋索引查詢返回需要的主鍵，再根據主鍵關聯原表獲得需要的數據。
InnoDB存儲: * .frm文件是一份定義文件，也就是定義數據庫表是一張怎么樣的表。*.ibd文件則是該表的索引，數據存儲文件，既該表的所有索引樹，所有行記錄數據都存儲在該文件中。
MyISAM存儲：* .frm文件是一份定義文件，也就是定義數據庫表是一張怎么樣的表。* .MYD文件是MyISAM存儲引擎表的所有行數據的文件。* .MYI文件存放的是MyISAM存儲引擎表的索引相關數據的文件。MyISAM引擎下，表數據和表索引數據是分開存儲的。
MyISAM查詢：在MyISAM下，主鍵索引和輔助鍵索引都屬于非聚簇索引。查詢不管是走主鍵索引，還是非主鍵索引，在葉子結點得到的都是目的數據的地址，還需要通過該地址，才能在數據文件中找到目的數據。
PS：InnoDB支持聚簇索引，MyISAM不支持聚簇索引
4、SQL事務隔離級別
ACID的四個特性
原子性（Atomicity）：把多個操作放到一個事務中，保證這些操作要么都成功，要么都不成功
一致性（Consistency）：理解成一串對數據進行操作的程序執行下來，不會對數據產生不好的影響，比如憑空產生，或消失
隔離性（Isolation，又稱獨立性）：隔離性的意思就是多個事務之間互相不干擾，即使是并發事務的情況下，他們只是兩個并發執行沒有交集，互不影響的東西；當然實現中，也不一定需要這么完整隔離性，即不一定需要這么的互不干擾，有時候還是允許有部分干擾的。所以MySQL可以支持4種事務隔離性
持久性（Durability）：當某個操作操作完畢了，那么結果就是這樣了，并且這個操作會持久化到日志記錄中
PS：ACID中C與CAP定理中C的區別
ACID的C著重強調單數據庫事務操作時，要保證數據的完整和正確性，數據不會憑空消失跟增加。CAP 理論中的C指的是對一個數據多個備份的讀寫一致性
事務操作可能會出現的數據問題
1、臟讀(dirty read)：B事務更改數據還未提交，A事務已經看到并且用了。B事務如果回滾，則A事務做錯了?
2、 不可重復讀(non-repeatable read)：不可重復讀的重點是修改: 同樣的條件, 你讀取過的數據, 再次讀取出來發現值不一樣了，只需要鎖住滿足條件的記錄?
3、 幻讀(phantom read)：事務A先修改了某個表的所有紀錄的狀態字段為已處理，未提交；事務B也在此時新增了一條未處理的記錄，并提交了；事務A隨后查詢記錄，卻發現有一條記錄是未處理的造成幻讀現象，幻讀僅專指新插入的行。幻讀會造成語義上的問題跟數據一致性問題。
4、 在可重復讀RR隔離級別下，普通查詢是快照讀，是不會看到別的事務插入的數據的。因此，幻讀在當前讀下才會出現。要用間隙鎖解決此問題。
在說隔離級別之前，你首先要知道，你隔離得越嚴實，效率就會越低。因此很多時候，我們都要在二者之間尋找一個平衡點。SQL標準的事務隔離級別由低到高如下：上圖從上到下的模式會導致系統的并行性能依次降低，安全性依次提高。
讀未提交：別人改數據的事務尚未提交，我在我的事務中也能讀到。
讀已提交(Oracle默認)：別人改數據的事務已經提交，我在我的事務中才能讀到。
可重復讀(MySQL默認)：別人改數據的事務已經提交，我在我的事務中也不去讀，以此保證重復讀一致性。
串行：我的事務尚未提交，別人就別想改數據。
標準跟實現：上面都是關于事務的標準，但是每一種數據庫都有不同的實現，比如MySQL InnDB 默認為RR級別，但是不會出現幻讀。因為當事務A更新了所有記錄的某個字段，此時事務A會獲得對這個表的表鎖，因為事務A還沒有提交，所以事務A獲得的鎖沒有釋放，此時事務B在該表插入新記錄，會因為無法獲得該表的鎖，則導致插入操作被阻塞。只有事務A提交了事務后，釋放了鎖，事務B才能進行接下去的操作。所以可以說 ? MySQL的RR級別的隔離是已經實現解決了臟讀，不可重復讀和幻讀的。
5、MySQL中的鎖
無論是Java的并發編程還是數據庫的并發操作都會涉及到鎖，研發人員引入了悲觀鎖跟樂觀鎖這樣一種鎖的設計思想。
悲觀鎖：
優點：適合在寫多讀少的并發環境中使用，雖然無法維持非常高的性能，但是在樂觀鎖無法提更好的性能前提下，可以做到數據的安全性
缺點：加鎖會增加系統開銷，雖然能保證數據的安全，但數據處理吞吐量低，不適合在讀書寫少的場合下使用
樂觀鎖：
優點：在讀多寫少的并發場景下，可以避免數據庫加鎖的開銷，提高DAO層的響應性能，很多情況下ORM工具都有帶有樂觀鎖的實現，所以這些方法不一定需要我們人為的去實現。
缺點：在寫多讀少的并發場景下，即在寫操作競爭激烈的情況下，會導致CAS多次重試，沖突頻率過高，導致開銷比悲觀鎖更高。
實現：數據庫層面的樂觀鎖其實跟CAS思想類似， 通數據版本號或者時間戳也可以實現。
數據庫并發場景主要有三種：
讀-讀：不存在任何問題，也不需要并發控制
讀-寫：有隔離性問題，可能遇到臟讀，幻讀，不可重復讀
寫-寫：可能存更新丟失問題，比如第一類更新丟失，第二類更新丟失
兩類更新丟失問題：
第一類更新丟失：事務A的事務回滾覆蓋了事務B已提交的結果 第二類更新丟失：事務A的提交覆蓋了事務B已提交的結果
為了合理貫徹落實鎖的思想，MySQL中引入了雜七雜八的各種鎖：
鎖分類
MySQL支持三種層級的鎖定，分別為
表級鎖定
MySQL中鎖定粒度最大的一種鎖，最常使用的MYISAM與INNODB都支持表級鎖定。
頁級鎖定
是MySQL中鎖定粒度介于行級鎖和表級鎖中間的一種鎖，表級鎖速度快，但沖突多，行級沖突少，但速度慢。所以取了折衷的頁級，一次鎖定相鄰的一組記錄。
行級鎖定
Mysql中鎖定粒度最細的一種鎖，表示只針對當前操作的行進行加鎖。行級鎖能大大減少數據庫操作的沖突。其加鎖粒度最小，但加鎖的開銷也最大行級鎖不一定比表級鎖要好：鎖的粒度越細，代價越高，相比表級鎖在表的頭部直接加鎖，行級鎖還要掃描找到對應的行對其上鎖，這樣的代價其實是比較高的，所以表鎖和行鎖各有所長。
MyISAM中的鎖
雖然MySQL支持表，頁，行三級鎖定，但MyISAM存儲引擎只支持表鎖。所以MyISAM的加鎖相對比較開銷低，但數據操作的并發性能相對就不高。但如果寫操作都是尾插入，那還是可以支持一定程度的讀寫并發
從MyISAM所支持的鎖中也可以看出，MyISAM是一個支持讀讀并發，但不支持通用讀寫并發，寫寫并發的數據庫引擎，所以它更適合用于讀多寫少的應用場合，一般工程中也用的較少。
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 共享讀鎖：
為了確保自己查到的數據沒有被其他的事務正在修改，也就是說確保查到的數據是最新的數據，并且不允許其他人來修改數據。但是自己不一定能夠修改數據，因為有可能其他的事務也對這些數據使用了 in share mode 的方式上了S 鎖。如果不及時的commit 或者rollback 也可能會造成大量的事務等待。
for update排它寫鎖:
為了讓自己查到的數據確保是最新數據，并且查到后的數據只允許自己來修改的時候，需要用到for update。相當于一個 update 語句。在業務繁忙的情況下，如果事務沒有及時的commit或者rollback 可能會造成其他事務長時間的等待，從而影響數據庫的并發使用效率。
Gap Lock間隙鎖：
1、行鎖只能鎖住行，如果在記錄之間的間隙插入數據就無法解決了，因此MySQL引入了間隙鎖(Gap Lock)。間隙鎖是左右開區間。間隙鎖之間不會沖突。
2、間隙鎖和行鎖合稱NextKeyLock，每個NextKeyLock是前開后閉區間。
間隙鎖加鎖原則(學完忘那種)：
1、加鎖的基本單位是 NextKeyLock，是前開后閉區間。
2、查找過程中訪問到的對象才會加鎖。
3、索引上的等值查詢，給唯一索引加鎖的時候，NextKeyLock退化為行鎖。
4、索引上的等值查詢，向右遍歷時且最后一個值不滿足等值條件的時候，NextKeyLock退化為間隙鎖。
5、唯一索引上的范圍查詢會訪問到不滿足條件的第一個值為止。
6、MVCC
MVCC：
1、全稱Multi-Version Concurrency Control，即多版本并發控制。MVCC是一種并發控制的理念，維持一個數據的多個版本，使得讀寫操作沒有沖突。
2、MVCC在MySQL InnoDB中實現目的主要是為了提高數據庫并發性能，用更好的方式去處理讀-寫沖突，做到即使有讀寫沖突時，也能做到不加鎖，非阻塞并發讀。
MySQL InnoDB下的當前讀和快照讀
當前讀
1、像select lock in share mode(共享鎖)、select for update 、update、insert、delete(排他鎖)這些操作都是一種當前讀，就是它讀取的是記錄的最新版本，讀取時還要保證其他并發事務不能修改當前記錄，會對讀取的記錄進行加鎖。
2、當前讀可以認為是悲觀鎖的具體功能實現
快照讀
1、不加鎖的select就是快照讀，即不加鎖的非阻塞讀；快照讀的前提是隔離級別不是串行級別，串行級別下的快照讀會退化成當前讀；之所以出現快照讀的情況，是基于提高并發性能的考慮，快照讀的實現是基于多版本并發控制，即MVCC，可以認為MVCC是行鎖的一個變種，但它在很多情況下，避免了加鎖操作，降低了開銷；既然是基于多版本，即快照讀可能讀到的并不一定是數據的最新版本，而有可能是之前的歷史版本。
2、快照讀就是MVCC思想在MySQL的具體非阻塞讀功能實現，MVCC的目的就是為了實現讀-寫沖突不加鎖，提高并發讀寫性能，而這個讀指的就是快照讀。
3、快照讀就是MySQL為我們實現MVCC理想模型的其中一個具體非阻塞讀功能。
因為大佬不滿意只讓數據庫采用悲觀鎖這樣性能不佳的形式去解決讀-寫沖突問題，而提出了MVCC，所以我們可以形成兩個組合：
MVCC + 悲觀鎖：MVCC解決讀寫沖突，悲觀鎖解決寫寫沖突
MVCC + 樂觀鎖：MVCC解決讀寫沖突，樂觀鎖解決寫寫沖突
MVCC的實現原理
MVCC實現原理主要是依賴記錄中的 四個隱式字段、undo日志 、Consistent Read View來實現的。
四個隱式字段：
DB_TRX_ID：
6byte，最近修改(修改/插入)事務ID：記錄創建這條記錄/最后一次修改該記錄的事務ID
DB_ROLL_PTR
7byte，回滾指針，指向這條記錄的上一個版本（存儲于rollback segment里）
DB_ROW_ID
6byte，隱含的自增ID（隱藏主鍵），如果數據表沒有主鍵，InnoDB會自動以DB_ROW_ID產生一個聚簇索引
FLAG
一個刪除flag隱藏字段, 既記錄被更新或刪除并不代表真的刪除，而是刪除flag變了
事務對一條記錄的修改，會導致該記錄的undo log成為一條記錄版本線性表(鏈表)，undo log的鏈首就是最新的舊記錄，鏈尾就是最早的舊記錄。
undo日志：此知識點上文已經說過了，對MVCC有幫助的實質是update undo log，undo log實際上就是存在rollback segment中舊記錄鏈。
一致讀視圖 Consistent Read View：Read View是事務進行快照讀操作的時候生產的讀視圖(Read View)，在該事務執行的快照讀的那一刻，會生成數據庫系統當前的一個快照，記錄并維護系統當前活躍事務的ID(InnoDB里面每個事務有一個唯一的事務ID，叫作transaction id。它是在事務開始的時候向InnoDB的事務系統申請的，是按申請順序嚴格遞增的)。拿著這個ID跟記錄中ID對比進行選擇性展示，這里說下大致的思維。
你可以簡單的理解為MVCC為每一行增加了兩個隱藏字段，兩個字段分別保存了這個行的當前事務ID跟行的刪除事務ID。
insert時：
InnoDB為新插入的每一行保存當前系統版本號作為版本號。
select時：
1、 InnoDB只會查找版本早于當前事務版本的數據行(也就是行的系統版本號<=事務的系統版本號)，這樣可以確保事務讀取的行，要么是在事務開始前已經存在的，要么是事務自身插入或者修改過的。
2、行的刪除版本要么未定義，要么大于當前事務版本號，這可以確保事務讀取到的行在事務開始之前未被刪除。
3、只有1，2 同時滿足的記錄，才能返回作為查詢結果。
delete時：
InnoDB會為刪除的每一行保存當前系統的版本號(事務的ID)作為刪除標識.
update時：
InnoDB執行update，實際上是新插入了一行記錄，并保存其創建時間為當前事務的ID，同時保存當前事務ID到要update的行的刪除時間。
上面只是一個淺顯的講解MVCC選擇標準流程，源碼層面應該是根據低水位跟高水位來截取的。具體實現可自行百度。
重點：
1、事務中快照讀的結果是非常依賴該事務首次出現快照讀的地方，即某個事務中首次出現快照讀的地方非常關鍵，它有決定該事務后續快照讀結果的能力。
2、在RC隔離級別下，是每個快照讀都會生成并獲取最新的Read View；而在RR隔離級別下，則是同一個事務中的第一個快照讀才會創建Read View, 之后的快照讀獲取的都是同一個Read View。
7、緩沖池（buffer pool）
應用系統分層架構，為了加速數據訪問，會把最常訪問的數據，放在緩存(cache)里，避免每次都去訪問數據庫。操作系統，會有緩沖池(buffer pool)機制，避免每次訪問磁盤，以加速數據的訪問。MySQL作為一個存儲系統，同樣具有緩沖池(buffer pool)機制，以避免每次查詢數據都進行磁盤IO，主要作用：
1、存在的意義是加速查詢?
2、緩沖池(buffer pool) 是一種常見的降低磁盤訪問 的機制；
3、緩沖池通常以頁(page 16K)為單位緩存數據；
4、緩沖池的常見管理算法是LRU，memcache，OS，InnoDB都使用了這種算法；
5、InnoDB對普通LRU進行了優化：將緩沖池分為老生代和新生代，入緩沖池的頁，優先進入老生代，該頁被訪問，才進入新生代，以解決預讀失效的問題頁被訪問。且在老生代停留時間超過配置閾值的，才進入新生代，以解決批量數據訪問，大量熱數據淘汰的問題
預讀失效：
由于預讀(Read-Ahead)，提前把頁放入了緩沖池，但最終MySQL并沒有從頁中讀取數據，稱為預讀失效
緩沖池污染：
當某一個SQL語句，要批量掃描大量數據時，可能導致把緩沖池的所有頁都替換出去，導致大量熱數據被換出，MySQL性能急劇下降，這種情況叫緩沖池污染。解決辦法：加入老生代停留時間窗口策略后，短時間內被大量加載的頁，并不會立刻插入新生代頭部，而是優先淘汰那些，短期內僅僅訪問了一次的頁。
8、table瘦身
空洞：
MySQL執行delete命令其實只是把記錄的位置，或者數據頁標記為了可復用，但磁盤文件的大小是不會變的。通過delete命令是不能回收表空間的。這些可以復用，而沒有被使用的空間，看起來就像是空洞。插入時候引發分裂同樣會產生空洞。
重建表思路：
1、新建一個跟A表結構相同的表B?
2、按照主鍵ID將A數據一行行讀取同步到表B?
3、用表B替換表A實現效果上的瘦身。
重建表指令：
1、alter table A engine=InnoDB，慎重用，牛逼的DBA都用下面的開源工具。
2、推薦Github：gh-ost
9、SQL Joins、統計、 隨機查詢
7種join具體如下：統計：
1、MyISAM模式下把一個表的總行數存在了磁盤上，直接拿來用即可?
2、InnoDB引擎由于 MVCC的原因，需要把數據讀出來然后累計求和?
3、性能來說 由好到壞：count(字段) < count(主鍵id) < count(1) ≈ count(*)，盡量用count(*)。
隨機查詢：
mysql>?select?word?from?words?order?by?rand()?limit?3;直接使用order by rand()，explain 這個語句發現需要 Using temporary和 Using filesort，查詢的執行代價往往是比較大的。所以在設計的時要避開這種寫法。
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;這樣可以避免臨時表跟排序的產生，最終查詢行數 = C + (Y1+1) + (Y2+1) + (Y3+1)
exist 和 in 對比：
1、in查詢時首先查詢子查詢的表，然后將內表和外表做一個笛卡爾積，然后按照條件進行篩選。
2、子查詢使用 exists，會先進行主查詢，將查詢到的每行數據循環帶入子查詢校驗是否存在，過濾出整體的返回數據。
3、兩表大小相當，in 和 exists 差別不大。內表大，用 exists 效率較高；內表小，用 in 效率較高。
4、查詢用not in 那么內外表都進行全表掃描，沒有用到索引；而not extsts 的子查詢依然能用到表上的索引。not exists都比not in要快。
10、MySQL優化
SQL優化主要分4個方向：SQL語句跟索引、表結構、系統配置、硬件。
總優化思路就是最大化利用索引、盡可能避免全表掃描、減少無效數據的查詢：
1、減少數據訪問：設置合理的字段類型，啟用壓縮，通過索引訪問等減少磁盤 IO。
2、返回更少的數據：只返回需要的字段和數據分頁處理，減少磁盤 IO 及網絡 IO。
3、減少交互次數：批量 DML 操作，函數存儲等減少數據連接次數。
4、減少服務器 CPU 開銷：盡量減少數據庫排序操作以及全表查詢，減少 CPU 內存占用?。
5、分表分區：使用表分區，可以增加并行操作，更大限度利用 CPU 資源。
SQL語句優化大致舉例：
1、合理建立覆蓋索引：可以有效減少回表。
2、union，or，in都能命中索引，建議使用in?
3、負向條件(!=、<>、not in、not exists、not like 等) 索引不會使用索引，建議用in。
4、在列上進行運算或使用函數會使索引失效，從而進行全表掃描?
5、小心隱式類型轉換，原字符串用整型會觸發CAST函數導致索引失效。原int用字符串則會走索引。
6、不建議使用%前綴模糊查詢。
7、多表關聯查詢時，小表在前，大表在后。在 MySQL 中，執行 from 后的表關聯查詢是從左往右執行的(Oracle 相反)，第一張表會涉及到全表掃描。
8、調整 Where 字句中的連接順序，MySQL 采用從左往右，自上而下的順序解析 where 子句。根據這個原理，應將過濾數據多的條件往前放，最快速度縮小結果集。
SQL調優大致思路：
1、先用慢查詢日志定位具體需要優化的sql?
2、使用 explain 執行計劃查看索引使用情況?
3、重點關注(一般情況下根據這4列就能找到索引問題)：
1、key（查看有沒有使用索引）?
2、key_len（查看索引使用是否充分）
3、type（查看索引類型）?
4、Extra（查看附加信息：排序、臨時表、where條件為false等）
4、根據上1步找出的索引問題優化sql 5、再回到第2步
表結構優化：
1、盡量使用TINYINT、SMALLINT、MEDIUM_INT作為整數類型而非INT，如果非負則加上UNSIGNED 。
2、VARCHAR的長度只分配真正需要的空間?。
3、盡量使用TIMESTAMP而非DATETIME?。
4、單表不要有太多字段，建議在20以內。
5、避免使用NULL字段，很難查詢優化且占用額外索引空間。字符串默認為''。
讀寫分離：
只在主服務器上寫，只在從服務器上讀。對應到數據庫集群一般都是一主一從、一主多從。業務服務器把需要寫的操作都寫到主數據庫中，讀的操作都去從庫查詢。主庫會同步數據到從庫保證數據的一致性。一般 讀寫分離 的實現方式有兩種：代碼封裝跟數據庫中間件。
分庫分表：分庫分表分為垂直和水平兩個方式，一般是先垂直后水平。
1、垂直分庫：將應用分為若干模塊，比如訂單模塊、用戶模塊、商品模塊、支付模塊等等。其實就是微服務的理念。
2、垂直分表：一般將不常用字段跟數據較大的字段做拆分。
3、水平分表：根據場景選擇什么字段作分表字段，比如淘寶日訂單1000萬，用userId作分表字段，數據查詢支持到最近6個月的訂單，超過6個月的做歸檔處理，那么6個月的數據量就是18億，分1024張表，每個表存200W數據，hash(userId)%100找到對應表格。
4、ID生成器：分布式ID 需要跨庫全局唯一方便查詢存儲-檢索數據，確保唯一性跟數字遞增性。
目前主要流行的分庫分表工具 就是Mycat和sharding-sphere。
TiDB：開源分布式數據庫，結合了傳統的 RDBMS 和NoSQL 的最佳特性。TiDB 兼容 MySQL，支持無限的水平擴展，具備強一致性和高可用性。TiDB 的目標是為 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 場景提供一站式的解決方案。TiDB 具備如下核心特點
1、支持 MySQL 協議（開發接入成本低）。
2、100% 支持事務（數據一致性實現簡單、可靠）。
3、無限水平拓展（不必考慮分庫分表），不停服務。
4、TiDB 支持和 MySQL 的互備。
5、遵循jdbc原則，學習成本低，強關系型，強一致性，不用擔心主從配置，不用考慮分庫分表，還可以無縫動態擴展。
適合：
1、原業務的 MySQL 的業務遇到單機容量或者性能瓶頸時，可以考慮使用 TiDB 無縫替換 MySQL。
2、大數據量下，MySQL 復雜查詢很慢。
3、大數據量下，數據增長很快，接近單機處理的極限，不想分庫分表或者使用數據庫中間件等對業務侵入性較大、對業務有約束的 Sharding 方案。
4、大數據量下，有高并發實時寫入、實時查詢、實時統計分析的需求。5、有分布式事務、多數據中心的數據 100% 強一致性、auto-failover 的高可用的需求。
不適合：
1、單機 MySQL 能滿足的場景也用不到 TiDB。
2、數據條數少于 5000w 的場景下通常用不到 TiDB，TiDB 是為大規模的數據場景設計的。
3、如果你的應用數據量小（所有數據千萬級別行以下），且沒有高可用、強一致性或者多數據中心復制等要求，那么就不適合使用 TiDB。
往期推薦這8種常見的SQL錯誤用法，你還在用嗎？
用好MySQL的21個好習慣！
忘記MySQL密碼怎么辦？一招教你搞定！
關注我，每天陪你進步一點點！
總結
以上是生活随笔為你收集整理的MySQL中你必须知道的10件事，1.5万字！的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： MySQL 中锁的面试题总结
- 下一篇： 记住：永远不要在MySQL中使用UTF-