CREATE USER语句 子句 作为 子句写入审计日志和一般查询日志 。（缺陷号 33184550）BY 'auth_string'AS 'auth_string'

以前，MySQL 用户帐户使用单一身份验证方法向服务器进行身份验证。MySQL 现在支持多因素身份验证 (MFA)，这使得创建最多具有三种身份验证方法的帐户成为可能。MFA 支持需要进行以下更改：

此外，MySQL Enterprise Edition 现在支持使用智能卡、安全密钥和生物识别读取器等设备对 MySQL Server 进行身份验证。这种身份验证方法基于 Fast Identity Online (FIDO) 标准，并 authentication_fido在服务器端和 authentication_fido_client客户端使用一对插件。服务器端 FIDO 身份验证插件仅包含在 MySQL 企业版发行版中。

多因素身份验证可以使用现有的 MySQL 身份验证方法、新的 FIDO 身份验证方法或两者的组合。有关详细信息，请参阅 多因素身份验证和 FIDO 可插入身份验证。（缺陷号 33159968）

在身份验证插件未对身份验证字符串执行散列的情况下，CREATE USER带有子句的语句会因错误而失败。（缺陷号 33125289）BY 'auth_string'

当表达式或模式无法转换为适合 ICU 正则表达式引擎的字符集时，正则表达式函数现在会报告错误。

此外，改进了几个几何函数中的错误检查。（缺陷号 33290245）

该gen_dictionary()函数现在将latin1其作为参数的字符集，并返回相同的字符集。（缺陷号 30389649）

否则相同的字符串，分别使用 ASCII ( ascii_general_cicollat​​ion) 和 UCS2 (collat​​ion ucs2_general_ci) 字符集与连接条件中的预期不匹配。（错误#104571，错误#33204161）

参考资料：另请参阅：Bug #24847620、Bug #30746908、Bug #32244631、Bug #32501472。

c1给定字符集 的默认排序规则cs和不同的排序规则 c2（即不等于 c1），然后该语句 CREATE DATABASE d COLLATE c2 CHARACTER SET cs创建了一个新数据库，默认排序规则设置为c1而不是c2。（错误#104504，错误#33183590）

InnoDB： 针对导致 Windows 上构建失败的 Clang 问题实施了解决方法（ Bugzilla – 错误 51538）。（缺陷号 33217633）

MySQL 现在可以使用 C++17 编译。以下最低版本要求适用于编译器支持：

特别是在 Solaris 上，GCC 现在是唯一受支持的编译器。已清理代码以删除针对 Sun Studio、Oracle Studio 和 SunPro 的改编和解决方法。（错误#32907274、错误#103757、错误#32907475、错误#32992125、错误#32992242、错误#33004840、错误#33086882）

以前，如果服务器将客户端限制为用于处理密码过期帐户的客户端连接的沙盒模式，则客户端可以使用该 SET 语句。这不再被允许。有关沙盒模式的更多信息，请参阅 服务器对过期密码的处理。（漏洞 #16369085）

YEAR值并不总是被正确解释。（缺陷号 33142669）

参考资料：此问题是 Bug #31994744 的回归。

重要变化：default_authentication_plugin从 MySQL 8.0.27 开始不推荐使用 该 希望在未来版本的 MySQL 中删除对它的支持。

该 default_authentication_plugin 变量仍在 MySQL 8.0.27 中使用，但与新系统变量一起使用且优先级低于新 authentication_policy系统变量，后者在 MySQL 8.0.27 中引入，具有多因素身份验证功能。有关详细信息，请参阅 默认身份验证插件。（漏洞 #27515356）

重要变化： 该BINARY运算符现已弃用，并可能在 MySQL 的未来版本中删除。使用BINARYnow 会导致警告。改用 CAST(... AS BINARY)。

BLACKHOLE存储引擎最大密钥长度已从 1000 字节增加到 3072 字节（与 相同 ）InnoDB。感谢 Adam Cable 的贡献。（错误#32788749，错误#103371）

新FIREWALL_EXEMPT权限使用户免于防火墙限制。例如，对于配置防火墙的任何数据库管理员来说，这很有用，可以避免配置错误导致管理员被锁定而无法执行语句的可能性。请参阅MySQL 企业防火墙。

该SPACE()函数没有正确处理某些大值或无符号值。（缺陷号 33180446）

在视图中定义的函数的解析过程中，函数参数并不总是被正确评估。（缺陷号 33142010）

参考资料：此问题是 Bug #29904087 的回归。

窗口表达式中的位函数断言位掩码的运行时大小不大于其解析时间大小。我们发现了一些违反此规则的行为，列在此处：

（错误#32922688、错误#33117410、错误#33275424）

参考资料：另请参阅：Bug #33516898。

keyring_hashicorp插件配置问题的 诊断已得到改进。（缺陷号 32075854）

EXPLAIN FORMAT=TREE现在显示比之前显示的关于范围优化器生成的扫描更精确的信息。特别是，子迭代器现在显式显示，并正确计时 EXPLAIN ANALYZE；索引范围扫描现在显示正在扫描的实际范围。输出中的描述也比以前更加用户友好；例如， index_for_group_by显示的查询使用 DISTINCT被替换为index skip scan for deduplication。

此外，导致读取范围交集扫描的行计数估计不准确的舍入错误已得到纠正，索引范围扫描的优化器跟踪现在可以 InnoDB在使用时正确显示主键中的隐式键部分。（错误#33037007，错误#33062448）

转换EXISTS为半连接时，以及查询包含视图引用时，查询处理不正确。（缺陷号 32813550）

参考：这个问题是 Bug #30671329 的回归。

在横向派生表的情况下，如果缓存无效器的创建被延迟，则在没有无效器的情况下发出表实现，这会阻止在执行期间发生重新实现并导致错误的结果。

只有当横向表的索引小于所考虑的表列表中最后一个表的索引时，才会发出挂起的缓存无效器。当挂起的无效器的表索引等于连接切片的最后一个表时，缓存无效器被跳过，并且在没有无效器的情况下发出物化。

如果挂起的失效器的表索引小于或等于当前连接切片的表列表中最后一个表的索引，我们通过创建挂起的缓存失效器来解决这个问题。（缺陷号 32407774）

为了协助监控和故障排除，性能模式检测现在用于将检测线程的名称导出到操作系统。这使显示线程名称的实用程序（例如调试器和 Unix ps命令）能够显示不同的 mysqld线程名称而不是 “ mysqld ”。此功能仅在 Linux、macOS 和 Windows 上受支持。有关详细信息，请参阅 setup_instruments 表。

