您现在可以在创建或更新 MySQL 用户帐户时设置每个用户的评论和属性。用户评论由作为参数传递 给与or 语句COMMENT一起使用的子句 的任意文本组成。用户属性由 JSON 对象形式的数据组成，这些数据作为参数传递给与这两个语句中的任何一个一起使用的子句。该属性可以包含 JSON 对象表示法中的任何有效键值对。 CREATE USERALTER USERATTRIBUTE

例如，以下两个语句中的第一个创建了一个bill@localhost带有评论文本的用户帐户This is Bill's user account。email第二条语句使用 key和 value 向该帐户添加用户属性 bill@example.com。

CREATE USER 'bill'@'localhost' COMMENT 'This is Bill\'s user account';

ALTER USER 'mary'@'localhost'
    ATTRIBUTE '{"email":"bill@example.com"}';

在同一个 or 语句中只能 COMMENT使用 or 之一。ATTRIBUTECREATE USERALTER USER

用户评论和用户属性作为 JSON 对象在内部存储在一起，评论文本作为具有键的元素的值comment。ATTRIBUTE您可以从表的列 信息中检索用户评论和用户属性 INFORMATION_SCHEMA.USER_ATTRIBUTES ；由于此数据为 JSON 格式，您可以使用 MySQL 的 JSON 函数和运算符来处理它（请参阅 JSON 函数）。对现有用户属性的更改将与其当前值合并，就像您使用的那样 JSON_MERGE_PATCH()；新的键值对附加到属性，现有键的新值覆盖它们以前的值。

要从用户属性中删除给定的键值对，请使用 . ALTER USER user ATTRIBUTE '{"key":null}'

有关更多信息和示例，请参阅 CREATE USER 语句、ALTER USER 语句和 INFORMATION_SCHEMA USER_ATTRIBUTES 表。

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

根据 OpenSSL 的建议， C 客户端库中的x509_check_host() 和调用X509_check_ip_asc()分别替换为 X509_VERIFY_PARAM_set1_host()和 X509_VERIFY_PARAM_set1_ip_asc()调用。（漏洞#29684791）

MySQL C API 现在支持异步函数的压缩。这意味着函数的 MYSQL_OPT_COMPRESSION_ALGORITHMS和 MYSQL_OPT_ZSTD_COMPRESSION_LEVEL选项mysql_options()现在影响异步操作，而不仅仅是同步操作。请参阅mysql_options()。

我们感谢 Facebook 的贡献。（缺陷 #96802，缺陷 #30284871）

服务器构建的 Boost 库的最低版本现在是 1.72.0。（缺陷号 30963985）

tcmalloc不再是mysqld_safe --malloc-lib选项的允许值。（缺陷号 31372027）

MySQL 服务器支持普通客户端连接的“主要”网络接口，以及可选的管理客户端连接的管理网络接口。以前，主界面和管理界面使用相同的 TLS 配置，例如用于加密连接的证书和密钥文件。现在可以为管理界面单独配置 TLS 材料：

有关详细信息，请参阅 加密连接的管理界面支持、 ALTER INSTANCE 语句和 tls_channel_status 表。

分区： 不支持带有索引前缀的列作为表分区键的一部分；以前，当在创建、更改或升级按键分区的表时引用这些列时，服务器只是简单地省略了这些列，没有迹象表明发生了这种遗漏，除非建议的分区函数仅使用带前缀的列，其中case 语句失败，错误消息未指明问题的实际来源。此行为现​​已弃用，并会在未来的版本中删除，在未来的版本中，在建议的分区键中使用任何此类列将导致出现它们的CREATE TABLEorALTER TABLE 语句被拒绝。

当一个或多个使用索引前缀的列被指定为分区键的一部分时，现在会为每个这样的列生成一条警告。此外，当 CREATE TABLEor ALTER TABLE语句因为建议的分区键中指定的所有列都使用索引前缀而被拒绝时，现在返回的错误消息会清楚地说明语句未成功的原因。这包括使用空PARTITION BY KEY() 子句将提出分区函数的列隐式定义为表主键中的列的情况。

有关更多信息和示例，请参阅 Column index prefixes not supported for key partitioning和 KEY Partitioning。（错误#29941932、错误#29941959、错误#31100205）

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

添加了JSON_VALUE()函数，简化了在 JSON列上创建索引。调用 等同于调用，其中 是 JSON 文档， 是指向文档中单个值的 JSON 路径表达式，并且 是与 兼容的数据类型 。是可选的；如果未指定返回类型，则 返回. JSON_VALUE(json_doc, path RETURNING type)CAST( JSON_UNQUOTE( JSON_EXTRACT(json_doc, path) ) AS type)json_docpathtypeCAST()RETURNING typeJSON_VALUE()VARCHAR(512)

JSON_VALUE()还支持ON EMPTY与.ON ERROR一起使用的类似条款JSON_TABLE()。

您可以使用如下所示在 JSON 列 上创建索引：JSON_VALUE()

CREATE TABLE inventory(
    items JSON,
    INDEX i1 ( (JSON_VALUE(items, '$.name' RETURNING CHAR(50))) ),
    INDEX i2 ( (JSON_VALUE(items, '$.price' RETURNING DECIMAL(5,2))) ),
    INDEX i3 ( (JSON_VALUE(items, '$.quantity' RETURNING UNSIGNED)) )
);

假设该items列包含诸如 之类的值'{"name": "hat", "price": "22.95", "quantity": "17"}'，您可以发出能够使用这些索引的查询，如下所示：

SELECT items->"$.price" FROM inventory
    WHERE JSON_VALUE(items, '$.name' RETURNING CHAR(50)) = "hat";

SELECT * FROM inventory
    WHERE JSON_VALUE(items, '$.price' RETURNING DECIMAL(5,2)) <= 100.01;

SELECT items->"$.name" AS item, items->"$.price" AS amount
    FROM inventory
    WHERE JSON_VALUE(items, '$.quantity' RETURNING UNSIGNED) > 500;

有关更多信息和示例，请参阅 JSON_VALUE()函数的说明。

MySQL 尝试对任何具有子句的查询 ORDER BY使用 有序索引，覆盖优化器做出的任何其他选择，只要它确定这会导致更快的执行。由于进行此确定的算法对数据分布和其他条件做出了某些假设，因此它可能并不总是完全正确，并且在某些情况下，为此类查询选择不同的优化可能会提供更好的性能。为了处理此类事件，现在可以通过将 系统变量的 标志 设置为来禁用此优化。 GROUP BYLIMIToptimizer_switchprefer_ordering_indexoff

有关此标志及其使用示例的更多信息，请参阅可切换优化和 LIMIT 查询优化。

感谢 Jeremy Cole 的贡献。（缺陷 #97001，缺陷 #30348211）

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

使用具有or谓词的子查询 的单表UPDATE或 语句现在在许多情况下可以使用半连接转换或子查询具体化。这可以在语句不使用or 时完成，并且当子查询中使用的任何优化器提示或 服务器系统变量的值允许半连接或子查询具体化时。 DELETE[NOT] IN[NOT] EXISTSLIMITORDER BYoptimizer_switch

您可以看到半连接优化或子查询具体化何时用于符合条件的单表 DELETE或UPDATE由于优化器跟踪中存在join_optimization对象。您还可以通过检查 ; 的输出看到执行了转换 EXPLAIN FORMAT=TREE；如果不进行优化，则显示<not executable by iterator executor>，而多表语句报告完整计划。

作为这项工作的一部分UPDATE， InnoDB当事务隔离级别弱于 REPEATABLE READ. （错误#35794、错误#96423、错误#11748293、错误#30139244）

