mysql我們最常用的操作，無非是查詢、更新和新增記錄，那么mysql關(guān)于這些操作，從架構(gòu)設(shè)計到底層數(shù)據(jù)結(jié)構(gòu)，都做了什么呢？
mysql分為server層和存儲引擎層，Server 層包括連接器、查詢緩存、分析器、優(yōu)化器、執(zhí)行器等，涵蓋 MySQL 的大多數(shù)核心服務(wù)功能，以及所有的內(nèi)置函數(shù)（如日期、時間、數(shù)學(xué)和加密函數(shù)等），所有跨存儲引擎的功能都在這一層實現(xiàn)，比如存儲過程、觸發(fā)器、視圖等。
而存儲引擎層負責(zé)數(shù)據(jù)的存儲和提取。其架構(gòu)模式是插件式的，支持 InnoDB、MyISAM、Memory 等多個存儲引擎。現(xiàn)在最常用的存儲引擎是 InnoDB，它從 MySQL 5.5.5 版本開始成為了默認存儲引擎。我們接下來的討論皆是在innoDB的前提下。
關(guān)于查詢，我們知道索引的出現(xiàn)，可以幫助我們快速定位到我們所需的數(shù)據(jù)，提高我們的讀寫效率，索引的實現(xiàn)有很多種，
比如哈希表，有序數(shù)組，搜索樹等等，哈希表我們可以通過對特定的hash函數(shù)把key轉(zhuǎn)化為一個確定的位置，從而迅速查找到我們所需的數(shù)據(jù)，
不可避免的由于hash沖突的存在，導(dǎo)致不同的key出現(xiàn)同一個值的情況，進而出現(xiàn)鏈表以解決這種情況
由于數(shù)據(jù)的無序，所以當(dāng)出現(xiàn)范圍查詢的需求時，hash表的表現(xiàn)并不盡如人意，僅適用于等值查詢的情況
有序數(shù)組的等值查詢和范圍查詢都非常優(yōu)秀，可以通過二分法迅速找到所需數(shù)據(jù)，如果是范圍查詢，由于是有序的，所以只需繼續(xù)往后或
往前遍歷即可，但是由于我們的數(shù)據(jù)庫，是會經(jīng)常發(fā)生數(shù)據(jù)的更新的，有序數(shù)組的更新，需要挪動改動位置后的所有數(shù)據(jù)，成本太高。
二叉樹的特征是每個節(jié)點大于左節(jié)點而小于右節(jié)點，查詢和更新都很快。然而因為索引不僅寫在內(nèi)存中，還需要寫在磁盤中，在機械硬盤時代，從磁盤隨機讀一個數(shù)據(jù)塊需要 10 ms 左右的尋址時間。也就是說，對于一個 100 萬行的表，如果使用二叉樹來存儲，單獨訪問一個行可能需要 20 個 10 ms 的時間，由于二叉樹只有2個分叉，導(dǎo)致這棵樹會長得很高進而導(dǎo)致我們的查詢次數(shù)增多，所以N叉樹應(yīng)運而生，假如N是1000，那么
一顆高為4的樹，就能夠容納1000的3次方，10億的數(shù)據(jù)，查詢一個值訪問磁盤的次數(shù)最多也就3次（因為根節(jié)點一般在內(nèi)存中常駐）
N 叉樹由于在讀寫上的性能優(yōu)點，以及適配磁盤的訪問模式，已經(jīng)被廣泛應(yīng)用在數(shù)據(jù)庫引擎中了
不管是哈希還是有序數(shù)組，或者 N 叉樹，它們都是不斷迭代、不斷優(yōu)化的產(chǎn)物或者解決方案。數(shù)據(jù)庫技術(shù)發(fā)展到今天，跳表、LSM 樹等數(shù)據(jù)結(jié)構(gòu)也被用于引擎設(shè)計中，這里我就不再一一展開了。
接下來我們探討一下innodb關(guān)于數(shù)據(jù)更新做了什么優(yōu)化。
在我們小時候，我們?nèi)ゴ謇锏男≠u部，經(jīng)常會看到小賣部里面有一塊小黑板，上面記錄了某某某年某月某日賒了多少錢的賬，你想想，小賣部
一般就店老板夫妻兩個人，最多孩子放假的時候來幫忙，每天的買賣高峰期是很忙的，如果某個人來賒賬了，是不可能臨時跑到樓上的房間從
層層被褥中找出那本小賬本，然后再一頁一頁翻出那個人的欠賬歷史記錄再去算出加上今天他總共欠我多少錢，太慢了，通常的做法是立馬在
小黑板隨手記一筆某某的欠賬記錄，等到夜深人靜關(guān)店的時候，再拿出小賬本對照小黑板更新一波賒賬記錄，
映射到mysql，這叫做WAL技術(shù)，Write-Ahead Logging，它的關(guān)鍵點就是先寫日志，再寫磁盤，也就是先寫小黑板，等不忙的時候再寫賬本。
因為磁盤的隨機讀寫，是非常慢的，相較于內(nèi)存的讀寫，速度上有幾十萬倍的差距，我們不可能慢吞吞的去磁盤找到那條數(shù)據(jù)然后再更新，
mysql中的小黑板，叫做redolog，所以總而言之，mysql關(guān)于數(shù)據(jù)更新是這樣做的，先在內(nèi)存中的一塊叫做redolog的緩沖區(qū)中先記錄
‘某某記錄修改成為了什么‘，從邏輯上理解，我們可以把redolog當(dāng)成一個環(huán)，有兩個指針，一個指向?qū)懙侥牧耍粋€指向更新到哪了，
mysql后臺再慢慢的把緩沖區(qū)里面的東西更新到磁盤及redolog的物理日志，redolog還可以和binlog通過
兩階段提交從而達到crash-safe的能力，保證在數(shù)據(jù)庫突然掛掉的情況下恢復(fù)數(shù)據(jù)，這里就不拓展了。
無獨有偶，mysql關(guān)于數(shù)據(jù)更新還有個小優(yōu)化，我們知道索引有唯一索引和非唯一索引，在更新上的區(qū)別就是，更新唯一索引需要比
更新非唯一索引多一個步驟，就是判斷我更新之后的唯一性。對于普通索引而言，我們可以通過chage buffer從而提升我們的更新效率，
通常的更新流程這這樣的，我們需要去磁盤里把數(shù)據(jù)讀到內(nèi)存，再做更新，然后再寫回到磁盤，由前面可知，磁盤的操作是數(shù)據(jù)庫中成本最高的操作之一，會大大降低我們的效率，所以我們要盡可能避免磁盤的操作，change buffer是一塊專門用來記錄數(shù)據(jù)變更的內(nèi)存，當(dāng)需要更新
某條記錄時，只需在change buffer中記錄即可，當(dāng)change buffer存到一定量或者某條只存在change buffer不在磁盤中的數(shù)據(jù)被訪問到
時，需要通過merge操作完成真正的數(shù)據(jù)更新。
因為 merge 的時候是真正進行數(shù)據(jù)更新的時刻，而 change buffer 的主要目的就是將記錄的變更動作緩存下來，所以在一個數(shù)據(jù)頁做 merge 之前，change buffer 記錄的變更越多（也就是這個頁面上要更新的次數(shù)越多），收益就越大。
因此，對于寫多讀少的業(yè)務(wù)來說，頁面在寫完以后馬上被訪問到的概率比較小，此時 change buffer 的使用效果最好。這種業(yè)務(wù)模型常見的就是賬單類、日志類的系統(tǒng)。