Microsoft Windows： 在 MySQL 8.0.26 中为运行 Linux 的 MySQL 服务器和客户端主机添加的 Kerberos 身份验证方法现在在 Windows 客户端上得到支持。这使在 Windows 上运行的 MySQL 客户端应用程序能够连接到使用 Kerberos 进行身份验证的 Linux 服务器主机上的 MySQL 帐户。有关详细信息，请参阅 Kerberos 可插入身份验证。

对于绑定了 OpenSSL 库的平台，MySQL Server 的链接 OpenSSL 库已更新到版本 1.1.1l。在https://www.openssl.org/news/cl111.txt和 http://www.openssl.org/news/vulnerabilities.html中描述了新 OpenSSL 版本中修复的问题 。（错误#33273138，错误#33309871）

设置以下系统变量的会话值现在是受限操作，会话用户必须具有足够的权限才能设置受限会话变量：

有关设置受限会话变量所需权限的信息，请参阅 系统变量权限。

和函数ST_SymDifference()现在 ST_Intersection()允许几何参数具有地理空间参考系统 (SRS)。以前， ST_SymDifference()仅 ST_Intersection()支持笛卡尔 SRS 中的几何参数。请参阅 空间运算符函数。

重要更改： 系统变量 group_replication_components_stop_timeout 指定 Group Replication 在关闭时等待其每个模块完成正在进行的进程的时间。组件超时适用于STOP GROUP_REPLICATION发出语句，这在服务器重新启动或自动重新加入期间自动发生。超时用于解决Group Replication组件无法正常停止的情况，如果成员在错误状态下被驱逐出组，或者当MySQL Enterprise Backup等进程持有全局锁时，可能会发生这种情况在成员的表上。在这种情况下，成员无法停止应用程序线程或完成分布式恢复过程以重新加入。STOP GROUP_REPLICATION 在情况得到解决（例如，通过释放锁）或组件超时到期并且模块被关闭（无论其状态如何）之前， 该语句不会完成。

以前，超时值默认为 31536000 秒（365 天），这在刚才描述的情况下没有帮助。新的默认值为 300 秒，因此如果在此之前情况未得到解决，组复制组件将在 5 分钟后停止，从而允许成员重新启动并重新加入。

参考资料：另请参阅：Bug #31460690、Bug #31648211、Bug #32309647。

复制： 现在默认为副本服务器启用多线程。多线程应用程序有许多并行执行事务的应用程序线程。此行为可以避免许多不需要的复制滞后情况，这些情况可能会导致源和副本之间出现临时分歧。

以下默认服务器设置用于产生多线程行为：

要覆盖新的默认值并为副本服务器禁用多线程，请指定 replica_parallel_workers=0. 此设置禁用并行执行并为副本提供单个应用程序线程而没有协调程序线程。当您应用此设置时， replica_parallel_type和 replica_preserve_commit_order 选项无效并被忽略。

复制： 在以前的版本中，Group Replication 使用自己的安全协议实现来保护成员之间的组通信连接和分布式恢复连接，包括 TLS/SSL 和对传入组通信系统 (GCS) 连接使用白名单。复制组现在可以使用 MySQL 服务器自己的连接安全性来代替组复制实现。使用 MySQL 协议意味着可以使用标准的用户身份验证方法来授予（或撤销）对组的访问权限，而不是允许列表，并且服务器协议的最新功能始终在发布时可用。

要使用 MySQL 服务器的连接安全管理实现代替组复制实现，请将新系统变量设置 group_replication_communication_stack 为MYSQL. 此外， group_replication_local_address 为每个组成员设置的网络地址必须更改为 MySQL 服务器正在侦听的 IP 地址和端口之一，如 bind_address. 如果使用网络命名空间，则必须使用 通道 中的CHANGE REPLICATION SOURCE TO 语句进行配置。group_replication_recovery

身份验证是使用 Group Replication 用于分布式恢复的现有复制用户帐户执行的，如使用 设置的CHANGE REPLICATION SOURCE TO，并且必须为该用户授予新 GROUP_REPLICATION_STREAM 权限。连接的 TLS/SSL 配置取自 Group Replication 用于保护分布式恢复的现有设置，以及 group_replication_ssl_mode 指定是否为组通信启用或禁用 TLS/SSL 的系统变量。如果这些设置尚未到位，则必须对其进行配置。所有这些设置必须在所有组成员上都相同，以避免出现沟通问题。

作为这项工作的一部分， performance_schema_max_cond_classes 系统变量的默认值从 100 增加到 150。

有关更多详细信息， 请参阅MySQL 通信堆栈的组复制要求。

include在选项文件中处理或指令 时遇到问题的程序 includedir 现在会生成错误消息，这些消息会提供有关错误原因的更多信息。（错误#32798288，错误#103397）

在所有支持的平台上，系统变量的默认值 thread_stack已增加到 1048576。（错误#103912，错误#32965326）

参考资料：另请参阅：Bug #32934187。

当基于 GTID 的复制在副本服务器上使用时，复制应用程序和接收线程仍然跟踪二进制日志文件名和文件位置并具有一些依赖性，就像用于替代二进制日志文件位置的复制一样。CHANGE REPLICATION SOURCE TO该语句 的一个新选项，GTID_ONLY从复制元数据存储库中删除了文件名和文件位置的持久性。对于具有此设置的复制通道，仍然会跟踪内存中的文件位置，并且仍然可以在错误消息中和通过以下接口观察文件位置以用于调试目的SHOW REPLICA STATUS声明（如果它们已过时则显示为无效）。但是，在基于 GTID 的复制实际上不需要它们的情况下，包括事务排队和应用程序进程，避免了持久化和检查文件位置所需的写入和读取。GTID_ONLY 设置还意味着复制元数据的刷新频率较低。

异步复制通道默认禁用该GTID_ONLY选项，但组复制通道默认启用该选项，并且不能为它们禁用。要设置GTID_ONLY = 1复制通道，GTID 必须在服务器 ( gtid_mode = ON) 上使用，并且基于行的二进制日志记录必须在源上使用（不支持基于语句的复制）。对于复制通道，CHANGE REPLICATION SOURCE TO选项 REQUIRE_ROW_FORMAT和 SOURCE_AUTO_POSITION必须分别设置为 1。当GTID_ONLY 设置为 1 时，副本使用 replica_parallel_workers=1如果该系统变量为服务器设置为零，那么它在技术上始终是一个多线程应用程序。这是因为多线程应用程序使用保存的位置而不是复制元数据存储库来定位它需要重新应用的事务的开始。

感谢 Facebook 提供与此问题相关的贡献。（缺陷 #94360，缺陷 #29364334）

现在可以--default-time-zone 在启动 MySQL Server Docker 容器时使用服务器选项为服务器设置默认时区。之前，如果使用该选项，容器将无法启动。

