MySQL 8.0 InnoDB 有哪些新特性？

毕竟MySQL 8.0是一个非常大的版本变化。我们从 5.7 直接跃升至 8.0。随着版本控制规则的变化，我们在产品开发过程中将会有与过去不同的路径。

我今天的演讲主要分为这几个部分。首先是功能改进。主要讲MySQL8.0中的InnoDB。我只谈论 InnoDB，因为我属于 InnoDB 组。 InnoDB在MySQL8.0中提供了哪些功能。

第二部分，InnoDB在8.0版本中所做的性能改进。

对未来也有一些展望。我今天讲的东西，我今天讲的功能和性能改进只是我们8.0代码中已经存在的功能。未来8.0版本可能会添加一些新功能，我们会在以后介绍。

第一部分，功能改进，功能改进的第一个最大变化，在8.0版本中，我们重构了InnoDB中的数据字典。大家应该知道什么是数据字典，什么是表结构，你的用户定义，所有与DDL相关的东西都放在数据字典里。

为什么我们需要进行这样的重构？因为在8.0、5.7、5.6以及更早版本之前，问题有多大？ MySQL 有两套数据字典。这两套数据字典，一套位于MySQL层，一套位于InnoDB层。

MySQL层将这些数据字典存储在哪里？只需将其放入 .frm 等文件中即可。

InnoDB位于哪里？ InnoDB位于它自己的数据表中。这有什么问题吗？

首先，它不支持原子操作，即DDL不能执行原子操作，但InnoDB表可以。由于不支持原子操作，所以两组字典不匹配。

同一张表的表结构在MySQL中可以是一种结构，在InnoDB中可以是另一种结构，这会导致数据字典不一致的第二个问题。

第三，在处理DDL并发时，我们必须非常小心，因为两组数据字典的并发机制是不同的。

InnoDB使用dict_sys::mutex进行同步，但是MySQL层使用MDL，这更容易导致死锁，因为里面混合了两种不同的锁定机制。

最后可能发生的问题是表在失败时无法恢复并且表结构已损坏。

这是我们很久以来想做的事情，直到8.0才完成。在8.0中做了这样的改变之后，我们得到了这样的好处。

首先，数据字典只有一份。其次，它支持原子操作，不会再出现不一致的情况。第三，我们支持事务性DDL，这意味着您创建的DDL支持所有事务的ACID功能。

第四，数据字典仅存储在InnoDB中。正如我刚才提到的，我们使用相同的锁机制来管理这个数据字典的并发控制，即由MDL来管理。至于.frm文件，我们基本上已经删除了。 8.0 中可能仍然存在残留的 .frm 文件，但我们基本上已将其删除。

所以这是我们在 8.0 中所做的一件相当大且基本的事情。

但是你可能对此没有太大感觉，因为你通常不会遇到这个问题，但是当你遇到这个问题时，它可能是一个大问题，因为你的桌子损坏了，桌子的结构也损坏了。

为了避免以后出现类似的问题，我们做了这样一个非常基础的改进。

这是示意图。在8.0版本中，我们直接编写，直接访问InnoDB数据字典。和原来5.7访问FRM文件一样，也是访问InnoDB系统表。这张表比较直观，告诉大家原来的数据字典以及数据字典现在的情况是怎样的？

我刚刚讲完第一个重大改进。值得注意的是，这一重大改进最终是由中国团队完成的。我们大约有四个中国人完成了这个伟大的任务。

我们中国的合作伙伴也有快速添加字段的功能，但不是官方的。原始补丁由腾讯团队提供。他们提供了初步修复。我们改进了它并将其合并到我们的版本中。这个功能非常实用，任何人都可以经常使用。

我现在很想在应用系统表中添加一个字段，但是原来的字段呢？添加字段需要等待，这可能需要很长时间。这将需要创建一个新表，然后复制原始数据。

现在不需要了，我们可以快速添加字段，无需重建表或复制数据。

发送命令添加字段，它会立即返回。为此，我们更改了页面结构和数据页结构。它可以告诉我们您是否添加了字段记录。我们针对两个不同的版本有不同的处理方法。这就是此功能的目的。这是非常实用的。以后使用8.0版本的时候会经常用到这个功能。

从官方安全的角度来看第三个功能是加密。该功能是5.7中加密功能的延续。在5.7版本中，我们提供了表数据加密。大家都知道它包含在 5.7 中。

在后续的功能实现中，我们对redo-log和undo-log进行加密。如果不加密的话，我会插入一个与张三同名的人。这些数据进入这两本日记的时候，也会包含张三场的信息吧？

所以我们对这两个进行加密会更安全。你拿到他的数据是没有意义的，对吧，因为它是加密的。

通用表和共享表空间应该已经完成​​了，可以在新的8.0版本中看到。我有一些共享表空间。要知道，一个表空间中可以建很多张表。之前我们的加密只支持一张表和一个IBD文件的加密。现在我们也可以对其进行加密。

另一个功能是Memcached以及自动增量列的改进。大家都熟悉Memcached，它是一个缓存系统。您可能不熟悉 Memcached InnoDB 插件。据我了解，这个功能可以少用。