添加了optimizer_switch标志 subquery_to_derived。当此标志设置为on时，优化器将符合条件的标量子查询转换为派生表上的左外连接（在某些情况下为内连接）。这种优化可以应用于满足以下条件的子查询：

ANY以及ALL可以重写使用 MIN()或 MAX()不受影响的子查询。

使用subquery_to_derived=on，优化也可以应用于表子查询，它是 、 、 或的参数IN，并且不包含子句。 NOT INEXISTSNOT EXISTSGROUP BY

该subquery_to_derived标志 off默认设置为 ，因为它通常不会提高性能，并且它的大部分预期用途是用于测试目的。

有关更多信息，请参阅 可切换优化，了解更多信息和示例。另请参阅 使用合并或实现优化派生表、视图引用和公用表表达式，以及 LIMIT 查询优化。

在 MySQL 8.0.18 中完成的工作的基础上，服务器现在将强制转换注入查询，以避免在将字符串数据类型与数字或时间类型进行比较时出现不匹配；与比较数字和时间类型时一样，优化器现在在参数的数据类型与预期数据类型不匹配的表达式和条件中的项树中添加转换操作。这使得将字符串类型与数字或时间类型进行比较的查询等同于符合 SQL 标准的查询，同时保持与以前版本的 MySQL 的向后兼容性。=, >=, >, <, <=, <>/!=和 <=>)。

这种隐式转换现在通过将字符串值转换为 ; 在字符串类型（CHAR, VARCHAR, BINARY, VARBINARY, BLOB, TEXT, ENUM或 SET）和数字类型（SMALLINT, TINYINT, MEDIUMINT, INT/ INTEGER, BIGINT; DECIMAL/ NUMERIC; FLOAT, DOUBLE, REAL; 和 BIT）之间执行DOUBLE；如果数值还不是、 或 类型DOUBLE， 它也会被转换为 。一个 值也被转换为 FLOATREALDOUBLEYEARDOUBLE与字符串值比较时（字符串值也是如此）。TIMESTAMP对于字符串类型和/或 值之间的此类比较DATETIME，参数被转换为DATETIME；当一个字符串类型与一个DATE值进行比较时，该字符串被转换为DATE.

例如，查询如被重写并执行为，并在执行之前转换为。 SELECT * FROM t1 JOIN t2 ON t1.char_col = t2.int_colSELECT * FROM t1 JOIN t2 ON CAST(t1.char_col AS DOUBLE) = CAST(t2.int_col AS DOUBLE)SELECT * FROM t1 JOIN t2 ON t1.varchar_col = t2.timestamp_colSELECT * FROM t1 JOIN t2 ON CAST(t1.varchar_col AS DATETIME) = CAST(t2.timestamp_col AS DATETIME)

EXPLAIN ANALYZE您可以通过查看、EXPLAIN FORMAT=JSON或 的输出来了解何时将强制转换注入给定查询EXPLAIN FORMAT=TREE。EXPLAIN [FORMAT=TRADITIONAL]也可以使用，但在这种情况下，有必要在执行 EXPLAIN语句后发出 SHOW WARNINGS以查看重写的查询。

此更改预计不会导致查询结果或性能出现任何差异。

对于 RPM 和 Debian 软件包，客户端插件已从服务器软件包移至客户端软件包。此外，客户端插件的调试版本已移至测试包。（错误#31123564，错误#31336340）

适用于 Windows 的 MSI 程序包不再包含旧版服务器数据组件。（缺陷号 31060177）

捆绑的 Protobuf 库从 3.6.1 版升级到 3.11 版。（缺陷 #31000511，缺陷 #98852）

libevent与 MySQL 捆绑 的库已升级到版本 2.1.11。另外，对于 CMake选项，做了如下两处改动： WITH_LIBEVENT

（缺陷号 30926742）

与 MySQL 捆绑在一起的 ICU（Unicode 国际组件）库已升级到 65.1 版。

实现 SASL LDAP 身份验证的 MySQL Enterprise Editionauthentication_ldap_sasl插件支持多种身份验证方法，但根据主机系统配置，它们可能并非全部可用。新的 Authentication_ldap_sasl_supported_methods 状态变量为支持的方法提供了可发现性。它的值是由空格分隔的受支持方法名称组成的字符串。例子："SCRAM-SHA1 GSSAPI"

不兼容的更改： 访问 INFORMATION_SCHEMA.FILES表现在需要PROCESS权限。

此更改会影响mysqldump 命令的用户，该命令访问表中的 FILES表空间信息，因此现在PROCESS也需要该权限。不需要转储表空间信息的用户可以通过 使用该 选项调用mysqldump来解决此要求。--no-tablespaces（缺陷号 30350829）

对于捆绑了 OpenSSL 库的平台，用于 MySQL Server 的链接 OpenSSL 库已更新至版本 1.1.1g。在https://www.openssl.org/news/cl111.txt和 https://www.openssl.org/news/vulnerabilities.html中描述了新 OpenSSL 版本中修复的问题 。（缺陷号 31296697）

以前，只能通过为客户端可访问的所有文件启用它或完全禁用它来在客户端控制语句LOCAL的数据加载功能。C API 函数LOAD DATA的新 MYSQL_OPT_LOAD_DATA_LOCAL_DIR选项 使客户端能够将数据加载限制到位于指定目录中的文件。请参阅 LOAD DATA LOCAL 的安全注意事项。 mysql_options()LOCAL

mysql-test-run.pl不再接受命令选项的唯一前缀。必须给出完整的选项名称。（缺陷号 31390127）

MySQL 测试已更新为使用 googletest 1.10.0。（缺陷号 31364750）

更新了innodb.innodb_mysql测试用例以避免输出行顺序的不确定性。感谢 Facebook 的贡献。（漏洞 #30810572，漏洞 #98377）

mysql-test-run.pl现在支持一个 --mtr-port-exclude选项，用于在搜索要使用的可用端口范围时指定要排除的端口范围。MTR_PORT_EXCLUDE 也可以设置环境变量来达到同样的效果。感谢 Facebook 的贡献。（缺陷号 30809607）

除了在收到 CTRL + C (SIGINT) 时中止之外， mysql-test-run.pl现在还显示到那时失败的测试用例列表。（缺陷号 30407014）

在使用美元符号 ($) 引用整个文档的情况下，X Plugin 会根据使用它的上下文以不同方式处理引用。现在已经标准化了。（缺陷号 31374713）

对于全局 SQL 模式的某些设置，X Plugin 的身份验证过程无法接受正确的用户密码。身份验证过程现在独立于全局 SQL 模式的设置运行以确保一致性。（缺陷号 31086109）

重要更改： 默认情况下，复制源服务器为二进制日志中的每个事件写入校验和，由系统变量指定binlog_checksum，默认为设置CRC32。以前，组复制不支持二进制日志中存在校验和，因此 在配置将成为组成员的服务器实例时binlog_checksum必须设置为NONE现在删除了此要求，可以使用默认值。组的所有成员的设置 binlog_checksum不必相同。

请注意，Group Replication 不使用校验和来验证 group_replication_applier通道上的传入事件，因为事件从多个源写入该中继日志，并且在它们实际写入原始服务器的二进制日志之前，即生成校验和时。校验和用于验证 group_replication_recovery通道和组成员上任何其他复制通道上事件的完整性。

性能：UNHEX()通过引入用于将十六进制数字字符串映射到其二进制表示形式的查找表来 改进函数的实现 此更改在测试中将函数的执行速度提高了 8 倍或更多。（缺陷号 31173103）

