内容簡要：
一、關于核心
二、核心特性詳解
一、 關于核心
（一）回歸核心
基于阿裡雲對核心重要性的判斷，我們投入大量精力進行核心研發。
在使用雲的時候，可能存在決策時間、價格商談時間、資料遷移時間和運作時間。當這些東西完成之後，我們發現一個穩定的資料庫核心尤為重要，因為它伴随了使用者最長的時間，是以我們花費大量的精力提升核心，并取得了不錯的效果。
（二）核心研發
2020年初，阿裡雲對資料庫核心研發進行構思，從兩個方向着手，一是從使用者/客戶角度，第二個是從技術要求方面，下面分别作出介紹。
1.客戶角度
客戶角度分為四個方面：實用性、高性能、穩定性、安全性。
首先，我們希望加一些非常實用的功能。例如Outline功能，可以臨時修改一個SQL的執行計劃，把它從錯誤的計劃變成正确的執行計劃。還有Flashback功能，當資料有誤操作的時候，可以快速找回誤操作之前的資料，這些功能具備十分強的實用性。
第二個是提高性能，我們希望有更高的QPS和更低的RT，這對應用十分重要。
第三個是穩定性，我們希望提升高并發場景下的穩定性和更快的問題分析能力。
第四個我們希望提升安全性，比如說我們對于通信與資料存儲進行加密。我們實作防止随意删表，對删表流程做特殊權限控制。我們研發資源回收筒，當使用者有删除操作時，先将東西放到資源回收筒而不是直接删除，同時對資源回收筒設定特别的權限控制。
阿裡雲在考慮研發客戶需求内容時，基本遵從以上四點進行。
2.技術要求
技術要求分為四點：雲場景、通用性、連續性、領先性。
首先，過去大家認識AliSQL可能是通過電商業務的秒殺場景開始，但我們認為不應受到電商業務場景的局限，而應該從雲上使用者場景出發，希望我們的技術能夠讓所有的雲使用者受益。
第二是功能和技術須具備通用性。通用性指功能的使用不受場景限制，适用于所有場景，使用者無需修改SQL或應用。
第三點希望這些功能在不同的版本之間具有連續性，我們的技術在RDS 56/57/80上行為一緻。
第四個是技術領先性，或者稱為獨創性。我們希望這些技術或功能具備其他版本都沒有的創新，是一些獨到性的需求。
（三）核心特性
按照客戶角度分類，我們對上述四個技術又進行詳細劃分。
1.實用性
實用性方面實作四個功能，分别是是動态線程池技術，Flashback查詢，SQL Outline和自動熱點排隊。
2.高性能
高性能方面實作了四個功能，分别是索引鎖優化提升性能，Binlog In Redo，高效MySQL查詢緩存和多塊讀技術。
3.穩定性
穩定性有四方面改進，分别是快速DDL，性能監控的插件，BP動态伸縮與頁面淘汰優化。
4.安全性
在安全性方面，增加了對國密算法的支援，并實作防删表的功能和創立DDL資源回收筒。
（四）版本對齊
上圖為每個功能在各版本上的情況。我們研發首先是從8.0版本開始，之後是5.7版本，最後是在5.6版本，其中有兩個功能不在5.6版本實作。
第一個是SQL Outline，因為這依賴于Hint技術， 5.6版本原生架構裡不支援Hint技術。
第二個是BP動态升縮，5.6版本原生架構裡同樣沒有提供該項支援這塊。
除了上述兩項功能，其他的功能三個版本均可對齊，表明我們目前實作的功能大多具備良好的延續性。
（五）全網功能
在上述功能中，有部分功能達到數十萬執行個體開啟，稱為全網功能。
如上圖所示，全網功能有四個，分别是動态線程池、索引鎖優化、快速DDL和性能監控插件。全網功能的要求是數字化執行個體開啟使用，運作一年且沒有出現問題，我們接下裡的目标是在2021年讓2020所有功能都成為全網功能。
二、核心本質解析
（一）實用性
l 實用性主要從四個方面展現：
動态線程池；
Flashback查詢；
SQL Outline；
自動熱點排隊；
1.動态線程池
動态線程池的重要性不言而喻，随着資料庫的使用越來越深入，資料量也越來越大，應用到資料庫連接配接數越來越高。
在一般情況下，性能會随着連接配接數變大而下降，上圖灰線橫坐标是資料庫的連接配接數，縱坐标QPS。在達到一定并發以後，連接配接數開始下降，但在動态線程池的基礎下，可以變成完整平滑的線。
我們認為線程池有四個非常重要的功能，首先是RDS 56/57/80獨家預設開啟，第二個是節約記憶體，第三個是節約CPU，第四個是節約線程資源，這些功能解決了許多問題。
首先是高并發的問題，當來了一個數量大且多的請求，例如秒殺場景，來了三千到一萬的請求，線程池可以保證性能不下降。
第二個是解決了高連接配接問題，可以讓RTS支援更高的連接配接數，通過線程池技術，連接配接數在技術上最高達到了50萬。
第三個是高性能，如上圖曲線所示，在上1000個連接配接以後，差距會越來越明顯，到8000個連結時，原來的SQL幾乎罷工，這種情況通過動态線程池得到解決。
上圖為使用線程池之後的收益情況案例。左圖和右圖分别代表不開啟線程池和開啟線程池的差別。
當沒有開啟線程池時，可以看到Load數值很高，Process CPU的使用率與記憶體也存在不少差別。當沒有開啟線程池時，記憶體是10個GB，開啟線程池後Load降到3.98，記憶體節約了200MB，這是一個非常顯著的提升。
上圖下方黑圖是一個真實執行個體備庫的性能資料，它的資料庫連接配接數有15400個連接配接，在開啟動态線程池後，後端隻需要127個線程就可以提供非常平穩的服務。
2. Flashback查詢
很多時候使用者可能會遇到以下場景，如有些表不小心做一些誤操作，例如Update語句的Where條件寫錯，或者根本就沒有指定條件，或者Delete的語句，這些非常具有傷害性。
當遇到這些情況，原來的解決辦法是解析Binlog進行資料恢複，現在我們在SQL語句裡加了一個“as of timestamp”文法，使得我們可以回到過去的時間點，将誤操作之前的資料查出來，然後用這些資料進行恢複。
3. SQL Outline
如上圖所示，可以看到SQL計劃很多時候可能會發生變化。
當使用者做了SQL索引的增減索引，做了統計資訊的重新收集，做出資料庫版本的更新，調了一些參數，資料分布的變化，優化器的缺陷，程式固化等，這些情況都會造成SQL計劃的改變，我們可以通過解決Outline這些情況。
上圖右邊是一個真實案例，這個SLQ交易順序出錯導緻性能很差。通過Outline技術，隻需要調用一個存儲過程，給SQL設定一個Hint，執行計劃準确運作，這種技術給業務、應用開發提供了一個有效的應急手段。
4. 自動熱點排隊
自動熱點排隊是我們對AliSQL秒殺技術的一個更新。
秒殺技術是對同一行的更新，在事務上排隊且不讓它進入事務層，因為同一行的更新進入到事務引擎層時，會使得事務引擎實時檢測成本非常高。這時候我們第一版本加了幾個Hint，告訴SQL要用什麼ID進行排序，這個ID通常指主鍵。
現在通過文法分析，可以把這一部分透明化的，不用去更改SQL，可以自動識别語句是走的是主鍵或者UK索引，如果是走的主鍵或者UK索引表示單行更新，那麼可以自動把Where調節值取出來進行Hash，然後配置設定一個隊列。
（二）高性能
l 高性能主要從四個方面展現：
1）索引鎖優化；
2）Binlog In Redo；
3）高效查詢緩存；
4）多塊讀；
1.索引鎖優化
當資料庫的資料間插入時，可能會導緻索引的分裂，這個操作在MySQL裡其實非常重要。我們在這塊做了優化之後，大幅減少索引分裂的機率和深度。這裡的深度是防止這種情況從葉子間裡一直分到根，導緻層層傳遞上去裂變惡化，這樣帶來好處是50%的TPCC性能的提升。
上圖是一個測試，在實驗室裡我們可以把MySQL TPCC的值壓縮到39萬，左邊是真實運作的截圖，這表明壓縮資料是真實的。右邊是我們的檢查測試，可以看到索引鎖優化對檢查也有幫助，可以要到100萬Point Select。
2. Binlog In Redo
Binlog In Redo技術可以提升Commit的效率。
MySQL為了保證資料的一緻性，它要求Redo Log和Binlog要同時刷出去也就是Redo Log和Binlog的兩階段送出機制。當一個事務開始之後，到送出階段首先會Flush RedoLog，這個會設計成Release Lock。接下來會Flush Binary Log，也設計成Release Lock，然後才是真正的鎖釋放。我們在使用存儲或者雲盤時，可能會讓性能會變得不那麼理想。
我們研發的Binlog In Redo解決了這個問題，我們把Binlog先寫在Redo裡，隻要刷一次Redo之後便可以保證後續的Binlog不會丢失，是以使用者真正需要的Release Lock隻有一次了。
如上方左邊的流程圖所示，使用者在一次Release Lock之後，就可以把整個事務鎖中的鎖釋放，提高了Commit的響應速度，也更早的釋放了鎖的資源。
這個帶來了幾個好處，一個是增強事務并發性，另一個是使用者事務送出的性能得到提升。在我們的測試中，性能可以提升25%左右，适用于任何場景。
3.高效查詢緩存
MySQL本身具備查詢緩存功能，這裡說我們重新研發的原因在于社群8.0把查詢緩存剔除，我們覺得緩存其實是個非常好的東西，是以我們在8.0基礎上重新研發。
如上圖左邊所示，如果沒有緩存的時候，一條SQL語句進來要經過解析、檢查權限、優化器對SQL進行分析，得出執行計劃，然後真正的執行。執行過程中可能涉及事務引擎，還可能通路磁盤上的資料，是以說這個鍊路非常長。
我們這裡的查詢緩存是對結果起的一個緩存，是以我們稱之為Consistent Result Cache。Consistent是跟事務機制結合在一起，意味着從緩存查出來的資料滿足事務隔離級别。
我們在4C8G的機器上測試時，發現可以有100%的提升。我們測試了三個配置，第一個是将MySQL原生查詢緩存關閉的情況下，在最高峰值的時候同比其他配置不足一半。
中間橙色是MySQL原來的Query Cache，這個是我們在5.7版本上做的。原來Query Cache因為設計比較陳舊，是以他在應急下其實起到反作用,這也是社群8.0将它去掉的原因，但是我們解決其中最關鍵的問題，設計了一個獨到性的緩存維護與更新維護機制，達到100%的性能提升。目前查詢網站已經可以自己開啟了，這些開啟的參數都在控制台進行修改，可以直接啟用。
4.多塊讀
我們通過深入的代碼閱讀和分析，發現MySQL在處理RL的時候，基本上都是逐塊讀取。例如要查詢一張大表，或者要去Optimize打表，或者對于這個表加一個索引時，會發現系統會逐塊讀取與處理，這個過程十分浪費時間。我們考慮到可以在讀第一個塊的時候，将後續的塊也讀進來，我們将這個稱為多塊讀。
如上圖所示，我們做了個測試。上圖左邊這是一個10G的表，采用原來的機制耗時115秒，右邊為使用多塊讀技術，我們發現即使在AIO關閉的情況下，耗時仍會從115秒縮減到67秒。而當AIO打開的時候，由于本身對AIO有合并作用，提升效果更加明顯，從115秒縮減到43秒。
（三）穩定性
l 穩定性方面實作了四個功能：
1）快速DDL；
2）性能監控插件；
3）BP動态伸縮；
4）頁面淘汰優化；
1.快速DDL
以前有使用者過來找到我們，表示在高業務環境下做的DDL抖動很大。我們發現在MySQL的Buffer Pool中，很多表或者索引的資料是混合存放在同一個Buffer裡。當使用者要做DDL的時候，可能要把整個Buffer Pool掃描一遍，掃描效率很低。基本上所有的DDL、對表、進行重組等操作都會有這個過程，過程十分緩慢。
是以，我們在Buffer Pool加入一個新的導航機制，使用者可以快速定位到相應的操作對象，掃描效率得到大幅度提升。
上圖是一個測試的場景，是一個24G的Buffer Pool，Instances是4個。我們開啟了一個壓測，128張表，每張表200萬條資料，然後在過程中做Export Tables，這個操作會把Buffer Pool描儀一遍。當沒有快速DDL特性時，過程耗時80.51秒，當有快速DDL後，過程耗時0.34秒，對比顯著。
目前快速DDL在RDS 56/57/80預設開啟，是一個非常流行的全網功能。
2. 性能監控插件
資料庫中我們會經常遇到一些新的問題需要去分析，此時一個實時的性能資料就顯得尤為重要。
一般情況我們會登到MySQL中用“show global status”來檢視，但“show global status”執行成本高昂，很難保證每秒鐘都有新的資料輸出。是以，我們将性能資料的收集做到核心中，然後從核心的角度，可以直接讀取記憶體位置，然将資料寫到檔案裡，這樣可以做到每秒鐘一個資料，無論負載情況如何，基本上都非常準時。
這些資料有兩種存儲方式，第一個是存在格式化文本檔案裡面，我們采用三個檔案，每個檔案到100MB就切換，這樣可以對過去的性能資訊進行回溯。
另外我們提供了一個記憶體表，這個表的可查詢時長是可自定義的，使用者可以直接通路這些表。例如上圖右上方的曲線，我們把對執行個體的Select、Insert、Update、Delete和Query語句，用曲線畫出來這些資料。使用者們都可以通路，當大家在分析新問題的時候，我們可以跟使用者基于同一份資料來進行交流，加快問題分析的速度。
3. BP動态伸縮
我們發現，對Buffer Pool進行伸縮調節的時候，擴大沒有問題，但縮小的時候會有很大問題。
我們為什麼要調Buffer Pool？MySQL記憶體使用分成兩塊，一塊是資料記憶體，一塊是程式，每一個規劃都會用到一些記憶體。當連接配接資料多的時候，其實Buffer Pool需要調小一點，當連接配接數比較少的時候，Buffer Pool可以調大一點，動态的Buffer Pool機制能夠更好地利用記憶體，是以我們需要解決Buffer Pool動态伸縮的問題。
上圖為一個測試，綠色線是原生的MySQL，我們在做Buffer Pool縮小的過程中，發現它抖動得非常厲害，很多時候甚至可能會跌到底，我們對這個問題進行深入分析，并進行技術突破。
藍線是BP動态伸縮的技術下的回報，雖然也有抖動，但抖動幅度大幅減少，最壞的情況跌20%。這個測試是在業務高峰時段進行，如果在業務不那麼繁忙的階段，我們有信心做到沒有抖動。
4. 頁面淘汰優化
我們發現，當MySQL在記憶體緊張時容易引入單頁淘汰，也就是當要讀一個資料塊時，如果在記憶體裡找不到空的資料頁，則會淘汰一個資料頁。
此時是逐頁淘汰，效率非常低下。在這裡我們做了一個機制改進，将淘汰一個頁的機率降到最低，提升了淘汰頁面的效率，用同時淘汰多頁代替逐頁淘汰，性能得到大幅提升。
上圖為一個測試，4條線是2種場景，上面兩條線是測試，沒有打開範圍查詢。
高的線是我們頁面淘汰優化之後的線，相比優化前提升了20%。下面兩條線是打開範圍查詢的情況。由于它有些SQL較為複雜，會查詢比較多的記錄，是以QPS會低一點，我們發現提升幅度也是差不多在15～20%。
資料庫資料大于記憶體是一種常态，是以這裡的優化是很大的提升，意味着可以用更低的資源配置得到更高的CPU，有效節約了成本。
（四）安全性
l 安全性實作了三個功能：
國密(SM4)支援；
防删表保護；
DDL資源回收筒；
1.國密(SM4)支援
由于資料安全風險很大，國家對加密算法也有一定的要求與标準，是以我們增加了對國密SM4算法的支援，這點就不展開詳細講述了。
2.防删表保護
2020年的時候，業内發生數件資料庫表被意外删除的事情，阿裡雲居安思危，未防止此類事情發生，我們設計了一個防删表的功能。
這個功能可以設定删除表的權限，例如需要收到某個使用者的指定賬号，或者要Super權限，或者需要通過内部管控平台操作，或者要求删除操作隻能在本地登入進行，通過不同的權限設定可以起到不同的安全級别效果。
從保護内容方面可以分為兩類，第一類是資料類的，包括Drop Table、Truncate Table、Drop Partition、Truncate Partition、Exchange Partition和Drop Tablespace。還有一類是對存儲過程、視圖以及定義的保護，當用他人想用這個級别的時候，使用者可以禁止他人删除視圖的定義、存儲過程、觸發器，甚至可以禁止删除Binary Log。
多樣可選的設定相結合，可以起到很好的資料保護作用，確定使用者的資料庫安全運作。
3. DDL資源回收筒
出于對DDL方面的考慮，我們做了個DDL資源回收筒。
如上圖左邊所示，在AliSQL 8.0版本資料庫中，我們有一個“recycle_bin”保留資料庫名字，字面意思是資源回收筒。
資源回收筒這個概念大家非常常見，DDL資源回收筒的概念與Windows資源回收筒類似，但我們對資源回收筒的權限做了特别的控制，需要有特别的權限才能進行徹底删除。
在AliSQL 8.0中，當開啟資源回收筒功能後，使用者的删除操作不是直接将表删除，而是将這些表先移到資源回收筒。
上圖右邊一般來說沒有權限，它需要擁有更高的權限之後才可以進行删除操作。通過這樣的兩級機制，可以有效防止表被删掉。當使用者不想開啟防删表政策時，可以開啟資源回收筒，當使用者發生誤操作、誤删表時，可以從資源回收筒快速找回資料。