这个插件提供了一种直接访问InnoDB的方式，不需要通过上层去解析这组东西，通过API直接访问InnoDB中的东西。

在8.0版本中，我们改进了这个Memcached插件，这意味着我们现在可以支持多个get和range查询。

最初，您只能使用此方法搜索一个点。现在输入范围。我想找到所有大于5小于100的数据。所有值都可以找到。你现在就可以做。

第二个功能是自动增量栏的改进。我们如何记住自动增量列的当前值？我们真的不记得了。我们不知道自动增量列的当前最大值。

我们怎么知道？每次重新启动或打开电子表格时，您只会获得自动增量列的当前最大值。这会导致一些问题。有时，自动增量列会重复，或者您会看到不同的内容。

现在我们把它放入数据字典中，这样我们就无法再找到自动增量列的当前值了。

信息模式也发生了变化，例如添加新信息以访问当前信息并了解模式的当前状态。我不会那样做。

我刚刚谈到了8.0中一些比较重要的功能改进。以后我会讲讲其他可以提供的更重要的功能。

接下来第二部分，我会讲一下InnoDB在8.0版本中的性能改进。

第一个也是最重要的性能改进是并行重做日志写入。事实证明，写入重做日志是InnoDB的瓶颈。为什么？因为大家在做DML的时候都要写redo log。

重写日记。在高并发的情况下，如果每个人都写重做日志，就会产生冲突。这个时候你的写作不会那么流利了，是吗？

我会被困在哪里？他们陷入了日志缓冲区写入步骤。日志缓冲区有一个大的互斥体来保护日志缓冲区。我们在 8.0 版本中删除了它。

现在我们使用一种不需要锁的算法来写入重做日志，我们预先为每个日志分配一定的日志缓冲区，并通过LSN分配这些缓冲区。

这样就不会捕获日志缓冲区并预分配部分日志缓冲区。只需写入日志缓冲区的这一部分即可。这大大改善了日志写入瓶颈。

如果你想估算一下改进的程度，你可以看看我们测试同事部门的网站。其专门网站分析测试结果，在高并发情况下性能提升至少50%。

特别是当您的线程数不断增长时。过去，线程越多，达到某个峰值时性能曲线就会下降。现在它会上升，特别是当有128个并发线程时。你可以看到点击这条曲线。

第二部分性能提升是以下三点。第一个是基于成本的优化，它提供一些统计信息，例如索引中内存中的页面。这些信息提供给优化器，让优化器看着我。目前哪个指标比较合适。

percona 提供了另一种方法，可以删除缓存堆栈并将其拆分为多个。还有优化的阿里巴巴日志修复。

还有这种根据桌子ID进行的清理。我们按表 ID 进行分组，以减少多线程情况下的冲突。

删除时，二级索引不会立即删除。将出现一个标志，指示索引条目已被删除。好处是我可以提高数据删除的速度。

但是这些数据什么时候会被删除呢？这个清洁线程就可以做到这一点。查找二级索引记录中所有带标记的记录以及可以删除的记录。然后它将删除所有数据。

原来在我们有这个功能之前，都是混在一起的，速度会比较低。现在我们将根据此对它们进行分组。当我们这样做的时候，速度会快一些，对前台线程的影响也会小很多。

接下来两个是死锁检测可以动态调整。我的猜测是相当多的人修改了这个死锁检测。这个东西对性能可能不会有特别大的影响。它只会在更极端的情况下影响性能。 。

除了这两个大块之外，我们将来可能添加到8.0的第一个功能是更好的表空间管理。我们的表空间可能看起来越来越像 Oracle。

例如，向表空间添加版本控制是相同的。我可以将不同格式的表和不同格式的页面放在同一个表空间中，以便将来可以提供功能。

还有一个表空间会描述它自己。当您将表空间移动到另一个位置时，您必须删除所有数据字典定义，对吗？不然你拿过来的时候都不知道这里的表结构是什么。样本。

以后我们可以使用SDI将你当前表结构的信息放入这个文件中，并使用这个JSON文件将其复制到目标。通过这个JSON文件我们可以知道表的结构。

此外，它还为文档和JSON存储提供了更好的支持。处理MangoDB，在处理大文本数据或者大BLOB对象方面比MySQL有更大的优势。 8.0版本中也进行了改进。块支持。

例如，在新版本 8.0 中，包含了对 BLOB 对象的更灵活的处理。编辑 BLOB 过去需要更改字段并覆盖整个 BLOB。现在不再需要了。如果我只改变部分数据，我可能只需要改变一小部分数据。

以后还会有这样的性能优化。在生命周期优化、不必要的去除方面，MVCC可以做出一些改进，死锁检测也会带来一些改进。还有文件系统更改和冲突保护。

下面是下载链接等方面，还有最重要的是，如果你想了解最新的8.0性能测试报告，可以访问我同事的网站，可以看到8.0最新的TPS和QPS是多少。

有了好的工具，还要根据业务优化数据库！尤其是大型数据库如何提高执行效率，满足业务需求！