MySQL 复制的异步连接故障转移机制现在使作为受管复制组一部分的副本能够在当前接收方（组的主节点）出现故障时自动重新连接到发送方。新功能与 Group Replication 一起工作，在配置为单主模式的组上，其中该组的主节点是一个副本，其复制通道 SOURCE_CONNECTION_AUTO_FAILOVER设置为 ON. 在这种情况下，该功能默认在组上运行，但您可以通过禁用新成员操作为组禁用它 mysql_start_failover_channels_if_primary，使用 group_replication_disable_member_action() 功能。该功能是为一组发送者和一组接收者设计的，即使在某些成员暂时不可用时也能保持彼此同步。它还将一组接收者与一个或多个不属于托管组的发送者同步。不属于复制组的副本无法使用此功能。

要配置此功能，必须在复制组中的所有成员服务器以及任何新加入的成员上设置复制通道以及通道的复制用户帐户和密码。您可以使用该 CHANGE REPLICATION SOURCE TO 语句执行此操作，或者如果使用 MySQL 的克隆功能配置新服务器，这一切都会自动发生。这 SOURCE_CONNECTION_AUTO_FAILOVER频道的设置在他们加入时从主要的组成员广播给他们，如果它被改变了。源列表在所有成员加入或更新时广播给所有成员。如果主节点脱机或进入错误状态，则为该组选择的新主节点具有源列表和通道配置，并与源建立替代异步复制连接。

asynchronous_connection_failover_reset()还为管理员提供了 一个新功能 ，可以删除所有与异步连接故障转移机制相关的设置。使用此功能来清理不再在受管组中使用的服务器。

Group Replication（XCom，一种 Paxos 变体）的组通信引擎默认使用组中的每个成员作为领导者。当 Group Replication 通信协议版本设置为 8.0.27 或更高版本时，当组处于单主模式时，组通信引擎现在可以使用单个领导者来驱动共识。与单个共识领导者一起运行可以提高单主模式下的性能和弹性，尤其是当该组的某些次要成员当前无法访问时。

单一共识领导者与组的主要成员位于同一地点，并在选举出新的主要成员时发生变化。Performance Schema 表 replication_group_communication_information 显示了首选和实际的共识领导者，如果所有成员都用作领导者，则显示领导者、通信协议版本和写入并发。

要启用新行为，请将系统变量设置 group_replication_paxos_single_leader 为ON（默认值为 OFF）。当 Group Replication 在多主模式下运行时，或使用较早的通信协议版本，或 group_replication_paxos_single_leader设置为时OFF，组通信引擎使用组中的每个成员作为领导者运行。

请注意，当您手动将复制组的成员升级到新的 MySQL 服务器版本时，该组的通信协议版本不会自动升级以匹配。如果您不再需要支持早期版本的成员，您可以使用该 group_replication_set_communication_protocol() 功能将通信协议版本设置为您将成员升级到的新 MySQL Server 版本。MySQL InnoDB Cluster 为使用该功能创建的复制组自动管理通信协议版本。

对于在线 DDL 操作，存储通常是瓶颈。为解决此问题，已改进 CPU 利用率和索引构建。现在可以同时而不是连续地建立索引。内存管理也已收紧，以遵守用户设置的内存配置限制。请参阅 为在线 DDL 操作配置并行线程。

新innodb_ddl_threads 变量定义索引创建的排序和构建阶段的最大并行线程数。

新innodb_ddl_buffer_size 变量定义了 DDL 操作的最大缓冲区大小。默认设置为 1048576 字节（大约 1 MB）。定义缓冲区大小限制可避免创建或重建二级索引的在线 DDL 操作可能出现的内存不足错误。请参阅联机 DDL 内存管理。

克隆插件现在允许在克隆操作正在进行时对供体 MySQL 服务器实例执行并发 DDL 操作。以前，在克隆操作期间会持有一个备份锁，以防止对捐赠者进行并发 DDL。要恢复到先前在克隆操作期间阻止捐助者上的并发 DDL 的行为，请启用该 clone_block_ddl变量。请参阅 克隆和并发 DDL。

为变量设置会话值 internal_tmp_mem_storage_engine 现在需要 SESSION_VARIABLES_ADMIN或 SYSTEM_VARIABLES_ADMIN权限。

不兼容的更改： 对于视图上的所有SELECT语句，查询摘要基于视图定义。因此，不同的查询具有相同的摘要并在 Performance Schema 表中聚合在一起 events_statements_summary_by_digest，因此该表中的统计信息无法用于区分不同的SELECT语句。

视图上每个SELECT 语句的查询摘要现在基于 SELECT，而不是视图定义。这使得能够区分 SELECT表中的不同语句 events_statements_summary_by_digest 。但是，使用查询摘要的工具可能需要进行一些调整以适应这种变化。例如，MySQL Enterprise Firewall 和查询重写插件依赖于查询摘要，而与视图关联的现有规则可能需要更新。（错误#27540213、错误#89559、错误#31761802）

重要变化： EXPLAIN FORMAT=TREE现在显示索引扫描是否使用覆盖索引，因此不需要从表/聚集索引中查找其他列。例如，如果 idx1是覆盖索引，则旧输出 Index scan on t1 using idx1现在显示为 Covering index scan on t1 using idx1. 以前，此信息仅针对 FORMAT=TRADITIONAL和 FORMAT=JSON。

此修复程序还改进了用于全文搜索的措辞以与此更改保持一致。例如，旧的输出 Indexed full text search on t1（在覆盖和非覆盖情况下都是相同的）现在 Full-text index search on t1是没有覆盖索引和Full-text covering index search on t1使用覆盖索引时的输出。（错误号 32825235）

InnoDB：innodb_open_files临时超过限制 时，将过多的注释写入错误日志（缺陷号 33343690）

InnoDB： 就地 DDL 操作无法刷新所有修改的页面。（错误#33290335，错误#33238133）

InnoDB：从子分区表 将数据加载到 HeatWave 时，并行扫描返回了不正确的分区 ID InnoDB。（缺陷号 33276021）

InnoDB：删除了源中 未使用的os_event::event_iter字段 InnoDB以减少os_event结构中的内存使用。

我们感谢 Facebook 的贡献。（缺陷号 33252468）

InnoDB： 和srv_purge_thread线程 srv_worker_thread在performance_schema.threads 表中重复。

感谢叶凯歌的贡献。（错误#33209066，错误#104575）

InnoDB： 在活动事务使用期间截断撤消表空间引发断言失败。事务过早地标记为完成，允许截断操作。（缺陷号 33162828）

InnoDB： 当从分区表中加载数据到 HeatWave 并发 DML 修改主键时，发现加载回调中报告的分区 ID 对于某些记录不正确。（缺陷号 33139692）

