MySQL 复制：带标签的 GTIDs。 全局事务标识符（GIDs）在 MySQL 复制和组复制中的格式已被扩展，以便识别事务组，使得可以将唯一名称分配给属于特定事务组的 GTIDs。例如，仅通过比较 GTIDs 就可以轻松地将包含数据操作的事务与来自管理操作的事务区分开。

新的 GTID 格式为 UUID：TAG：NUMBER，其中 TAG 是一个最多 8 个字符的字符串，通过设置系统变量 gtid_next 的值为 AUTOMATIC：TAG 实现的（请参阅变量的描述以获取标签格式和其他信息）。该标签将在当前会话中所有事务的提交时生效（除非使用 SET gtid_next 更改），或在使用组复制时，在认证时生效。也可以将 gtid_next 设置为 UUID：TAG：NUMBER 以设置单个事务的 UUID 和自定义标签。UUID 和 NUMBER 的分配方式与之前的 MySQL 版本相同。在任何情况下，用户都需要确保标签在给定的复制拓扑结构中是唯一的。

原始的 UUID：NUMBER 格式的 GTIDs 仍然得到支持，未经修改地继承自之前的 MySQL 版本；不需要更改现有的使用 GTIDs 的复制设置。

将 gtid_next 设置为 AUTOMATIC：TAG 或 UUID：TAG：NUMBER 需要新的 TRANSACTION_GTID_TAG 权限，该权限是在本版本中添加的；这适用于源服务器和复制 applier 线程的 PRIVILEGE_CHECKS_APPLIER。这也意味着管理员现在可以限制使用 SET @gtid_next=AUTOMATIC：TAG 或 UUID：TAG：NUMBER 的 MySQL 用户或角色，以便只有相关的数据或操作域的用户可以提交带标签的事务。

内置函数 GTID_SUBSET()、GTID_SUBTRACT() 和 WAIT_FOR_EXECUTED_GTID_SET() 与带标签的 GTIDs 兼容。

有关更多信息，请参阅gtid_next系统变量和TRANSACTION_GTID_TAG权限的描述，以及第 19.1.4 节，“在线服务器上的 GTID 模式更改”。

EXPLAIN FORMAT=JSON 格式版本控制。 现在可以使用explain_json_format_version服务器系统变量选择 EXPLAIN FORMAT=JSON 语句的 JSON 输出格式的两个版本之一。在这个版本中，设置该变量为 1 将导致服务器使用 Version 1，即线性格式，该格式曾经是 MySQL 8.2 及更早版本中该语句的输出格式。这是 MySQL 8.3 中的默认值和格式。设置 explain_json_format_version 为 2 将导致使用 Version 2 格式，该 JSON 输出格式基于访问路径，旨在提供与未来版本的 MySQL 优化器的更好兼容性。

请参阅获取执行计划信息，以获取更多信息和示例。

DDL 和 DCL 语句跟踪 group_replication_set_as_primary()。 group_replication_set_as_primary() 现在等待以下语句完成，然后选举新的主服务器：

这些是在 MySQL 8.1 或其他已经支持的语句中添加的。此外，还有更多信息，包括 MySQL 8.3 中支持的所有语句的列表，请参阅 group_replication_set_as_primary() 函数的描述。

基于 Windows 的 SASL LDAP 身份验证  在 Microsoft Windows 上，现在支持服务器插件用于基于 SASL 的 LDAP 身份验证。这意味着 Windows 客户端现在可以使用 GSSAPI/Kerberos 来与 authentication_ldap_sasl_client 插件进行身份验证。

有关更多信息，请参阅 基于 SASL 的 LDAP 身份验证。

binlog_transaction_dependency_tracking 默认值的更改  在 MySQL 8.2.0 中，binlog_transaction_dependency_tracking 服务器系统变量被弃用。为准备删除该变量，现在其默认值为 WRITESET。没有计划替换该变量或其功能，该功能预计将在服务器内部实现。

WITH_LD CMake 选项  定义是否使用 llvm lld 或 mold 链接器，否则使用标准链接器。WITH_LD 也取代了在 MySQL 8.3.0 中删除的 USE_LD_LLD CMake 选项。

MySQL 企业数据屏蔽和去标识  数据屏蔽组件添加了对指定专用模式来存储相关内部表和屏蔽函数的支持。以前，mysql 系统模式提供了唯一的存储选项。新的 component_masking.masking_database 只读变量启用了在服务器启动时设置和持久化替代模式名称。

线程池插件连接信息  添加了线程池连接信息到 MySQL 性能模式中，如下所示：

