MySQL之父解读数据库最新亮点

大家好，我是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的团队实现了， 他们会参考大家贡献的代码，从而在终版中得到最好的特性。