MariaDB 11.0 – 新的优化器，新的主版本系列
MariaDB 10.0.0 已于十多年前发布（2012 年 11 月 12 日），您可能会问自己 MariaDB 11.0.0 何时发布。如果是这样，我可以回答您：就是今天。
您现在可以从我们的专用下载页面下载 MariaDB Server 11.0 Alpha 预览版，并查看发行说明。
时光荏苒……
当然，我们使用新的主版本号，不仅仅是因为已经过去了十年。更重要的是有显著的新功能。与早期版本有显著的不兼容性。或者其他一些客观原因。
……而且我们已经达到了一个重要的里程碑！
我们很高兴 MariaDB Server 达到了一个新的里程碑。此版本中的大多数更改直接源于我们的用户向我们报告的性能问题，通常表现为糟糕的查询计划。我们的社区深入参与了此版本的开发指导。
优化器的新成本模型
MariaDB 11.0 的旗舰功能是新的优化器成本模型，它能够更准确地预测每个查询执行计划的实际成本。但是，由于我们不能确定它在所有场景下都更好，因此我们提高了主版本号，以发出信号：如果某些意外的查询变慢了，请不要惊讶。
我们的三点信息
我们的核心信息有三点
- 社区帮助我们识别优化器问题。
- 我们倾听了意见，现在有了一个解决方案，使 MariaDB 的优化器与 2022 年的硬件保持一致（“硬盘”已今非昔比）。
- 我们希望社区开始使用此更改，并向我们提供更多**反馈**。越多越好！您可以通过jira.mariadb.org的错误报告、Zulip或maria-discuss和maria-developers邮件列表与我们联系。
改进的是复杂的查询
大多数查询不受影响——特别是那些简单的查询，最多只有一个连接（join）。在 100 个查询中，可能有 10 个会使用不同的计划执行，也就是说基于表中的实际内容、行数、可用索引，以不同的顺序执行。在这 10 个受影响的查询中，我们预计有 9 或 10 个会更快。
更多内容将在后续博客中发布
成本模型的更改将在后续的博客文章中详细描述，这是一项历时 12 个多月工作的重大改进。这项工作主要由我们的创始人 Michael “Monty” Widenius 完成，并得到了 Sergey Petrunia 和 Vicențiu Ciorbaru 的大力支持。
10.11 和 11.0 之间的不兼容性
10.11 和 11.0 之间也存在一些不兼容性，我们将在适当时候列出并在博客中进行介绍。我们一直想实现这些更改，但如果不更改主版本号就无法引入它们。
重新审视重新编号的标准
由于所谓的新功能和不兼容性重要性的“客观”标准并非黑白分明，我们将重新审视我们重新编号第一个版本的标准。可以肯定地说，我们确实希望您能在现在起的 10 年内（2032 年）之前看到 MariaDB 12.0.0。欢迎提供见解和评论！
最重要的是：好消息——性能提升！
总而言之，我们认为有充分的理由下载 MariaDB 11.0 并检查您的查询是否运行得更快。特别是对于那些一直使用 FORCE INDEX 来通过向优化器提供使用哪个计划的提示来提高执行速度的用户。
体验“数值达到十一”
附注：对于英国流行文化和/或虚构重金属乐队Spinal Tap的爱好者：期待您体验 MariaDB Server 的AMP 达到 11。
令人高兴。
我曾深入参与 MariaDB 的实现，共同创立了交付 ServiceNow 目前在生产中使用的分支的团队。
我的工作使我对 Innobase 的实现历史进行了深入研究，从 10.1 到今天。
我对你们的事业深表同情。把它做得棒极了！
我希望过去我们看到的复杂性带来的恐惧能够消失——例如 10.4 由于 push down select 的类型系统降级而带来的不成熟性，以及 instant alter table 的复杂性，AHI drop = O(N^whtevs)，粗粒度互斥锁，未编译的 where 子句 AST cliffing 分支预测，通过 mmap/fsync 的 b-tree 访问瓶颈，尤其是在用户空间 NVMe 多页原子写入显而易见的情况下。这个列表每天都在变短！
编译庞大的代码库，以及对于任何大规模堆（一个能填满整个机架的 DDR）来说，时间上实现健全的堆（在 500G/80T 白热化堆上的 MTR 健全性？）语义仍然是一个巨大的挑战。
同样值得注意的是，打造世界上最好的关系型堆的指令和追求通用云业务的愿望削弱了产品和业务；应该无情地剔除在 21 世纪时代精神中收集到的 junksQL 插件。
如果未能做到这一点，可能会让 SQLite 的衍生产品抢占你们的市场份额。
2023 年的另一个机会是缺乏从数据库到与 Samsung Xilinx FPGA 协同放置的存储阵列等集成解决方案，以实现页面内容的渲染，并通过 PCIe 总线传输到内存。
如果在靠近存储的地方编译 WHERE 子句，通过 PCIe 总线实现 100% 的选择性是可能的，尤其是在我们拥有 uring i/o 的时代。
这可能反映了下一代隐喻，或是给了 MariaDB 在 2012 年竞争优势的原子写入 Fusion I/O 时代。
我注意到 FPGA 的讨论也出现在网卡周围，用于 CPU 卸载内存中的投影，以及 CPU/FPGA 本身（RISC-V B树扩展）用于加速单线程下的并行连接，或者通过查询计划的数据路径工程提供基于索引的寻址等。
将 B树 规范化卸载到 FPGA 算法。各种各样。
另一个机会是使用与存储协同放置的 FPGA，将 B树 内容以列式存储布局呈现，为事务存储提供 SIMD 执行或有些人所说的“分析查询能力”。
这可能会消除由 HTAP 思想导致的后端、复制的疯狂需求，以及仅为向 SIMD 单元呈现页面而存在的插件。
在需要列式布局将 B树 页面呈现给 SIMD 单元的情况下，插件架构固有的架构问题，即每个存储引擎的工作集分割主内存总是损害纯 Innobase 的性能，现在已经消失了，一个单例存储引擎可能通过靠近存储的 FPGA 更好地控制 B树 范围的列式投影的相对重要性。
计算连接也必须扩展到机器学习符号和点积排序——如果希望将 chatgpt 或图像相关性识别集成到关系型查询中，而不是创建客户端连接，那么每个组织的 AI/ML 都必须与连接层以下的数据库集成。
我相信 ServiceNow 和你们其他最大的社区客户在 2023 年能够绝对高效地备份和恢复大规模堆，并且围绕这个敏感问题的信任问题能够得到解决。
在业界最高层面，如果这方面不是领先且无瑕疵的，你们的声誉就会受到威胁。
不过我必须说，恭喜这是一个伟大的成就，我在 sql_select.c 的深处有着丰富的经验和恐惧。祝 MariaDB 在 2023 年好运！
你好！
Matthew Hastie，感谢您提供了许多有趣的思考和想法。
对部分章节的一些评论
我认为普遍尝试这样做会遇到一些问题
在大多数实时场景中，大部分活动数据都由数据库缓存，因此使用 uring 不会有太大帮助。
在块读取层面，关于读取了什么以及如何解释的信息非常少。
在没有上下文的情况下对块应用 WHERE 子句，以及当一个记录的数据经常分散在多个块中时，这样做非常困难。
更复杂的是我们的 B树 是非内存可比较的（因为我们想支持仅索引读取）。例如，MyRocks 可以支持用于排序和 SST 文件合并的硬件加速部分，因为它以内存可比较的形式存储数据。然而，这意味着不能将仅索引读取与 MyRocks 一起使用。
唯一可能有用之处在于对整个表进行扫描时。然而，更好的选择可能是应用 MIN/MAX 索引、布隆过滤器或其他块过滤机制，以便根本不必读取/检查不包含任何相关数据的块。
并行查询是 2023 年的议题。我们有非常大的 MariaDB/MySQL 用户已经在 MySQL/MariaDB 中实现了这一点，我非常希望他们中的任何一个能将他们的代码捐赠给 MariaDB。如果不行，我自己会考虑为 MariaDB 11.1 或 11.2 实现这个功能！
这里的问题是 B树 的代码并非完全通用和隔离。由于用户可以在索引中包含任何类型和字符集的组合，大多数 B树 代码都调用子函数来比较事物。B树 代码还依赖于事务的状态，例如事务可见的内容、可以删除的内容等。B树 代码性能很大一部分在于锁定 B树、复制块（以允许多并行访问等）。我不知道 FPGA 在这方面能帮多少忙。对于只存储一种类型（double？）的 B树 来说，我认为实现 FPGA 解决方案会相对容易。但是，在一般情况下如何高效地做到这一点，我并不知道。
对于聚簇索引来说，这可能是可行的。然而，这并不会带来太大的性能提升，因为仍然需要读取所有块，包括不需要的数据。
列式存储布局的最大优势在于每次块读取都能获得更多的行，并且在压缩方面有很大的优势。例如，MariaDB 列式存储一次读取兆字节大小的压缩块。在普通 B树 上工作的 FPGA 无法与之匹敌！
我希望您已经看到了我们在 11.0 中为改进它所做的所有出色工作！至少，我希望您过去经历过的一些“恐惧”现在已经消失了！
此致，
Monty