InnoDB：MY_ATTRIBUTE((noreturn))源中的和 MY_ATTRIBUTE((unused))的 实例InnoDB被 C++17 [[noreturn]]和 [[maybe_unused]]属性取代。（漏洞#33112971）

InnoDB： 每个缓冲池块都包含一个 block->lock_hash_val字段。该值的缓存被确定为不必要的，因为它引入了缓冲区和锁定系统的不必要耦合以及不必要的内存使用。（缺陷号 33072415）

InnoDB： 执行索引合并和按行 ID 排序的检索的查询引发断言失败。由于扫描的表包含带 BLOB 组件的主键，因此无法使用为索引合并设置的记录缓冲区。记录缓冲区不能用于读取存储在记录外部的 BLOB。设置记录缓冲区时未检测到 BLOB 主键，因为主键列尚未在读取集中。按行 ID 排序的检索在需要时临时添加主键。为解决此问题，如果主键具有 BLOB 组件，则不再为行排序检索请求记录缓冲区。（缺陷号 33067554）

InnoDB： 删除或更新父表中的一行会在子表上启动级联SET NULL操作，将虚拟列值设置为 NULL。虚拟列值应该是从基列值派生的。

感谢腾讯尹鹏的贡献。（缺陷号 33053297）

InnoDB： 在接近磁盘容量的系统上， InnoDB涉及应用文件扩展重做日志记录 (MLOG_FILE_EXTEND) 的恢复操作可能会导致失败。（缺陷号 33002492）

InnoDB： 在同一记录上授予的冲突显式锁引发了断言失败。（缺陷号 33000142）

InnoDB： 在清除批处理结束时释放 LOB 的第一页引发断言失败。失败是由于无效的根页码。（缺陷号 32958624）

InnoDB： 为了促进故障报告和解决，源代码中的 ib::fatal()函数 InnoDB被修改为包括调用者的位置。（缺陷号 32957311）

InnoDB： 克隆接收服务器上的恢复失败，出现以下错误：读取 innodb_undo_007 的加密时出错。加密密钥未写入在克隆操作的页面复制阶段创建的加密空间。（缺陷号 32950216）

InnoDB： 为避免生成不需要的警告消息， fil_space_acquire()函数 InnoDB替换为 fil_space_acquire_silent()函数。后台线程使用这两个函数来获取表空间。（缺陷号 32944543）

InnoDB： InnoDB CRC32 校验和算法实现现已针对 ARM 和 x86/x64 架构进行了优化。（缺陷号 32887066）

InnoDB： 由于错误日志子系统上的大量流量，在具有数千个表的实例上启动花费了过多的时间。（缺陷号 32846656）

InnoDB: 视图INFORMATION_SCHEMA.FILES没有显示临时表空间文件的当前路径，显示的文件名与 innodb_temp_data_file_path 变量定义的文件名不同。（缺陷 #32840635，缺陷 #103553）

InnoDB： 在 Windows 上，在尝试获取互斥锁时在没有共享写锁的情况下保持文件打开会互斥锁并试图访问同一文件fil_shard 线程发生死锁fil_shard（缺陷号 32808809）

InnoDB： 使用与另一个正在运行的 MySQL 服务器实例相同的 InnoDB数据文件启动 MySQL 服务器实例导致初始化失败。（错误#32777654，错误#103338）

InnoDB： 恢复InnoDB过程没有识别出页面压缩已经应用于正在恢复的数据，导致表空间数据文件在重做日志应用阶段增加大小，这可能导致系统接近磁盘的恢复失败-满状态。（漏洞#32771259）

InnoDB： 断言遍历未满的文件段列表以计算已用页数以与文件段 inode 中的字段跟踪的已用页数进行比较时偶尔失败。（缺陷号 31685095）

InnoDB: 在线DDL操作失败后重启服务器时事务回滚失败。无法为未提交的事务恢复表锁，并且无法为受影响的表加载数据字典表对象。

感谢 Shaohua Wang 的贡献。（漏洞 #31131530，漏洞 #99174）

InnoDB： 使用临时表进行聚合的查询耗尽了TempTable存储引擎可用的内存，导致更新操作失败并出现 table is full 错误。（缺陷 #31117893，缺陷 #99100）

复制： 在组复制自动重新加入过程中，组成员将其状态设置为RECOVERING。如果群组成员未能重新加入，则应将状态更改为ERROR，但如果在此期间发生视图更改，则状态可能会保持在RECOVERING。成员状态现在设置为ERROR在不成功的自动重新加入程序之后，无论任何正在进行的或卡住的视图更改。（缺陷号 33276418）

复制： 认证信息的垃圾收集已从组复制组通信系统 (GCS) 线程移至后台线程，以便在进行垃圾收集时不会阻塞消息的发送和接收。（缺陷号 33190276）

复制： 当 Group Replication 配置为 时 group_replication_consistency = BEFORE_ON_PRIMARY_FAILOVER，如果主节点发生故障转移，客户端连接将保持直到新的主节点与之前的主节点具有相同的状态。一些监控和管理语句不受此限制，因此可以在故障转移过程中检查新的主数据库。

以前，DO语句可以一揽子免除保留，但现在只有DO 不使用表或可加载函数的语句可以免除，至于SELECT语句。（缺陷号 33130768）

复制： 复制应用程序 (SQL) 线程覆盖来自存储引擎的可重试错误（如死锁和等待超时），并出现未找到密钥错误，导致复制停止而不重试事务。这些错误不再被覆盖。（缺陷号 33107663）

复制： 当组复制停止或重新启动时，MySQL 服务器错误地允许从与组复制相关的性能模式表中读取，并且不应使用相关数据。OFFLINE服务器现在在执行查询之前检查 Group Replication 是否处于 （缺陷号 33085494）

复制： 当 Group Replication 配置为 时 group_replication_consistency = BEFORE_ON_PRIMARY_FAILOVER，如果主节点发生故障转移，客户端连接将保持直到新的主节点与之前的主节点具有相同的状态。一些监控和管理语句不受此限制，因此可以在故障转移过程中检查新的主数据库。以前，SHOW语句可以完全免除保留（除了SHOW CREATE USER），但现在只有SHOW 不依赖于数据（仅依赖于状态或配置）的语句可以免除。免除SHOW 语句列在该功能的文档中。（缺陷号 33082509）

复制： 当 Group Replication 的分布式恢复过程正在进行以将加入成员与捐赠者同步时，Performance Schema 表 replication_group_member_stats未使用 group_replication_applier通道上排队的当前事务数（ COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE 字段）进行更新。现在在新事务时跟踪计数在分布式恢复期间到达，尽管在加入者验证在分布式恢复的第一阶段收到的事务之前它仍然为零。（缺陷号 33067441）