有关更多信息，请参阅 第 7.6.3 节，“MySQL 企业线程池”，和 第 29.12.16 节，“性能模式线程池表”。

信息模式 PROCESSLIST 表使用  尽管 INFORMATION_SCHEMA.PROCESSLIST 表在 MySQL 8.0.35 和 8.2.0 中被弃用，但仍然对其使用情况感兴趣。本版本添加了两个系统状态变量，提供了对 PROCESSLIST 表的访问信息，列举如下：

数据屏蔽字典的刷新。 MySQL Enterprise Data Masking 和 De-Identification 组件现在包括将数据从辅助或副本中刷新到内存的能力。这可以通过以下两种方式之一完成：

有关更多信息，请参阅 第 8.5 节，“MySQL Enterprise 数据屏蔽和去标识化”，以及这些项目的描述。

组复制恢复元数据。 组复制恢复不再依赖于二进制日志中的视图更改事件来标记组成员身份的变化；相反，当所有组成员都是 MySQL 8.3.0 或更高版本时，成员共享压缩恢复元数据，不再记录视图更改事件（或分配 GTID）当新成员加入组时。

恢复元数据包括 GCS 视图 ID、GTID_SET certified 交易和认证信息，以及在线成员的列表。

由于 View_change_log_event 不再在恢复中扮演角色，因此 group_replication_view_change_uuid 系统变量不再需要，现在弃用；预计在未来 MySQL 版本中删除该变量，不计划提供替代或替代该变量或其功能的解决方案，请相应地开发应用程序。

C API 函数删除。 以下 MySQL C API 函数在之前的 MySQL 版本中弃用，现在删除：

mysql_shutdown()在 MySQL 8.0 中已弃用；其余函数在 MySQL 5.7.11 中已弃用。

由于这些更改，MySQL C API 库版本从 22.1 提高到 23.0。

FLUSH HOSTS 语句。 FLUSH HOSTS 语句，在 MySQL 8.0.23 中已弃用。要清除主机缓存，请执行TRUNCATE TABLE performance_schema.host_cache 或mysqladmin flush-hosts。

过时的复制选项和变量。 一些与 MySQL 复制相关的选项和变量在之前的 MySQL 版本中已弃用，现在从 MySQL 8.3 中删除。尝试使用任何这些选项或变量现在将导致服务器引发语法错误。这些选项和变量列举如下：

--skip-host-cache 服务器选项.  该选项已被删除；使用 --host-cache-size=0 启动服务器 instead. 参见 第 7.1.12.3 节，“DNS 查找和主机缓存”.

--innodb 和 --skip-innodb 服务器选项.  这些选项已被删除。 InnoDB 存储引擎始终启用，无法禁用它。

--character-set-client-handshake 和 --old-style-user-limits 服务器选项.  这些选项以前用于与非常旧版本的 MySQL 兼容，现已不再支持或维护，因此不再有任何有用的目的。

过时的 CMake 选项.  编译服务器时以下 CMake 选项已过时并被删除：

基于 GTID 的复制和 IGNORE_SERVER_IDS.  使用全局事务标识符 (GTID) 时，已经应用的事务将自动被忽略。这意味着 IGNORE_SERVER_IDS 不兼容 GTID 模式。如果 gtid_mode 是 ON，则 CHANGE REPLICATION SOURCE TO 带有非空 IGNORE_SERVER_IDS 列表将被拒绝并出现错误。同样，如果任何现有的复制通道是使用要忽略的服务器 ID 列表创建的，SET gtid_mode=ON 也将被拒绝。在开始基于 GTID 的复制之前，请检查并清除涉及的服务器的忽略服务器 ID 列表；您可以通过检查 SHOW REPLICA STATUS 的输出来实现。在这种情况下，您可以通过发出 CHANGE REPLICATION SOURCE TO 带有空的服务器 ID 列表来清除列表，如下所示：

CHANGE REPLICATION SOURCE TO IGNORE_SERVER_IDS = ();

参见 第 19.1.3.7 节，“使用 GTID 的复制限制”，以获取更多信息。

二进制日志事务依赖跟踪和日志格式.  使用写集信息进行冲突检测已被发现会导致依赖跟踪问题；因此，我们现在限制使用写集信息进行冲突检查，以便仅在基于行的日志记录生效。

这意味着，从本版本开始，如果 binlog_transaction_dependency_tracking 设置为 WRITESET 或 WRITESET_SESSION，则 binlog_format 必须是 ROW；MIXED 不再支持在这种情况下。