InnoDB： 现在可以使用 ALTER INSTANCE {ENABLE|DISABLE} INNODB REDO_LOG语法启用和禁用重做日志记录。此功能旨在将数据加载到新的 MySQL 实例中。禁用重做日志记录有助于通过避免重做日志写入来加快数据加载。

新INNODB_REDO_LOG_ENABLE 权限允许启用和禁用重做日志记录。

新的 Innodb_redo_log_enabled状态变量允许监视重做日志状态。

请参阅禁用重做日志记录。

InnoDB： 在繁忙的系统上截断撤消表空间可能会影响性能，因为相关的刷新操作会从缓冲池中删除旧的撤消表空间页面并将新撤消表空间的初始页面刷新到磁盘。为解决此问题，删除了刷新操作。

旧的撤消表空间页面现在会在最近最少使用时被动释放，或者在下一个完整检查点被删除。新撤消表空间的初始页面现在在截断操作期间被重做记录而不是刷新到磁盘，这也提高了撤消表空间截断操作的持久性。

为了防止过多的撤消表空间截断操作引起的潜在问题，检查点之间对同一撤消表空间的截断操作现在限制为 64。如果超过限制，撤消表空间仍然可以变为非活动状态，但不会被截断直到下一个检查点之后。

INNODB_METRICS与失效的撤消截断刷新操作关联的计数器已被删除。删除的计数器包括： undo_truncate_sweep_count、 undo_truncate_sweep_usec、 undo_truncate_flush_count和 undo_truncate_flush_usec。

请参阅撤消表空间。

InnoDB： 在启动时，InnoDB根据存储在数据字典中的表空间文件路径验证已知表空间文件的路径，以防表空间文件已移动到其他位置。新 innodb_validate_tablespace_paths 变量允许禁用表空间路径验证。此功能适用于不移动表空间文件的环境。禁用表空间路径验证可缩短具有大量表空间文件的系统的启动时间。

有关详细信息，请参阅 禁用表空间路径验证。

InnoDB： 使用该DATA DIRECTORY子句在数据目录之外创建的表和表分区数据文件现在仅限于 InnoDB. 此更改允许数据库管理员控制创建表空间数据文件的位置，并确保在恢复期间可以找到数据文件。

一般和每个表文件表空间数据文件 (.ibd文件 ) 不能再在撤消表空间目录 ( innodb_undo_directory) 中创建，除非直接知道InnoDB。

已知目录是由 datadir、 innodb_data_home_dir和 innodb_directories变量定义的目录。

截断InnoDB驻留在 file-per-table 表空间中的表会删除现有表空间并创建一个新表空间。从 MySQL 8.0.21 开始，InnoDB 如果表空间是使用较早版本创建的并且当前表空间目录未知，则在默认位置创建新表空间并将警告写入错误日志。要在其当前位置创建表空间，请在运行之前TRUNCATE TABLE将目录添加到 设置中。 innodb_directoriesTRUNCATE TABLE

InnoDB： 为了提高需要访问表和行资源的锁队列的操作的并发性，锁系统 mutex (lock_sys->mutex) 被分片闩锁取代，锁队列被分组为表和页 锁队列分片，每个分片由一个专用互斥体。以前，单锁系统mutex保护所有的锁队列，这是高并发系统的一个争论点。新的分片实现允许更细粒度地访问锁队列。

锁系统互斥锁 ( lock_sys->mutex) 被以下分片锁存器取代：

用于监视单锁系统互斥锁的 Performance Schema wait/synch/mutex/innodb/lock_mutex工具被用于监视新的全局、表分片和页面分片锁存器的工具所取代：

以前，该 --disabled-storage-engines选项不会忽略选项值中列出的存储引擎周围的空格。引擎名称周围的空格现在被忽略。（漏洞 #31373361，漏洞 #99632）

新的HANDLE_FATAL_SIGNALS CMake选项支持配置 Address Sanitizer 和 Undefined Behavior Sanitizer 构建是否使用消毒器运行时库来处理致命信号，而不是 MySQL 内部函数。选项默认 ON用于非消毒剂构建， OFF用于消毒剂构建。如果选项是 OFF，则默认操作用于 SIGBUS、SIGILL 和 SIGSEGV，而不是内部函数。（缺陷号 31068443）

使用在GROUP BY（通过别名）中重复两次或更多次的列，结合 ROLLUP，其行为与 MySQL 5.7 不同。例子：

SELECT a, b AS a, COUNT(*) FROM t1 GROUP BY a, b WITH ROLLUP;

此类查询的行为已更改为更好地匹配 MySQL 5.7。但是，应避免使用它们，因为将来行为可能会再次发生变化，或者此类查询可能变得非法。（漏洞 #30921780，漏洞 #98663）

comp_err为某些输入文件问题提供更好的错误消息。感谢 Facebook 的贡献。（缺陷 #30810629，缺陷 #98390）

MySQL Server Docker 容器现在支持在客户端会话中重新启动服务器（例如，当 客户端执行 RESTART语句时或在InnoDB Cluster 实例的配置期间）。要启用此重要功能，应在将 docker run选项--restart 设置为 value的情况下启动容器on-failure。有关详细信息，请参阅 启动 MySQL 服务器实例。（缺陷号 30750730）

EXPLAIN ANALYZE现在支持该 FORMAT选项。目前， TREE是唯一受支持的格式。（缺陷号 30315224）

ALTER INSTANCE ROTATE INNODB MASTER KEYread_only或 启用时不再允许 super_read_only。（缺陷号 30274240）

在支持原子 DDL 的存储引擎上， CREATE TABLE ... SELECT当使用基于行的复制时，该语句现在作为一个事务记录在二进制日志中。以前，它被记录为两个事务，一个用于创建表，另一个用于插入数据。通过此更改， CREATE TABLE ... SELECT语句现在对于基于行的复制是安全的，并且允许与基于 GTID 的复制一起使用。有关详细信息，请参阅原子数据定义语句支持。（错误#11756034，错误#47899）

LOAD XML现在支持 CDATA导入 XML 文件中的部分。（缺陷 #98199，缺陷 #30753708）

X 插件的mysqlx_bind_address 系统变量现在像 MySQL 服务器的系统变量一样接受多个 IP 地址bind_address，使 X 插件能够在多个网络套接字上侦听 TCP/IP 连接。

行为上的一个重要区别是，对于 MySQL 服务器，地址列表中的任何错误都会阻止服务器启动，但 X 插件（不是强制插件）不会这样做。对于 X Plugin，如果无法解析其中一个列出的地址，或者如果 X Plugin 无法绑定到它，则跳过该地址，记录一条错误消息，并且 X Plugin 尝试绑定到每个剩余地址。X Plugin 的 Mysqlx_address状态变量仅显示列表中绑定成功的那些地址。如果列出的地址均未导致成功绑定，则 X 插件会记录一条错误消息，指出无法使用 X 协议。

ENGINE_ATTRIBUTE和 SECONDARY_ENGINE_ATTRIBUTE选项已添加到CREATE TABLE、 ALTER TABLE和 CREATE INDEX语法。该 ENGINE_ATTRIBUTE选项也被添加到 CREATE TABLESPACE语法 ALTER TABLESPACE中。允许为表、列、索引和表空间定义存储引擎属性的新选项保留供将来使用。

添加了下INFORMATION_SCHEMA 表，用于查询表、列、索引和表空间的存储引擎属性。值存储在数据字典中。这些表保留供将来使用。