Replication： 对于多线程副本（ replica_parallel_workers设置值大于0的replicas），如果 replica_parallel_workers设置为1， replica_preserve_commit_order 现在忽略设置。当只有一个应用程序时，事务总是按照与副本的中继日志中相同的顺序执行和提交；忽略保留提交顺序的过程可以避免潜在的性能下降。（缺陷号 33048169）

复制： 当引用访问控制列表 (ACL) 的语句时可能会发生死锁，例如CREATE USER，在组复制组的主节点上执行，并且在事务提交被其他组成员确认之前，一个成员立即加入了该组。分布式恢复进程需要对 ACL 语句锁定的 ACL 缓存进行读取锁定。这种情况会阻塞 Group Replication 的 Group Communication System (GCS) 线程，直到 ACL 语句超时，从而导致无法访问主节点并可能阻止新成员加入。现在分布式恢复过程不再需要 ACL 缓存锁，尽管所描述情况中的锁仅在视图更改完成并提交 ACL 语句后才释放。因此，任何需要 ACL 缓存锁的新连接或语句，包括组复制使用 MySQL 通信堆栈时的成员连接，都必须等待此操作，否则会失败并重试。（缺陷号 33025231）

复制： 如果具有未填充时区的副本 MySQL 服务器实例试图复制设置副本未知的时区值的语句，则会引发断言。副本现在可以正确处理这种情况。（缺陷号 32986721）

复制： 在某些情况下，当自动定位所需的 GTID 已被清除时，MySQL 复制发出的错误消息可能会被错误分配或扰乱。（缺陷号 32965864）

Replication： 如果运行 Group Replication 的 applier 模块的线程停止，则 group 无法正常运行，因为它无法交换 group 事务和消息。以前，处于这种情况的成员保持ONLINE状态并忽略内部错误。如果线程停止，成员现在更改为 ERROR状态，并采取 group_replication_exit_state_action系统变量指定的操作。（缺陷号 32934479）

复制： 如果一个组成员在关闭之前或关闭时被选为主选，则关闭过程在等待主选过程时挂起，主选过程试图让服务器离开组，因为选举因关闭。初选的错误处理过程现在考虑到了这一点，如果该成员已经离开该组，则不会采取任何进一步的措施。（缺陷号 32884709）

复制：如果在查询过程中删除了一行，则 查询 Performance Schema 表 replication_asynchronous_connection_failover 可能会返回错误。在这种情况下，行计数现在返回为零，并且可以重试查询。（缺陷号 32701593）

复制： 在某些情况下，使用连接压缩的副本无法重新建立与源服务器丢失的连接。该问题现已解决。（缺陷号 32494609）

复制： 从 MySQL 8.0.22 开始，复制源服务器 在服务器重启后第一次使用时，TRUNCATE TABLE向二进制日志写入一条语句，通知副本清空 MEMORY以前，记录该语句的线程未在全局线程管理器中注册，因此 Group Replication 无法确认它。该问题现已得到纠正。（缺陷号 32355801）

JSON： 对 MySQL 8.0.23 中的 JSON 函数错误处理进行了额外改进。（缺陷号 32864910）

参考资料：另请参阅：Bug #31856260。

JSON： JSON_TABLE()当名称仅大小写不同时允许重复的列名，尽管列名在 MySQL 中不区分大小写。

现在这个函数以不区分大小写的方式比较列名。（漏洞 #102824，漏洞 #32591074）

添加了 Ubuntu 21.10 软件包。（错误#33501583，错误#105274）

如果 MySQL 链接到 OpenSSL 1.0.1，MySQL 客户端库可能会导致内存泄漏，就像在 EL6 上构建的情况一样。（缺陷号 33335046）

隐式分组的查询有时会在优化期间计算聚合，因为它们的值可以很容易地从索引中检索到。当谓词引用使用排序规则声明的列时NO PAD，该谓词可能会使用PAD SPACE语义进行评估，因此会返回错误的结果。这是因为检查无关紧要的尾随空格的内部函数假设所有非二进制排序规则都具有PAD SPACE语义，这在 MySQL 5.7 中是正确的，但 MySQL 8.0 并非如此，它添加了许多具有NO PAD语义的排序规则，包括默认排序规则( utf8mb4_0900_ai_ci).

在这种情况下，我们通过显式检查排序规则的填充属性来解决此问题。（缺陷号 33282123）

包含公用表表达式的查询以及 MATCH() AGAINST()在未定义全文索引的表上执行的子句引发断言失败。（缺陷号 33264864）

几个 Performance Schema 表包含默认时间戳值 0（零），这与默认 sql_mode值 NO_ZERO_IN_DATE和 冲突NO_ZERO_DATE。

例如，尝试基于此类 Performance Schema 表创建新表会导致类似于以下内容的错误：ERROR 1067 (42000): Invalid default value for 'FIRST_SEEN'

默认时间戳值已从下表中删除：

（错误#33240123，错误#104643）

写入NOTIFY_SOCKET 环境变量失败导致失败。与失败写入相关的 ER_SYSTEMD_NOTIFY_WRITE_FAILED 错误有两个参数，但只有一个参数被传递给错误记录例程。（缺陷号 33239183）

--ssl-fips-mode设置选项 时使用了错误类型转换的变量 。（缺陷号 33223230）

表中不存在以下线程 performance_schema.threads：

感谢叶凯歌的贡献。

感谢叶凯歌的贡献。（错误#33214130、错误#104582、错误#33214136、错误#104583）

对内部保存函数的递归调用导致意外错误。（缺陷号 33198164）

内部mysqld_list_fields()函数未能删除为评估 JSON表函数而创建的临时表。（缺陷号 33177686）

生成最小 TAR 包的代码向包中添加了调试符号，这导致了更大（大约 10 倍）的构建。现在，DEB/RPM 编译器标志对于调试符号构建默认打开，对于最小大小的发布构建默认关闭。（错误#33151629，错误#104402）

发现部分多表DELETE 语句内存泄漏。（缺陷号 33151275）

参考资料：另请参阅：错误 #18684036。

服务器内部复制函数的返回值未按预期处理。（缺陷号 33142669）

参考资料：此问题是 Bug #31982292 的回归。

空范围帧并不总是被正确处理。（缺陷号 33142418）

参考资料：此问题是 Bug #90300、Bug #27808099 的回归。

在调试版本中，ALTER TABLE 如果该语句添加了一个与稍后由外键引用的列之一同名的新虚拟列，则该语句可能会产生错误。如果名称重复，此修复程序现在会忽略虚拟列，而是使用现有的非虚拟列名称来检查条件。（缺陷号 33114045）

