大家好，我是MariaDB的 Michael Widenius，我們今天來簡單的聊下MariaDB10.5新特性和即將要做的事情。10.5已經是RC了，應該是下周四GA，所以非常近了。

Monty分析MariaDB10.5新特性_騰訊視頻 v.qq.com

Monty全程分享視頻

從我個人加到MariaDB的特性開始，這也是我現在依然寫代碼的地方，差不多我花了我至少一半的時間在做這里。實際上在COVID-19期間，我花了90%的時間在做這里，這還是很好的。

其中一個我加到MariaDB10.5的就是S3引擎，這也是我被用戶要求要提供一個解決方案的地方，它將幫助用戶把歷史數據存儲在便宜而可靠的存儲上面。S3是一個只讀的engine。

存儲在S3上的是可選壓縮，去減少一點存儲空間。重要的事情是多種存儲，但每個地方都能很好運行、復制，所有的keys。這是非常常規的東西，你平時在用，但一般不注意。

所以，表轉換這里，你可以把表直接Alter成S3的表，或者改回來。你可以有主和備，他們所有都是不同的，這展示的是正常的復制的工作，有趣的事情是S3是共享存儲，可以讓主從都用同一個S3 。所以當主(指的MariaDB的主) 改變后，備不用做什么也能直接讀到信息。

你可以任何時間在MariaDB上加server。他是自動發現的，所以你要做的唯一事情是slave加認證，然后就可以訪問所有的在S3的表了，不需要做復制，自動感知變化。

到現在為止，我們在MariaDB對MySQL做了很好的兼容，所有的命令，命名等，幾乎所有東西都一樣。一個可以區別的是他們二進制名字，10.4是軟連到MariaDB，10.5改為了二進制是MariaDB為前綴，但依然有老的軟連接，保證老的腳本和其他東西運行。一個大的改變就是在進程里面，你看到的是MariaDB，而不是MySQL了 ，這可以讓你同時運行MySQL和MariaDB，你就知道誰是誰了。

我們有一些擴展的DDL語法，首先是我們對于create database語句加了 comments，我們讓table更容易去使用和rename，也做了一些在alter table 和rename table上的代碼修正。我們需要在strict 模式下做table的復制，引擎自動的加if exist到binlog去，所以slave知道是否要跳過，因為他可能不存在是一個share table。

我們已經有returning了，但這次加了insert 和replace的 returning 語法。returning的意思是你可以獲取改變的內容返回到客戶，所以在insert里面就意味著 插入的數據集都可以被返回，（有時候）可能很重要，例如：

有數據列和元素在replace下，有些會被刪除，有了retuning，你就知道了哪些其實不是insert進的（因為replace帶有插入和替換兩層意思，就是說可以區分 哪些是真的replace，哪些是insert的）。

我們也對于Except 和 intersect 加了對于ALL的語法（也就是說 可以去分集合運算不去重了），這是MariaDB特有的，MySQL沒有。我們也做了一些易于MySQL8.0遷移到MariaDB的工作，你也許知道，我們有不同的方式去存儲數據，mysql這方面做了一些奇怪的工作，所以我們在塊和磁盤的層面不兼容MySQL8.0，但SQL的層面是兼容的，所以大部分應用遷移到MariaDB很容易。

但若要升級，我們做了不少工作讓用戶從其他版本升級到10.5很容易，不需要改變什么，自動工具升級。

我們有一些對master 和 slave 非常敏感的用戶，所以我們把show master status這個指令改成了show binlog status。

我們添加了新的支持JSON的函數，對JSON的支持更友好了。

很多人認為mariadb的超級用戶權限太超級了，獲得了太多的權限難以控制。所以我們把超級權限分割成了更小的子權限給人們使用。這意味著你可以單獨給某個用戶獲取binlog和binlog操作的權限，但不用把他提升為超級用戶。當然了，要使用這樣的功能，用戶需要做一點小小的權限改動來適配，在10.5版本里我認為這是唯一需要用戶適配的修改了。

我們這個版本里，對InnoDB進行了很大的迭代，我們有3個innodb開發，他們做了很多大的工作去改善innodb性能，讓它變得更快。同時有很多參數被刪除了因為他們幾乎沒有意義了，還有部分參數被調整了默認值。比如innodb_log_files_in_group，我們知道修改這個值到很高并不能達到任何改善性能的效果，所以現在它默認被設置為1。