Group Replication 组成员现在可以公布 IP 地址列表，加入成员可以使用这些地址与他们建立连接，以便在分布式恢复期间进行状态传输。以前，现有成员的标准 SQL 客户端连接用于此目的以及客户端流量。相反，广告分布式恢复端点可以让您更好地控制网络基础设施中的分布式恢复流量（包括远程克隆操作和来自二进制日志的状态传输）。成员的分布式恢复端点列表使用新的指定 group_replication_advertise_recovery_endpoints 系统变量，如果 SQL 客户端连接用于分布式恢复，则应用相同的 SSL 要求。

MySQL Server 的默认日志记录级别忽略了信息性日志消息，这些消息以前包括组复制的一些重要生命周期事件，这些事件是非错误情况，例如组成员身份更改。有关复制组重要事件的消息现在已被重新归类为系统消息，因此无论服务器日志记录级别如何，它们总是出现在服务器的错误日志中。因此，操作员可以查看复制组中服务器成员资格的完整历史记录。此外，组通信层上的套接字绑定错误已从信息重新分类为错误消息。

您现在可以使用 、 和 选项在语句上指定用于分布式恢复的 用户 凭据START GROUP_REPLICATION 。这些凭据用于通道上的分布式恢复。当您在 上指定用户凭据时，凭据仅保存在内存中，并通过语句或服务器关闭删除。这些凭据可以替换使用 语句设置的用户凭据，这些凭据存储在复制元数据存储库中，因此可以帮助保护组复制服务器免受未经授权的访问。 USERPASSWORDDEFAULT_AUTHgroup_replication_recoverySTART GROUP_REPLICATIONSTOP GROUP_REPLICATIONCHANGE MASTER TO

提供用户凭据的新方法与在服务器启动时自动启动组复制不兼容。如果先前已使用 CHANGE MASTER TO语句设置用户凭据，则您指定的凭据START GROUP_REPLICATION优先于这些凭据。START GROUP_REPLICATION 但是，如果在没有用户凭据的情况下指定， 则会使用复制元数据存储库中的凭据，如果group_replication_start_on_boot 系统变量设置为ON（包括在分布式恢复的远程克隆操作之后），则会在自动启动时发生。要获得在 上指定用户凭据的安全优势 START GROUP_REPLICATION，请确保将 group_replication_start_on_boot 其设置为OFF（默认为 ON），并使用CHANGE MASTER TO语句清除之前为 group_replication_recovery通道设置的任何用户凭据。

由系统变量指定的组复制中 XCom 消息缓存的最大大小的最小设置 group_replication_message_cache_size 已从大约 1 GB 减少到 134217728 字节，或大约 128 MB。请注意，此大小限制仅适用于缓存中存储的数据，并且缓存结构需要额外的 50 MB 内存。应在所有组成员上设置相同的缓存大小限制。1 GB 的默认 XCom 消息缓存大小（以前也是最小设置）未更改。

提供较小的消息缓存大小是为了能够在可用内存量有限且网络连接良好的主机上进行部署。有一个很低 group_replication_message_cache_size 如果主机位于不稳定的网络上，则不建议设置，因为较小的消息缓存会使组成员在暂时失去连接后更难重新连接。如果在成员临时缺席期间交换的某些消息已从其他成员的 XCom 消息缓存中删除，因为达到了最大大小限制，则该成员无法使用消息缓存重新连接。它必须离开组并重新加入，以便通过分布式恢复检索事务，这是一个比使用消息缓存更慢的过程，尽管成员仍然可以通过这种方式重新加入而无需操作员干预。

请注意，从 MySQL 8.0.21 开始，默认情况下，在将成员从组中驱逐之前添加 5 秒的驱逐超时（由 group_replication_member_expel_timeout 系统变量指定）。因此，使用此默认设置，XCom 消息缓存现在需要在 10 秒内（驱逐超时加上初始 5 秒检测期）存储组交换的消息，而不是像以前那样在 5 秒内存储（仅初始 5 秒检测期）。

group_replication_member_expel_timeout 指定组复制组成员在创建怀疑后等待的时间（以秒为单位），然后将怀疑失败的成员从组中驱逐出去。在产生怀疑之前的最初 5 秒检测期不计入此时间。

之前指定的等待期 group_replication_member_expel_timeout 默认为0，即5秒检测期结束后，疑似会员将立即被驱逐。根据用户反馈，等待时间现在默认为 5 秒，使与群组失去联系的成员总共有 10 秒的时间重新连接到群组。如果此时成员确实重新连接，它可以从 XCom 消息缓存中恢复丢失的消息并自动返回ONLINE 状态，而不是被逐出组并需要自动重新加入程序或人工操作员干预才能重新加入。

如果您之前在成员被驱逐前的默认时间（仅 5 秒检测期）参考预期的消息量调整了 XCom 消息缓存的大小，请增加您的 group_replication_message_cache_size 设置以考虑新的驱逐超时，默认时间加倍至 10 秒。使用新的默认驱逐超时，您可能会开始看到来自 GCS 的关于活动组成员的警告消息，指出一条消息可能需要被当前无法访问的成员恢复，已从消息缓存中删除。此消息表明成员需要使用消息缓存重新连接，并且缓存大小可能不足以支持成员被驱逐前的当前等待时间。

Group Replication 的自动重新加入功能现在默认激活。MySQL 8.0.16 中提供的 group_replication_autorejoin_tries 系统变量使已被驱逐或达到其无法达到的多数超时的成员尝试自动重新加入组。此系统变量最初默认为 0，因此未激活自动重新加入，现在默认为 3，这意味着成员在其被驱逐或无法达到多数超时的情况下进行三次重新加入组的尝试。在每次尝试之间，成员等待 5 分钟。如果在没有成员重新加入或被停止的情况下用完了指定的尝试次数，则该成员继续执行由 group_replication_exit_state_action 系统变量。

自动重新加入功能最大限度地减少了手动干预将成员带回组的需要，特别是在瞬态网络问题相当普遍的情况下。在自动重新加入尝试期间和之间，成员保持超级只读模式并且不接受写入。但是，仍然可以在成员上进行读取，随着时间的推移，过时读取的可能性会增加。如果要干预让成员下线，可以随时使用STOP GROUP_REPLICATION 语句或关闭服务器手动停止成员。如果您不能容忍任何时间段内出现过时读取的可能性，请将 group_replication_autorejoin_tries 系统变量为 0，在这种情况下，每当成员被逐出组或达到其无法到达的多数超时时，都需要操作员干预。

InnoDB：GROUP BY由于类型转换不正确，对 的JSON导致 MySQL 的 UBSan 构建失败。（缺陷号 31451475）

InnoDB：定义 了几个InnoDB没有符号值的错误日志消息。（缺陷号 31401028）

InnoDB： 与双写刷新和同步操作相关的数据文件写入失败后，单页写入的文件段未释放。（缺陷号 31370227）

InnoDB： 撤消表空间截断在删除截断操作之前和之后使用相同的空间 ID 时访问的代码。那种情景不再发生。截断的撤消表空间被具有不同空间 ID 的新撤消表空间数据文件替换。（缺陷号 31354435）

InnoDB： 撤消表空间的保留空间 ID 范围从每个撤消表空间 512 个增加到 400000 个。（缺陷 #31340834）

InnoDB：未返回 将日志插入 ddl_log表时发生的错误，使其看起来操作成功，并且在执行表空间加密操作时未注册事务。（缺陷号 31236217）

InnoDB： 该lob::purge()函数没有为TRX_UNDO_UPD_DEL_REC插入操作修改删除标记的记录时生成的撤消日志记录类型 () 正确释放 LOB。（漏洞 #31222046，漏洞 #99339）

InnoDB： 尝试重建丢弃的分区后发生关机错误。（缺陷号 31215415）