用于确保在没有错误时开始执行存储的程序指令的断言条件对于CASE循环中的语句无法正常工作。（缺陷号 33079184）

在调试版本中，ANALYZE TABLE withUPDATE HISTOGRAM子句可以在成功清除诊断区域后向调用方返回非成功值，而不是成功值。（缺陷号 33079073）

mecab_charset系统状态变量现在将其值报告为 而utf8mb4不是utf8，这已被弃用。（缺陷号 33078623）

在调试版本中，MySQL Enterprise Encryption UDF 在返回 NULL 时未设置可空标志。（缺陷号 33077931）

当计划锁定生效时，有时会调用范围优化器。这导致了问题，因为范围优化器可以调用自身，但计划锁不允许递归。（缺陷号 33076462）

参考资料：此问题是 Bug #18684036 的回归。

CAST()和 DEFAULT()，当在存储例程中使用时，并不总是能正确处理。（缺陷号 33075828）

在评估期间使用临时字符串缓冲区的字符串函数可能会导致意外关闭。（缺陷号 33073951）

主机名无法解析为 IP 地址后发出的错误消息不包含有意义的 errno值。现在，(-2) 指示EAI_NONAME在消息中返回而不是(0)。（缺陷号 33064143）

如果 的值设置为 并且 处于 ANSI 模式，则CREATE TABLE t SELECT 1创建一个 表 的语句 InnoDB会错误地写入二进制日志 。结果，语句的复制失败并在副本上出错。将mysqlbinlog实用程序应用于此类二进制日志也可能会失败。 binlog_formatROWsql_mode

原子CREATE...SELECT是通过向CREATE TABLEcalled添加一个新子句来实现的START TRANSACTION。但是，启用 ANSI 模式时未添加此子句。这反过来导致在CREATE TABLE事务中间执行普通隐式提交，如果事务具有分配的 GTID，则在 GTID 模式下产生错误。通过从新子句中删除 SQL 模式相关性来解决此问题。（错误#33064062，错误#104153）

包含格式错误的 ISO8601 时间戳的日志文件处理不当。（缺陷号 33060440）

以前引用的字符串转换警告 utf8现在引用utf8mb3 。（缺陷号 33059330）

在 Unix 平台上从源构建 MySQL 时， .bz2文件现在用于 Boost 存档下载而不是.tar.gz文件。（缺陷号 33052171）

对于 Enterprise Linux 8（和 Fedora），通过在 fprofile.cmake 中禁用 REPRODUCIBLE_BUILD 来修复 debuginfo RPMS 包。（缺陷号 33037380）

对于具有汇总的查询，当将表达式设置为可空时因为它有一个分组列，我们错过了将该表达式中的所有表达式设置为可空，只对最顶层的表达式这样做。这意味着，在评估期间，NULL汇总生成的数据并不总是正确传播。为了解决这个问题，我们现在在查询使用汇总时将所有具有分组列的表达式设置为可为空。（缺陷号 33036184）

在 执行期间EXPLAIN，当通过流式或物化节点跨入不同的查询块时，该节点被计为根，而不是实际的根节点。（缺陷号 33030136）

int64修复了从 double 到in 的未定义转换 sql/join_optimizer/cost_model.cc。（缺陷号 33024410）

内部函数find_in_group_list() 在处理过程中没有匹配正确匹配所有项目 ROLLUP。GROUP BY我们通过向表达式添加强制转换来解决此问题。（错误#33022742，错误#33123934）

参考资料：此问题是 Bug #30969045 的回归。

缺少 MySQL 客户端库中内存分配成功的测试可能会导致客户端退出。（缺陷号 33019026）

来自准备好的语句的审计日志函数调用导致错误。（缺陷号 33016004）

避免添加前缀为 的列名， !hidden!以确保新名称不会与现有隐藏列用于功能索引的名称发生冲突。生成的隐藏列名称现在具有以下新形式，将功能索引的使用扩展到不支持由生成的名称的环境中 MD5()：

!hidden!index_name!key_part_number!counter

counter除非表中已存在具有该名称的列，否则生成的名称 的值为零。在这种情况下，该值会递增，直到名称变得唯一为止。（缺陷号 32983024）

从sql_help.cc. （缺陷号 32976042）

窗口函数执行期间缓冲区空间分配不足可能导致引发断言。（缺陷号 32975889）

在哈希连接下查找表列表时，我们没有考虑那些也隐藏在 ZERO_ROWS 迭代器下的表。这可能会导致 NULL 行标志没有被正确设置，当 weedout 想要为它们保存行 ID 时，这也会导致问题。（缺陷号 32975168）

、和 数据屏蔽函数如果在时间上多次执行，每个函数都可以生成相同的值gen_dictionary()。 （缺陷号 32970772）gen_range()gen_rnd_pan()

用于解析公用表表达式的临时表的创建和删除以及在子查询中创建的表引用并不总是得到正确管理。（缺陷号 32962511）

当为mysql-–binary-as-hex客户端 启用该选项时，空字符串现在打印为而不是 . （错误#32961656，错误#103906）0xNULL

解析器通常在遇到语句错误后终止分析并退出。在重复列分析的情况下，解析器会继续到列列表的末尾，可能会向诊断对象添加多条错误消息。（缺陷号 32960158）

当标量子查询返回多行时，产生的错误并不总是得到正确处理。（缺陷号 32956779）

在创建包含生成的列的表后更改服务器 SQL 模式可能会导致将虚假消息写入错误日志。（缺陷号 32954466）

在 Windows 上读取清单文件可能会失败。（缺陷号 32950322）

列表中值的评估IN() 不会在出错时立即停止，这会导致断言失败。我们通过在出现错误后立即停止评估来解决此问题。（缺陷号 32942328）

如果在将两个不可为 null 的值作为字符串进行比较时出现错误，则比较的结果将设置为NULL，即使根据比较运算符元数据该结果不可为 null。错误已正确返回给用户，但在调试模式下运行时，此不一致引发了断言。

这是通过在所有者不可为空时Arg_comparator不将其所有者设置为来解决的。NULL（缺陷号 32942327）

在升级操作期间执行的 SQL 脚本中引用的未设置变量导致失败。（缺陷号 32939819）

操作中不正确的错误传播filesort 可能会引发断言。（缺陷号 32932969）

在内部WalkAndReplace()函数中，来自set_cmp_func()的错误未正确传播。（错误#32918927，错误#33007298）

参考资料：此问题是 Bug #32548377 的回归。

RESET REPLICA ALL 如果在读取通道配置时使用语句，则 可能会发生死锁。（缺陷号 32906709）