這里所有的變量雖然不推薦（僅展示一部分）：
innodb_checksums
innodb_log_checksums
innodb_locks_unsafe_for_binlog
innodb_stats_sample_pages
innodb_undo_logs
innodb_rollback_segments
innodb_log_optimize_ddl

但依然可以在配置文件使用，啟動的時候在errorlog 里面會有warning日志。這對于清理這些配置是一個好的事情，我們相信升級還是很容易的，所以我們把這里做了修改。

現在你可以通過innodb status 去看innodb引擎的狀態，同時還有大量的性能改善，如果你從innodb舊版本遷移過來，你的感受會非常強烈。

這里我們會介紹一些改善的點。一個顯著的改動是新的線程池（不是連接的那個，是后臺線程池），以前啟動的時候，為了LRU開啟了很多線程，即便不使用也是如此。我們現在有了general的線程池，按需創建，不用會自動減少。

如果你使用的是NVDIMM持久性存儲，我們針對這一存儲做了優化，使用戶能夠直接把數據寫入持久性存儲來分攤文件系統的開銷。這一點使mariadb一些性能顯著提高了，基本上sync到日志文件的開銷降到了0。mariadb會時刻保持更新，和最新的硬件兼容。我們也和cpu的供應商有合作，比如ARM，來確保mariadb能很好的和arm兼容。

我們收到的關于10.4的抱怨之一，是我們的新特性都是基于mysql 5.7 performance shcema，現在mariadb對此作了修復，因此performance_schema表可以提供更多mariadb的信息。和mysql5.7相比，之前我們已經有很好的數據接口來使用內存，現在我們也支持了mysql5.7的接口。

我在使用mysql的時候,尤其關心的是性能。MySQL之所以這么受歡迎的原因之一，也是因為他相較于其他數據庫有更好的性能。我們在MariaDB 10.5中保持了這一優勢，我自己寫了新的二進制文件記錄的代碼，值得注意的是，改進后的二進制文件比原來更小，處理起來也速度也更快了。我也做了一些范圍優化器的改進，移除了10.4版本中的一些優化器的小問題。同時，我也改進了優化器，使得開銷能更好的和不同引擎匹配。

例如對于MEMORY引擎來說，即使數據存在內存里，也會像數據存儲在硬盤里那樣來計算訪問開銷。這個問題在10.5版本中得到了解決，Mariadb知道存在內存中的表處理會更快，并且更加精確的計算memory表的開銷。

我一直在強調和mysql相比，mariadb能非常快的連接到服務器，在SQL中我們能更快的從服務器連接到客戶端。10.5中我們更是把連接速度提升了25%。這也是為什么很多用戶不像在mysql中那種用連接池來提升性能，因為mariadb中的數據庫連接本身就很快了。

當然，在很多不需要使用密碼來訪問數據庫的場景中，我們使用了特殊的邏輯來處理這種內部的使用，使得數據庫連接的速度更快。

10.5中我們對Galera做了許多改進，其中最重要的一個就是mariadb支持了Global Transaction ID。因此現在Gerlera支持mariadb最新的全部特性，這使得Gelera的使用更方便也更安全。

關于主從復制，我之前提到過REPLCA已經支持在SQL語句中作為SLAVE的同義詞。同時我們也擴展了binlog的元數據以包括新字段。在mariadb 10.5和之后的版本中，添加新的數據類型會更方便。

但是如果你的主從中包含不同的數據類型，我們需要知道更多的信息，比如原始列的信息，來處理更多復雜的情況。新的元數據使得復制和之前相比更安全了。我還提到了IF EXISTS，我們可以在S3引擎中使用IF EXISTS來代替寫和修改查詢。我們有標識來區分他是否含有隱式的EXISTS。

關于優化器，我們做了很多內部處理來使得優化器更可靠。更合理的部分是，anlyze語句分析了更多的信息，optimizer_trace比原來更快了。我們在使用文件排序的時候，使用的磁盤空間也更少了。如果你用varchar作為文件索引，在之前的文件排序中，會給每一行都用到這個文件索引。在10.5中，我們只存儲真正用到的數據，這使得文件排序中的VARCHAR，CHAR和BLOB更快了。