InnoDB：负责检索目录或文件路径 的内部get_real_path()函数已修改为在确定路径是文件还是目录之前去除尾随分隔符。此外，如果路径不存在或无法识别为文件或子目录，如果基本名称具有三个字母后缀，则该函数现在假定该路径是一个文件。（缺陷号 31215160）

InnoDB： 修改了与表空间相关的错误消息。（漏洞 #31205520，漏洞 #31205441）

InnoDB： 为避免潜在的编译问题， __attribute__((const))从 __attribute__((pure))内部InnoDB函数中删除了属性。（缺陷号 31153123）

InnoDB： 在为直方图采样生成读取线程时未观察到并行读取线程限制，导致断言失败。（缺陷号 31151218）

InnoDB： 在为生成直方图统计数据而对记录进行采样时，未检查事务读取视图。（缺陷号 31151077）

InnoDB： 由于另一个线程持有锁存器，I/O 完成例程无法获取 LRU 列表互斥锁。（缺陷号 31128739）

InnoDB： 一个可附加的事务线程请求了一个 InnoDB已经被主线程保留的票证，导致死锁。此外，在这种死锁情况下，服务器无法响应KILL 语句。（缺陷号 31090777）

InnoDB：定义为模块所有者的计数器 的INNODB_METRICS表 AVG_COUNT_RESET该 METRIC_AVG_VALUE_RESET字段被错误地标记为 NULL。感谢 Fungo Wang 的贡献。（漏洞 #31084706，漏洞 #98990）

InnoDB： 在启动时，在撤消表空间截断操作期间意外停止后，发现一些回滚段标头页已损坏。回滚段标头页的加密是在写入标头页时启动的，导致某些标头页未按预期加密。（缺陷号 31045160）

InnoDB：lock_sys重构 了锁系统 ( ) 代码的各个方面lock_sys lock_rec_block_validate()并 lock_test_prdt_pacge_lock()修复了功能问题。该lock_rec_block_validate()函数重复调用另一个函数，这可能导致在某些情况下锁未被验证。该实现还具有潜在的二次时间复杂度。该lock_test_prdt_page_lock()函数没有按预期迭代所有锁。（缺陷号 31001732）

InnoDB： 超过阈值后使用内存映射文件 temptable_max_ram导致性能下降。（错误#30952983，错误#98739）

InnoDB： 在调试模式下，DROP TABLE 对具有错误定义 COMPRESSION子句的表的操作导致失败。 InnoDB没有向调用者返回错误以进行正确处理。（错误#30899683，错误#98593）

InnoDB： 当历史列表长度接近零时，清除线程活动过多，浪费 CPU 资源并导致互斥锁争用。（缺陷号 30875956）

InnoDB： MySQL 8.0.18 中引入的回归影响了 INFORMATION_SCHEMA.INNODB_COLUMNS 查询性能。重复获取架构和表数据字典对象以检索分区列信息。（漏洞 #30837086，漏洞 #98449）

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

InnoDB：对文件 的ALTER TABLE ... IMPORT TABLESPACE操作 .cfg失败，出现“表的密钥文件不正确”错误。该 row_import::m_flags成员未初始化。（缺陷号 30830441）

InnoDB：丢弃分区后执行 的DROP TABLE操作没有删除关联的数据文件，并且DROP DATABASE失败并提示无法删除数据库目录的错误。如果存在带有废弃分区的分区表，从 MySQL 5.7 升级到 MySQL 8.0 也会失败。该 DISCARD属性应用于表对象而不是数据字典中的分区对象，这使得所有分区看起来都被丢弃了。（缺陷号 30818917）

InnoDB： 服务器间歇性失败，出现“ ibuf 游标恢复失败”错误。（漏洞 #30770380，漏洞 #91033）

InnoDB：ALTER TABLE将数据从一个表复制到另一个表 的操作返回“列值超出范围”错误。跟踪AUTO_INCREMENT多行插入操作所需行数的计数器在批量插入操作后并不总是设置回零。（缺陷 #30765952，缺陷 #98211）

InnoDB： 内部 TempTablerecords_in_range() 处理函数包含一个DBUG_ABORT() 调用，该调用导致调试构建中的断言失败，以及某些查询的常规构建中的空结果集。（缺陷号 30716037）

InnoDB： 该btr_cur_pessimistic_update()函数未能处理由 lob::purge()调用引起的游标位置更改。（缺陷号 30712878）

InnoDB：操作 期间的类型转换失败DELETE IGNORE导致断言失败。值 JSON未转换为预期值。（缺陷号 30664660）

InnoDB： 清除操作遇到空 LOB 引用，导致断言失败。（缺陷号 30658887）

InnoDB： 从存储引擎释放内存时，块大小计算不正确TempTable，导致SELECT DISTINCT查询性能下降。（缺陷号 30562964）

InnoDB： 使用线程池插件时，TempTable 存储引擎发生分段错误。TempTable 线程局部变量与对单个客户端连接发出的语句使用不同的线程不兼容。由于线程局部变量使用的内存在线程的生命周期内保持分配，因此使用线程局部变量也会导致过多的内存消耗。为了解决这些问题，线程局部变量被缓存机制所取代。（错误#30050452、错误#31116036、错误#99136）

InnoDB：关闭期间发生 致命的“页面仍然固定或脏”错误。（缺陷 #29759555，缺陷 #95285）

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

分区： 针对使用 的分区表的查询 ORDER BY在以下条件下返回无序结果：

感谢韩全安的建议。（漏洞 #84070，漏洞 #25207522）

Replication：为控制所有用户连接 的系统变量设置的全局值， group_replication_consistency 适用于使用 SQL API 的 Group Replication 到 MySQL Server 模块的内部连接，其处理方式与用户连接类似。这有时会导致 Group Replication 报告使用 group_replication_consistency as 错误，例如在分布式恢复期间检查克隆插件状态时。Group Replication 使用 SQL API 的内部连接现在配置为使用一致性级别EVENTUAL，这与该选项可用之前的行为相匹配 group_replication_consistency ，并且不会导致错误消息。（漏洞 #31303354，漏洞 #99345）

复制： 如果组的一致性级别（由 group_replication_consistency 系统变量设置）设置为BEFORE或 BEFORE_AND_AFTER，则在发生主故障转移时可能会发生死锁。主要故障转移现在以不同方式注册以避免这种情况。（错误#31175066，错误#98643）

复制： 在 Windows 上，Group Replication 使用 Windows API 函数 SleepConditionVariableCS 等待新的写入事件导致该函数在 Group Replication 运行两天或更长时间后明显高 CPU 使用率，可以通过重启 MySQL 服务器实例来纠正，但是然后像以前一样随着时间的推移再次增加。这是由于使用两个时钟函数来计算调用 SleepConditionVariableCS 函数之前的超时，这两个函数随着时间的推移相互漂移，使得超时逐渐变短，函数调用更加频繁。通过使用单个时钟的当前时间来计算超时，此问题已在 Windows 上得到纠正。（缺陷号 31117930）

复制： 如果在进行分布式恢复时停止组复制，则尝试访问被选为捐助者的成员的记录可能会导致内存问题。该记录现在与分布式恢复状态一起保存在本地。（缺陷号 31069563）

复制： 当组复制的分布式恢复涉及远程克隆操作时，在服务器上设置的标志将保持设置状态，直到服务器实例重新启动。以前，如果 Group Replication 在服务器上停止并重新启动，该标志会导致 Group Replication 清除中继日志文件 group_replication_applier通道，这是在远程克隆操作后启动时需要的，以确保与克隆的数据表不匹配。如果清除的中继日志文件中有任何未应用的事务，则该成员随后不能用于引导组，尽管它可以通过从另一个成员检索事务成功加入组。Group Replication 现在在其第二次或后续启动时忽略该标志，并且仅在远程克隆操作后第一次启动时清除中继日志文件。（缺陷号 31059680）