访问持久变量缓存的潜在竞争条件已被消除。（缺陷号 32901419）

MySQL 优化器执行的常量传播在某些情况下可以用可空表达式替换对不可空列的引用。发生这种情况时，被替换列引用的父项有时可能具有错误的可空性，导致稍后在执行期间断言失败，此时不可为空的项意外返回 NULL。

在不可空列引用被可空表达式替换的情况下，我们通过跳过常量传播来解决此问题。（缺陷号 32895824）

参考资料：此问题是 Bug #32371039 的回归。

查询中提供的列名可能在排序规则细节上有所不同，或者因为该名称是作为查询中的表达式别名提供的，并且仍然与字典中的列名匹配。查询输出包含查询中指定的列名（例如，aaa）而不是字典中的列名（例如， AAA）。（缺陷号 32892045）

当服务器 SQL 模式不是严格模式时，某些字符串函数返回NULL以指示结果对于结果缓冲区来说太大，这可能导致不一致的行为，例如错误排序的输出。此外，这些函数 LAST_INSERT_ID()并 CAST(... AS CHAR)没有在所有情况下都正确地维护可空性。（缺陷号 32864958）

作为ORDER BY窗口函数的一部分或对视图的引用添加的隐藏项在隐式分组查询中并不总是得到正确处理。（错误#32863279，错误#33079592）

将类型从整数转换为小数时，否定的类型解析没有设置正确的精度。这是通过分配与参数相同的精度来解决的。（缺陷号 32863037）

参考：这个问题是 Bug #31348202 的回归。

失败语句的错误传播不当 CREATE TABLE ... SELECT导致回滚不会发生。（缺陷号 32855882）

在子查询中使用时，并不总是能正确处理VALUES 具有多个的 a。ROW()（缺陷号 32851684）

当使用协议压缩时，MySQL 服务器在等待超时到期时发送给客户端程序的错误数据包 ( ER_CLIENT_INTERACTION_TIMEOUT) 在数据包标头中使用了错误的序列号 2 而不是 0。（错误#32835205，错误#103412）

多张全文索引表的并发插入操作导致大量全文索引同步请求，导致内存不足。（错误#32831765，错误#103523）

先前问题的修复已恢复，后续工作使其变得多余并导致窗口函数中使用的表达式产生无效结果。（缺陷号 32820802）

参考资料：恢复补丁：Bug #26389508。

在准备好的语句中，NULLIF() 结果类型确定可能不正确。（错误#32816305，错误#103458）

在存储例程中创建和删除视图并不总是能正确处理。（缺陷号 32807430）

上一个问题的修复包括对如何确定小数表达式的精度和小数位数的小重构。后来发现，对于该 TRUNCATE()函数，我们可能会以零精度结束，这是无效的。

我们通过将精度零视为一来解决此问题。（缺陷号 32802251）

参考资料：另请参阅：Bug #31348202。

由于遗留原因，我们可以有复合访问路径，包括 Filter和Sortinside table_path。为了便于分析和更好地格式化，我们将EXPLAIN 这些之前的输出移至Materialize 访问路径。

我们在这里展示了在EXPLAIN此更改之前和之后运行的语句示例：

# Table created as follows:
mysql> DROP TABLE IF EXISTS t1;
Query OK, 0 rows affected (0.02 sec)

mysql> CREATE TABLE t1 ( f1 INTEGER );
Query OK, 0 rows affected (0.03 sec)


# Previous to change:
mysql> EXPLAIN FORMAT=TREE
    ->   SELECT * FROM ( SELECT * FROM t1 LIMIT 2 OFFSET 1 ) AS alias1
    ->   WHERE f1 <= ANY ( SELECT f1 FROM t1 ) ORDER BY f1\G