除了上面提到的這些以外，我們還有很多小的改進。我們更新了正則表達式的庫到最新的版本。把Aria引擎中鍵值的長度從1000 bytes增加到了2000。這是很重要的，因為S3存儲引擎是基于Aria代碼的，我們有用戶想要把引擎轉換為INNODB，他們在S3中有非常長的鍵值，我們這個改進主要基于這一點。

10.5中新增了很多新參數，因為實在太多了，我就只在這里放了鏈接。Knowledge Base( http:// )上有最新功能的文檔說明，大家可以去Knowledge Base上搜索10.5，可以找到ppt里所有的內容。

10.5發布之前我們還有一些想要加進去的特性。在GA之前，我們會把哈希連接的使用加進去，其實在10.4和現在的10.5版本中，我們已經支持了哈希連接，但是用戶需要設置一些參數來使之生效。我們還在開發優化器引擎，讓他自動檢測何時使用哈希連接會比普通連接性能更好。

有一些情況下哈希連接始終比普通連接的性能好，比如在沒有可用索引的情況下，我們會在10.5中自動使用哈希連接。如果用戶忘記添加索引，10.5版本的處理速度會比10.4快很多，因為系統自動使用了哈希連接。

列存引擎在10.5中發生了很大的變化，我沒有在這一頁中添加過多的內容，因為列存這個話題可以作為一個完整的話題來分享。有趣的是，列存引擎中，每一列都作為單獨的二進制表單獨存儲。列存引擎是專門用來做分析型查詢優化的分布式引擎，可以很快的分析處理pb級別的數據。

在mariadb10.5中，列存引擎是可插拔的形式，他有自己的rpm安裝包，用戶可以很簡單的在服務器中添加、刪除。這也使得我們對mariadb列存的優化和貢獻變得更簡單，因為我們不需要單獨的二進制表。

我不知道大家是否關注了我們的新聞，大約一年前，mariadb收購了存儲引擎Clustrix，一個支持事務的分布式存儲引擎。有趣的是，因為clustrix的分布式特性，它可以處理無限制的寫請求。

比如用戶有一個集群，集群里有三個存儲節點，用戶增加了三個節點之后，寫請求也會翻倍。這個特性會在SkySQL的第一個版本中發布，SkySQL是mariadb下的一款云數據庫產品，我們還在決定如何把這個特性加入mariadb的社區版本中，據我所知現在的計劃是，用戶付費之后就可以使用clustrix所有的特性，社區版還需要一段時間才能發布Xpand。

我們很高興騰訊對mariadb做出了很多代碼上的貢獻。mariadb和mysql現在最大的區別之一就是mariadb和社區更好的互動，并把大家在代碼上的變更和貢獻合并進來。我們很高興騰訊就是很大的代碼貢獻者之一，我們希望之后騰訊能對mariadb有更多的貢獻。

這里有一些騰訊貢獻給mariadb的特性：
壓縮二進制日志中的事件，使binlog更小了；我們和騰訊一起做了列存壓縮，這一點mysql是不支持的，mysql的一些版本中支持類似的部分，但是也是有限制的，騰訊在列存壓縮上特性上對mariadb做出了很大的貢獻。

對于InnoDB秒加字段的特性，我們也用相同的模式做了改進。騰訊在mariadb DDL之前就發布了版本支持秒加字段，剛好騰訊相關的開發人員參加mariadb在中國的會議，會后我們和騰訊的研發一起探討了騰訊是如何實現秒級加列特性的，并討論我們能否在這個基礎上做一些增加和改進。

這部分工作完成在mariadb 10.3-10.4的版本中，但是在10.4版本中，基于之前的這部分代碼我們增加了很多秒級特性，許多innodb里alter table的操作是秒級的，可以在用戶對數據庫離線無感知的情況下增加、刪除列。

幾周之前我收到了很多代碼貢獻可以加進mariadb 10.5中去，DROP TABLE FORCE是我親自實現的一個功能，我的任務是保證這一特性會以某種形式添加進10.5中。這一頁中其余的一些代碼貢獻都和Marcel(mariadb開發人員)正在做的10.5版本中的特性有關，我們希望這部分能順利加進10.5，如果不可以，那么將會在10.6中發布。

刪除大表優化在我們收到代碼貢獻之前就已經由Marcel的團隊實現了， 他們會參考大家貢獻的代碼，從而在終版中得到最好的特性。