复制： 为了避免数据不一致的可能性，组复制阻止同一服务器的新化身（具有相同地址但新标识符）加入组，而其旧化身仍被列为成员。以前，Group Replication 的 Group Communication System (GCS) 在尝试向服务器发送消息时将与服务器旧化身的连接视为活动状态，并且仅在套接字返回错误时才认识到连接处于非活动状态，这可能花费大量时间。期间，服务器的新化身无法加入群组，因为现有成员没有连接到它，因为他们仍在等待与旧化身的联系。现在，GCS 仅将与服务器的连接视为活动连接，而消息可以成功发送给它。如果套接字不再可写，服务器连接将被视为不活动并主动关闭。连接关闭会触发组成员尝试重新连接到该服务器地址，然后与服务器的新化身建立连接，使新化身能够加入该组。（缺陷号 30770577）连接关闭会触发组成员尝试重新连接到该服务器地址，然后与服务器的新化身建立连接，使新化身能够加入该组。（缺陷号 30770577）连接关闭会触发组成员尝试重新连接到该服务器地址，然后与服务器的新化身建立连接，使新化身能够加入该组。（缺陷号 30770577）

复制： 从单主模式切换到多主模式时，组复制没有广播通知。现在通知更改用于路由。（缺陷号 30738896）

复制： 当复制源服务器关闭并重新启动时，其 MEMORY表变为空。为了将此效果复制到副本，源在启动后第一次使用给定 语句MEMORY写入二进制日志来通知副本必须清空DELETE以前，生成的DELETE语句被写入当前会话的二进制日志语句缓存，这可能导致它与同一 GTID 下的其他语句一起记录，或者在没有 BEGIN语句COMMIT 。此外，在某些情况下，生成的 DELETE语句可以使用用于触发它的事务的 GTID。生成的DELETE语句现在与伴随的语句一起记录，BEGIN生成 COMMIT的事务在写入语句缓存后立即刷新到二进制日志，因此它始终接收自己的 GTID 并与其他事务分开。（错误#30527929，错误#25681518，错误#77729）

Replication： MySQL 8.0.14 补丁后，如果函数调用中包含对临时表的操作，则可以在 binlog_format = MIXED设置时以语句格式写入二进制日志。如果它们包含函数调用，这将导致CREATE TEMPORARY TABLE语句被错误地写入二进制日志。经过进一步分析，存储函数和触发器中临时表的操作现在被标记为对于语句格式的二进制日志不安全，因为它们很有可能导致复制问题。设置后binlog_format = MIXED，这些操作现在以行格式记录。（漏洞 #30395151，漏洞 #30320009）

复制：group_replication_force_members 如果另一个成员已经请求驱逐正在驱动操作的成员，则 设置 group_replication_force_members 。执行由指定的配置的操作 group_replication_force_members 系统变量强制任何挂起的组重新配置首先发生。如果其中一个成功地驱逐了已设置系统变量的成员，因为在该成员上设置的驱逐超时已过期，操作超时且无法完成。为了避免这种情况，Group Replication 现在直接执行由 group_replication_force_members 系统变量指定的新配置，并忽略任何其他挂起的组重新配置。（漏洞 #29820966）

复制： 在 MySQL 8.0.14 和 MySQL 5.7.25 中针对涉及系统变量的死锁场景进行了修复， binlog_transaction_dependency_tracking 并 binlog_transaction_dependency_history_size 具有使用于事务依赖性跟踪的写入集历史不受并发更新保护的副作用。写入集历史记录和跟踪模式现在在访问时被正确锁定。（缺陷 #29719364，缺陷 #95181）

参考资料：另请参阅：Bug #28511326、Bug #91941。

复制： 如果CHANGE MASTER TO发出的语句MASTER_USER指定为空 (MASTER_USER='')，则该语句成功并清除了复制元数据存储库中任何先前指定的用户名。但是，如果随后从存储库中读取信息，例如在组复制通道自动重启期间，则可以用默认用户名代替该通道。此问题现已修复，因此从 MySQL 8.0.21 开始，MASTER_USER如果您始终使用START SLAVE语句或START GROUP_REPLICATION启动复制通道的语句。这种方法意味着复制通道总是需要操作员干预才能重新启动，但用户凭证不会记录在复制元数据存储库中。

该CHANGE MASTER TO语句的文档也已更正，以阐明可以指定MASTER_USER='', 并且仅当您尝试使用空凭据启动复制通道时才会发生由此产生的错误。（漏洞#27357189）

复制： 组复制对与其他组成员的连接的跟踪仅考虑传入连接，而不考虑传出连接。这意味着如果从成员 A 到成员 B 的传出连接中断，例如由于防火墙配置问题，但从成员 B 到成员 A 的传入连接完好无损，成员 A 将显示成员 B 的状态为ONLINE，尽管成员 A 的消息是未到达成员 B。成员 B 会将成员 A 的状态显示为UNREACHABLE. 现在，如果一个组成员开始从另一个与其有活动连接的组成员接收到 ping（在这种情况下，如果成员 A 收到来自成员 B 的 ping），这将被视为连接问题的指示器。如果收到足够多的 ping，则 ping 的接收者（在本例中为成员 A）将关闭连接，以便两个成员的连接状态保持一致。（漏洞 #25660161，漏洞 #84796）

JSON： 当传递给的表达式和路径 JSON_TABLE()产生 JSON null 时，该函数会引发错误，而不是 NULL按要求返回 SQL。（缺陷号 31345503）

JSON： 在 MySQL 5.7 和 8.0.17 之前的 MySQL 8.0 中，服务器在直接使用 测试时尝试将 JSON 布尔值转换为它们的 SQL 对应值IS TRUE，如下所示：

mysql> CREATE TABLE test (id INT, col JSON);

mysql> INSERT INTO test VALUES (1, '{"val":true}'), (2, '{"val":false}');

mysql> SELECT id, col, col->"$.val" FROM test WHERE col->"$.val" IS TRUE;
+------+---------------+--------------+
| id   | col           | col->"$.val" |
+------+---------------+--------------+
|    1 | {"val": true} | true         |
+------+---------------+--------------+

作为 MySQL 8.0.17 中完成的工作的结果，以确保 SQL 条件中的所有谓词都是完整的（即，形式的条件被重写为 ），并且or子句中的or 条件 被转换为反连接， SQL 布尔上下文中的 JSON 值的评估执行与 JSON 整数 0 的隐式比较。这意味着之前显示的查询在 MySQL 8.0.17 及更高版本中返回以下结果： WHERE valueWHERE value <> 0NOT INNOT EXISTSWHEREON

mysql> SELECT id, col, col->"$.val" FROM test WHERE col->"$.val" IS TRUE;
+------+----------------+--------------+
| id   | col            | col->"$.val" |
+------+----------------+--------------+
|    1 | {"val": true}  | true         |
|    2 | {"val": false} | false        |
+------+----------------+--------------+

在这种情况下，服务器现在还会提供警告： 在 SQL 布尔上下文中评估 JSON 值会对 JSON 整数 0 进行隐式比较；如果这不是您想要的，请考虑使用 JSON_VALUE RETURNING 将 JSON 转换为 SQL 数字类型。因此，现在可以使用JSON_VALUE() 如下所示重写查询：

mysql> SELECT id, col, col->"$.val" FROM test
    ->     WHERE JSON_VALUE(col, "$.val" RETURNING UNSIGNED) IS TRUE;
+------+---------------+--------------+
| id   | col           | col->"$.val" |
+------+---------------+--------------+
|    1 | {"val": true} | true         |
+------+---------------+--------------+