*************************** 1. row ***************************
EXPLAIN: -> Sort: alias1.f1
-> Filter: <nop>((alias1.f1 <= (select #3)))  (cost=2.62 rows=2) [other sub-iterators not shown]
    -> Table scan on alias1  (cost=2.62 rows=2)
        -> Materialize  (cost=0.35..0.35 rows=0)
            -> Limit/Offset: 2/1 row(s)  (cost=0.35 rows=0)
                -> Table scan on t1  (cost=0.35 rows=1)

# Following change:
mysql> EXPLAIN FORMAT=TREE
    ->   SELECT * FROM ( SELECT * FROM t1 LIMIT 2 OFFSET 1 ) AS alias1
    ->   WHERE f1 <= ANY ( SELECT f1 FROM t1 ) ORDER BY f1\G
*************************** 1. row ***************************
EXPLAIN:
-> Sort: alias1.f1  (cost=0.35..0.35 rows=0)
    -> Filter: <nop>((alias1.f1 <= (select #3)))  (cost=2.62 rows=2)
        -> Table scan on alias1  (cost=2.62 rows=2)
            -> Materialize  (cost=0.35..0.35 rows=0)
                -> Limit/Offset: 2/1 row(s)  (cost=0.35 rows=0)
                    -> Table scan on t1  (cost=0.35 rows=1)
        -> Select #3 (subquery in condition; run only once)
            -> Aggregate: max(t1.f1)  (cost=0.45 rows=1)
                -> Table scan on t1  (cost=0.35 rows=1)

进行此更改后，其中唯一合法的访问路径 table_path是TABLE_SCAN、 REF、REF_OR_NULL、 EQ_REF和ALTERNATIVE。（错误#32788576，错误#32915233）

在评估十进制表达式时，常量折叠并不总是正确处理错误。（缺陷号 32785804）

调用顺序不匹配 Query_block::prepare_values()导致 setup_order()在 之后调用 resolve_subquery()，这意味着对于子查询的 VALUES子句，子查询可以在调用之前合并到外部查询块中setup_order()，从而导致数据结构不一致和错误。

我们通过setup_order() 更早执行来解决此问题，如果未找到该列，则会中止解决。（缺陷号 32783943）

参考资料：此问题是 Bug #31387510 的回归。

在 Performance Schema 表中 variables.info，系统变量 skip_slave_start被错误地列为 COMPILED全局值实际从持久变量文件加载时，因此 PERSISTED应该使用。（缺陷号 32640588）

对具有并发 MySQL 服务器负载的视图 的SELECT查询 导致失败。INFORMATION_SCHEMA.PROCESSLIST（缺陷号 32625376）

当查询使用临时表进行聚合时，group by item作为临时表的唯一约束：如果item值已经存在，则更新该行；否则，一个新行被插入到临时表中。如果项目有结果字段或引用项目，它会计算两次，一次是检查结果是否存在于临时表中，如果不存在，则在构造要插入的行时再次计算。当按项目分组不确定时，用于检查是否存在的结果值与尝试插入的结果值不同，如果该值已存在于表中，则会导致插入被拒绝。

我们通过使用任何非确定性项目的散列作为唯一约束来解决这个问题，这样散列只被评估一次。（缺陷号 32552332）

特定于表的角色的权限检查在某些情况下不够严格。（缺陷号 32400788）

WHERE 如果使用函数而不是字符串文字，则 某些比较谓词的计算方式不一致（例如，当子句的一部分时）可能会返回不同的结果。（错误#32345941，错误#102151）

ENUMor 类型的列SET按照数值比较排序，但是窗函数的范围表达式（即范围框指定时用于排序的表达式）的比较函数是根据列的结果类型设置的，即对于ENUM和 SET是String。结果，窗口框架的行处理（查看一行是在框架之前还是之后）无法正常工作；例如，字符串比较可能会确定一行出现在帧之前，而数字比较会将该行放在帧之后。

ENUM为了解决这个问题，我们实现了和 的整数缓存项 ，以及在范围表达式中涉及或类型SET时使用的整数比较函数 。（缺陷号 32328576）ENUMSET

当访问已优化和清理的子查询时，DML 语句会导致服务器意外关闭。（缺陷号 32244822）

解析列时，使用 以不区分大小写的方式比较它们的名称 utf8_general_ci，这并不总是遵循与表实际使用的排序规则相同的比较规则。以前，当一个表的列数超过 32 时，将使用哈希表执行名称查找。散列是排序规则感知的，因此遵循排序规则的比较规则；这导致以不一致的方式完成名称查找和重复检测。我们通过删除散列来解决这个问题，并在所有情况下以相同的方式执行列名解析，而不管列数。（缺陷号 32169656）

对于可为空的列，当范围优化器将相邻范围四舍五入为相同值时，会返回错误结果。（缺陷号 31870920）

参考资料：另请参阅：Bug #98826、Bug #30988735。

SHOW GRANTS语句 的报价处理得到改进。（缺陷号 31716706）

在创建支持表函数的临时表之前，可能会尝试将 JSON_TABLE()表达式写入优化器跟踪，从而引发断言。现在，当列类型尚不可用时， <column type not resolved yet>将写入。（缺陷号 31578783）

系统变量设置的有效性检查 mandatory_roles现在与对 语句执行的有效性检查同步。（缺陷号 31218040）GRANT role

该 keyring_hashicorp_update_config() 函数对于并发执行不安全。（缺陷号 31205028）

刷新重写规则时查询重写插件失败，保存重写规则的表包含已标记为已删除但未物理删除的行。

我们通过使查询重写插件跳过已删除的行而不是在看到它们时失败来解决此问题。（漏洞 #22654105）

作为在 MySQL 中实现窗口函数的一部分完成的重构使得可以在 ORDER BY子句中引用聚合的别名，但也允许直接引用此类聚合，即使这不应该被允许。现在服务器明确检查此类非法引用。（错误#13633829，错误#30106081）

在某些情况下，在将条件下推到派生表时克隆的视图引用并不总是在所需的上下文中解析。此外，未正确执行空条件检查。（错误#104574、错误#33209907、错误#33197276）

一些使用查询HAVING COUNT(DISTINCT ...) 没有返回预期的任何行。（错误#104411，错误#33152269）

参考资料：此问题是 Bug #31790217 的回归。

以下情况未使用多值索引：

此外，MySQL 错误地报告了形式impossible condition为 的WHERE子句，其中 任何、或。 f() AND f()f()MEMBER OF()JSON_CONTAINS()JSON_OVERLAPS()

感谢 Yubao Liu 的贡献。（错误#104325、错误#104700、错误#104721、错误#33123079、错误#33268466、错误#33275457）

参考资料：另请参阅：Bug #102359、Bug #32427727。此问题是 Bug #30838807 的回归。

当NULL传递给调用 的用户创建的函数时，函数 REGEXP_INSTR()的第一次调用NULL按预期返回，但函数的每次后续调用也会返回NULL，而不考虑传递给它的值。（错误#104239，错误#33089668）

中定义的一些函数 mbr_utils.cc在某些情况下会抛出堆分配的异常。在这些情况下，为异常对象分配的内存从未被释放，这意味着每次抛出异常时都会泄漏少量内存。

在这种情况下，这是通过在堆栈上分配异常来解决的。（错误#104214，错误#33086286）

启用优化后 ，列名未正确显示在 ROLLUP查询 结果中。subquery_to_derived（错误#104139，错误#33057397，错误#33104036）

包含 IF语句 using 的存储过程，该语句EXISTS作用于在执行之间删除和重新创建的一个或多个表，对于第一次调用之后的后续调用没有正确执行。（错误#103607，错误#32855634）

当执行由多个相同范围连接的范围查询时OR（例如，带有 的查询 WHERE (a=1 AND b=2 AND c=3) OR (a=1 AND b=2 AND c=3)），优化器丢失了部分范围，因此选择了一个不是最优的查询计划。

我们感谢 Facebook 的贡献。（错误#102634，错误#32523520）

在评估松散索引扫描作为执行分组和查找最小值的可能选项时，由于分组属性上的相等谓词，成本计算并未反映查询仅查看一个组的事实。这导致检查额外的行，因为分组是在从索引中读取行之后执行的。

我们通过检查分组属性上是否存在等式谓词并使用它们来计算成本来确定查询是否仅产生一个组来解决此问题。当发现这样做有益时，这会导致优化器为此类情况选择松散索引扫描。（错误#101838，错误#32266286）

参考资料：另请参阅：错误 #18109609。

解析整数除法时，结果的精度取自被除数。当除数为十进制数时，可能小于1，这可能导致结果比被除数使用更多的位数。在某些情况下，这会产生不正确的值，其中整数除法的结果是小数或浮点数。（错误#100259，错误#31641064）

向优化器跟踪添加了内存中估计，以指示在缓冲池中缓冲了多少给定表。

感谢 Øystein Grøvlen 的贡献。（缺陷 #99993，缺陷 #31544522）

DML 语句的EXPLAIN输出在 的输出中包含表标识符，通常包括数据库名称SHOW WARNINGS。对于某些语句，如 CREATE VIEW，应省略数据库名称，这是通过 alias_name_used在缓存表对象中将标志设置为 true 来强制执行的，但是当以下缓存表被重用时 CREATE VIEW，标志没有被重置，这导致数据库名称是在访问与视图相同的缓存表 EXPLAIN之后运行的语句之后 的警告中省略了。CREATE VIEW

我们通过确保 alias_name_used在表初始化期间始终将标志设置为适当的值来解决此问题。

我们感谢 Kaiwang Chen 的贡献。（缺陷 #98635，缺陷 #30909064）