（缺陷号 31168181）

JSON：GROUP BY服务器并不总是正确处理对具有多值索引的表 的（缺陷号 31152942）

如果log_error_services一直存在，在某些情况下它可能会在启动期间的错误时间生效。（缺陷号 31464539）

SHOW CREATE USER在某些手动授权表修改后可能会导致服务器退出。（缺陷号 31462844）

部分撤销的一些内存更新可能会产生不正确的权限。（缺陷号 31430086）

如果log_error_verbosity使用 设置SET PERSIST，它在服务器启动期间没有足够早地生效以影响InnoDB 初始化。（缺陷号 31410674）

解析器在拒绝生成的列表达式中的子查询之前错误地提出断言。（缺陷号 31396191）

此版本对退化散列连接（即没有连接条件的连接）进行了以下两个微优化：

这些更改一起处理性能回归，即重写哈希反连接导致NOT EXISTS优化器执行未重写的查询并替换为“找到零行”。为了处理使用嵌套循环的情况，内部的非相关子查询NOT EXISTS不再转换为反连接。

此修复也适用于使用 . （缺陷号 31376809）constant NOT IN (non_correlated_subquery)

配置 -DWITH_EDITLINE=system导致旧库版本的编译失败。（缺陷号 31366715）

以前的 MySQL 发行版中捆绑库的升级libedit导致使用该库的构建出现问题，因此 在某些情况下， mysql客户端中的CTRL + C (SIGINT) 需要以下 Enter 才能生效。（缺陷号 31360025）

AUTO_INCREMENT同时使用和 值表达式 声明的列DEFAULT是不允许的组合，但无法为对列的操作 ALTER TABLE 产生错误。（缺陷号 31331454）SET DEFAULT (expr)AUTO_INCREMENT

可以将 protocol_compression_algorithms 系统变量设置为空字符串。这不再被允许。（缺陷号 31326231）

当参数不明确时，MySQL 服务器内部使用的查找函数返回整数 -1；当此值在用作后续计算中的参数之前被转换为无符号值时，这会导致未定义的行为。现在，当函数返回 -1 时，这将作为错误处理并且不会进一步使用该值。（缺陷号 31326120）

在某些情况下对有符号值取反会导致未定义的行为；为了防止这种情况发生，要取反的值现在被视为无符号。（缺陷号 31325602）

该WEIGHT_STRING()函数并不总是为整数参数返回正确的结果。（缺陷号 31321257）

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

CONCAT('')将or 分配CONCAT_WS('')给变量将变量设置为NULL，而不是空字符串。（错误#31320716、错误#99485、错误#31413167、错误#99722）

更正了在某些情况下特权限制可能被忽略的问题。（错误#31306814，错误#31315692）

某些SELECT用于锁定行的语句权限未正确检查，可能会错误地阻止其他用户。（缺陷号 31293065）

执行文件排序时，内部函数有时会NULL在失败时返回，即使正在排序的子查询不可为空。（缺陷号 31281602）

二进制日志的语句重写在 Windows 上效率低下。（缺陷号 31260698）

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

在执行权限授予操作时，在内存中表示匿名用户的不一致可能会导致问题。（缺陷号 31246179）

如果启用了管理连接接口，竞争条件可能会导致在主连接接口上接受 Unix 套接字文件连接时出现问题。（缺陷号 31241872）

当一个角色被授予时WITH ADMIN OPTION，被授予者只有在激活它后才能管理该角色。（缺陷号 31237368）

default_roles或 系统表 中的无效行role_edges可能会导致服务器行为异常。（缺陷号 31217385）

运行时组件取消初始化失败可能会导致在关闭时将重复的消息写入错误日志。（缺陷号 31217037）

没有完全执行禁止向匿名用户授予角色的禁令。（缺陷号 31215017）

特权升级问题已得到纠正。（缺陷号 31210226）

密钥环keyring_hashicorp插件没有对其配置参数的值执行充分的有效性检查。（缺陷号 31205363）

密钥环keyring_hashicorp插件不允许启用二进制日志加密（通过设置 binlog_encryption系统变量）。（缺陷号 31204841）

密钥环keyring_hashicorp插件不允许插件设置加密密码 audit_log。（缺陷号 31197670）

服务器未正确处理某些使用 REGEXP_SUBSTR()with ORDER BY子句的查询。（缺陷号 31184858）

nullptr纠正 了应用指针算法的一些实例 。（缺陷号 31172750）

如果可用的文件描述符已用完，则 mysql_real_connect()导致客户端退出。（缺陷号 31151052）

使用killall命令启动 mysqld关闭导致没有消息被记录以指示关闭开始。这已得到纠正。（缺陷号 31121907）

mysql_real_connect_nonblocking() 使用无效主机 调用 可能会导致客户端在调用 时退出mysql_close()。（漏洞 #31104389，漏洞 #99112）

对于 Debian 软件包，删除了可能导致安装失败的 Python 2 依赖项。（缺陷号 31099324）

一个潜在的内存泄漏lf_hash_insert() 是固定的。（漏洞 #31090258，漏洞 #99078）

在 LDAP SASL 身份验证插件中，多次调用 sasl_client_done()在某些情况下可能会导致未定义的行为。（缺陷号 31088206）

启用线程池插件后，高并发条件可能会导致客户端上下文丢失，从而导致服务器退出。（缺陷号 31085322）

对于使用 处理的结果集 mysql_use_result()， mysql_fetch_row_nonblocking() 没有增加行数，因此在获取所有行之后，mysql_num_rows() 返回了不正确的行数。（缺陷 #31082201，缺陷 #99073）

删除了EXISTS() 从未实际评估过的不必要的优化。（缺陷号 31069510）

对于使用该 --skip-grant-tables选项启动的服务器，启用partial_revokes 系统变量会导致服务器退出。（错误#31066069，错误#31202963）

使用带有外部引用的递归公用表表达式的查询可能会返回不正确的结果。（缺陷 #31066001，缺陷 #99025）

对于最小字符长度大于 1 个字节的多字节字符集，解析器可能会失败。（缺陷号 31063981）

在某些情况下，该LEAST() 函数可能会返回NULL不可为 null 的输入。（缺陷号 31054254）

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

mysql_real_connect_nonblocking()MYSQL_OPT_CONNECT_TIMEOUT 如果设置了选项，则被 阻止。（漏洞 #31049390，漏洞 #98980）

最后一次调用 mysql_fetch_row_nonblocking()C API 函数以返回空行是在不应该设置错误的情况下设置错误。（缺陷 #31048553，缺陷 #98947）

在 Windows 上，默认连接类型使用命名管道。用于 TCP/SSL 连接的非阻塞 C API 没有考虑到这一点并导致客户端退出。它现在会生成一条错误消息来指示问题。（缺陷号 31047717）

由于用户不存在而导致身份验证失败的 X 插件连接修改了全局 audit_log_filter_id系统变量。（缺陷号 31025461）

LOAD DATA解析输入文件行时不忽略隐藏的生成列。（漏洞 #31024266，漏洞 #98925）

元数据锁定子系统中的 Pinbox 耗尽可能会产生误导性的错误消息。（漏洞 #31019269，漏洞 #98911）

CREATE TABLE ... SELECT如果它包含功能索引，则失败。（缺陷 #31017765，缺陷 #98896）

对于 X 协议连接，改进了检查全局会话互斥锁以消除随着线程数量增加而出现的轻微性能下降。（缺陷号 31000043）

在某些情况下，执行包含多个子查询的查询可能会导致服务器意外关闭。（缺陷号 30975826）

SHOW CREATE TRIGGER如果有效则失败 FLUSH TABLES WITH READ LOCK。（缺陷号 30964944）

对构成 INFORMATION_SCHEMA视图基础的某些数据字典表执行了过多的访问检查，导致 SHOW COLUMNS性能下降。减少了这些检查以提高性能。

此外，发现SHOW 作为查询实现的几个语句INFORMATION_SCHEMA 受益于 为系统变量启用derived_merge标志 。optimizer_switch此类查询现在在内部暂时启用该标志以获得更好的性能，而不管标志会话值如何。受影响的查询是：

SHOW SCHEMAS
SHOW TABLES
SHOW TABLE STATUS
SHOW COLUMNS
SHOW KEYS
SHOW EVENTS
SHOW TRIGGERS
SHOW PROCEDURE STATUS
SHOW FUNCTION STATUS
SHOW CHARACTER SET
SHOW COLLATION

（错误#30962261、错误#98750、错误#30921214）

当使用区分大小写的排序规则时，分别执行的两个在其他方面相同的查询返回一行，而使用不区分大小写的排序规则返回两行。当使用 将相同的两个谓词组合在单个查询中AND时，本应只返回一行，但返回了两行。（缺陷号 30961924）

ALTER TABLE在 SET显示宽度大于 255 的列上，即使可能，也没有就地完成。（错误#30943642，错误#98523）

ULLONG_MAX服务器通过将双精度值与不能表示为双 精度的值进行比较，检查以 Yottabytes 为单位的数字是否太大而无法打印 。这导致紧接在 ULLONG_MAXyottabytes 之上的双精度值被打印为 0YClang 10 报告的错误转换。（缺陷 #30927590）

资源组 SQL 语句，例如 CREATE RESOURCE GROUP在使用 X 协议的连接上不起作用。（缺陷号 30900411）

SHOW GRANTS可以将函数特权显示为过程特权。（缺陷 #30896461，缺陷 #98570）

当audit_log多个客户端同时连接时，插件错误处理连接事件。（缺陷号 30893593）

该LOCK_ORDER工具报告了空依赖关系图的语法错误。现在允许使用空图。

LOCK_ORDER由于线程列表维护处理不当 ，该工具可能会出现意外行为。（缺陷号 30889192）

REPLICATION_APPLIER从MySQL 5.7 升级未授予 root. （缺陷号 30783149）

用户定义的gen_range()函数可能对其参数处理不当，导致服务器退出。（缺陷号 30763294）

在UPDATE处理过程中，将内部内存表转换为 InnoDB可能会导致密钥长度错误。（缺陷号 30674616）

尝试在过程或函数级别授予动态特权（始终是全局的）不会产生错误。（缺陷号 30628160）

表值构造函数忽略了该LIMIT 子句。现在考虑该条款。例如： VALUES ROW(1), ROW(2), ROW(3) LIMIT 2输出 1 和 2。（错误号 30602659）

可以定义一个名为* （单个星号字符）的列，但SELECT `*` 被视为与 相同SELECT *，因此不可能在查询中仅选择该列；换句话说，星号字符被扩展为所有表列的列表，即使它被反引号包围。（缺陷号 30528450）

该FROM_DAYS()函数可能会产生超出范围的结果（年份 > 9999）。（漏洞 #30455845，漏洞 #97340）

对于调试版本，将mysql.func 表更改为MyISAM（在任何情况下都不是推荐的操作）会导致服务器退出。现在这个操作是被禁止的。（错误#30248138，错误#96692）

由于在它们的定义中使用，对INFORMATION_SCHEMA KEY_COLUMN_USAGE和 视图 的查询可能会很慢。这些被重写以将 移动 到 表中，以使优化器能够更好地使用索引。（错误#30216864、错误#30766181、错误#98238）TABLE_CONSTRAINTSUNIONUNIONLATERAL

在某些情况下，LIMIT子句错误地导致优化器估计需要从表中读取零行。（缺陷号 30204811）

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

内部数据包长度函数返回错误整数类型的值。（缺陷号 30139031）

mysqldump对语句长度的 计算INSERT没有考虑_binary用于VARBINARY 字符串的字符集引入器。（缺陷 #29998457，缺陷 #96053）

在升级使用前缀键定义的分区表期间打印到错误日志的消息没有提供足够的详细信息。现在打印指示架构、表、列和前缀长度的详细警告。（漏洞 #29942014）

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

mysql_store_result()可能无法检测到无效的数据包。（漏洞#29921423）

如果在外键关系中创建子表导致引擎替换，则会引发断言。（缺陷 #29899151，缺陷 #95743）

mysqltest和 mysql-test-run.pl不再支持 --sleep命令行选项。 mysqltest不再支持该 real_sleep命令。（缺陷号 29770237）

服务器允许名称超过最大允许长度（255 个字符）的主机连接。（漏洞 #29704941）

在UPDATE更新首张表key的多表中，如果使用临时表策略，可能会在临时表中写入重复的条目，导致Can't find record错误。（漏洞 #28716103）

服务器有时会在优化查询时错误地删除带有 a 的子 GROUP BY查询，即使在某些情况下该子查询被外部选择使用。当子查询也使用聚合函数时，可能会发生这种情况。（缺陷号 28240054）

功能的可强制性NAME_CONST() 评估不正确。（缺陷号 26319675）

从存储引擎读取行时，除了 “没有更多记录”之外的错误可能会被忽略，从而导致以后出现问题。（缺陷号 20162055）

当多表更新使用临时表时，这不会显示在 的输出中 EXPLAIN FORMAT=TREE，即使这种使用可能会对执行UPDATE 此操作的语句的性能产生影响。（漏洞#17978975）

当执行文件排序以删除重复项时，例如执行 时SELECT DISTINCT，之后可能需要执行另一种排序以满足 ORDER BY. 如果这样的 an ORDER BY已被下推到连接的第一个表中，而不是作为一个整体连接，则实际上不会执行此最终排序。（缺陷 #99687，缺陷 #31397840）

在 MySQL 8.0.20 中完成的重构工作导致非可空列的单行缓冲GROUP BY无法正常运行，没有考虑到这样的列可能是外部连接的内表，因此会有一个NULL标志需要复制。在GROUP BY没有临时表的情况下，这将导致NULL 标志来自下一个输出行而不是前一个输出行，并且返回的数据不一致。（缺陷 #99398，缺陷 #31252625）

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

常量折叠代码中的逻辑错误对于类型常量DECIMAL 或是FLOAT左侧操作数而整数列值是右侧操作数的情况产生了不正确的结果。（缺陷 #99145，缺陷 #31110614）

其谓词0与 -0其中至少一个浮点值进行比较的查询返回了不正确的结果。（缺陷 #99122，缺陷 #31102789）

在不使用切片的情况下重新实现汇总。这修复了以下已知问题：

（错误#98768、错误#99141、错误#26227613、错误#29134467、错误#30967158、错误#30969045、错误#31110494）

SELECT DISTINCT( HEX( WEIGHT_STRING(varchar_column) ) )返回截断的结果。（缺陷 #98592，缺陷 #30898753）

MAX()使用、 MIN()或两者 的查询中的错误处理问题与 GROUP BY子句相结合，意味着这样的查询会继续执行，直到它通过所有可能的迭代，即使错误应该导致它立即终止也是如此。（缺陷 #98242，缺陷 #30769515）

LEAST()在重构、 GREATEST()和其他函数以及 的类型传播代码之后 UNION，数据类型的结果类型调整 ENUM也将计算的整数数据类型替换为无法同时容纳有符号和无符号值的类型。（缺陷 #95148，缺陷 #29698617）

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