标签：语句 8.0 1.3 MySQL JSON 使用 ER

 

本节总结了已添加到MySQL 8.0中，已弃用和从MySQL 8.0中删除的内容。随附的部分列出了在MySQL 8.0中已添加，不建议使用或删除的MySQL服务器选项和变量。请参见 第1.4节“在MySQL 8.0中添加，不建议使用或删除的服务器和状态变量及选项”。

• MySQL 8.0中添加的功能

• MySQL 8.0中不推荐使用的功能

• MySQL 8.0中删除的功能

MySQL 8.0中添加的功能

以下功能已添加到MySQL 8.0：

• 数据字典。  MySQL现在合并了一个事务性数据字典，用于存储有关数据库对象的信息。在以前的MySQL版本中，字典数据存储在元数据文件和非事务表中。有关更多信息，请参见第14章，MySQL数据字典。

• 原子数据定义语句（Atomic DDL）。  原子DDL语句将数据字典更新，存储引擎操作以及与DDL操作关联的二进制日志写入操作组合到单个原子事务中。有关更多信息，请参见 第13.1.1节“原子数据定义语句支持”。

• 升级程序。  以前，在安装新版本的MySQL之后，MySQL服务器会在下次启动时自动升级数据字典表，此后，DBA有望 手动调用mysql_upgrade来升级mysql架构中的系统表 以及其他模型中的对象。架构，例如sys架构和用户架构。

  从MySQL 8.0.16开始，服务器执行以前由mysql_upgrade处理的任务。在安装新的MySQL版本之后，服务器现在将在下次启动时自动执行所有必要的升级任务，并且不依赖于DBA调用 mysql_upgrade。另外，服务器更新帮助表的内容（ mysql_upgrade没做的事情）。新的 --upgrade服务器选项可控制服务器如何执行自动数据字典和服务器升级操作。有关更多信息，请参见 第2.11.3节“ MySQL升级过程将升级什么”。

• 安全性和帐户管理。  添加了这些增强功能，以提高安全性并在帐户管理中提供更大的DBA灵活性：

  • mysql现在 ，系统数据库中的授权表是InnoDB （事务性）表。以前，这些是 MyISAM（非事务性）表。授予表存储引擎的更改是帐户管理对帐单行为的伴随更改的基础。以前，帐户管理对帐单（例如 CREATE USER或 DROP USER），命名多个用户可以对某些用户成功，而对其他用户则失败。现在，每个语句都是事务性的，并且对于所有指定的用户都成功，或者回滚，并且在发生任何错误时都不起作用。如果成功，则将语句写入二进制日志；如果失败，则不写入语句。在这种情况下，将发生回滚并且不进行任何更改。有关更多信息，请参见第13.1.1节“原子数据定义语句支持”。

  • 一个新的caching_sha2_password 身份验证插件可用。像sha256_password插件一样 ， caching_sha2_password实现SHA-256密码哈希，但是使用缓存来解决连接时的延迟问题。它还支持更多的传输协议，并且不需要针对基于RSA密钥对的密码交换功能而针对OpenSSL进行链接。请参见 第6.4.1.2节“缓存SHA-2可插拔身份验证”。

    该caching_sha2_password和 sha256_password认证插件提供比更安全的密码加密 mysql_native_password插件，并 caching_sha2_password提供了比更好的性能sha256_password。由于的这些优越的安全性和性能特征 caching_sha2_password，它现在是首选的身份验证插件，并且也是默认的身份验证插件，而不是 mysql_native_password。有关此默认插件更改对服务器操作以及服务器与客户端和连接器的兼容性的影响的信息，请参阅 caching_sha2_password作为首选身份验证插件。

  • MySQL现在支持角色，这些角色被称为特权集合。可以创建和删除角色。角色可以具有授予和撤销的特权。可以向用户帐户授予角色或从用户帐户撤消角色。可以从授予该帐户的角色中选择该帐户的活动适用角色，并且可以在该帐户的会话期间进行更改。有关更多信息，请参见第6.2.10节“使用角色”。

  • MySQL现在合并了用户帐户类别的概念，根据系统用户和普通用户是否具有SYSTEM_USER特权来区分它们 。请参见第6.2.11节“帐户类别”。

  • 以前，除了某些模式之外，不可能授予全局适用的特权。现在，如果partial_revokes启用了 系统变量，则可以这样做。请参见 第6.2.12节“使用部分撤销的权限限制”。

  • 该GRANT语句有一个子句，用于指定有关用于语句执行的特权上下文的其他信息。该语法在SQL级别上可见，尽管其主要目的是通过使这些限制出现在二进制日志中，从而在由部分吊销施加的授予者特权限制的所有节点之间实现统一复制。请参见 第13.7.1.6节“ GRANT语句”。 AS user [WITH ROLE]

  • MySQL现在维护有关密码历史记录的信息，从而限制了对先前密码的重用。DBA可能要求在一定数量的密码更改或一段时间内，不要从以前的密码中选择新密码。可以在全局范围内以及每个帐户基础上建立密码重用策略。

    现在可以要求通过指定要替换的当前密码来验证更改帐户密码的尝试。这使DBA可以防止用户在不证明他们知道当前密码的情况下更改密码。可以在全局范围内以及每个帐户基础上建立密码验证策略。

    现在允许帐户具有双重密码，这使得在复杂的多服务器系统中无缝执行阶段性密码更改而无需停机。

    现在，MySQL使管理员能够配置用户帐户，以使由于密码错误而导致的连续登录失败过多，从而导致临时帐户锁定。所需的失败次数和锁定时间可以每个帐户配置。

    这些新功能使DBA可以更全面地控制密码管理。有关更多信息，请参见第6.2.15节“密码管理”。

  • 如果使用OpenSSL进行编译，MySQL现在支持FIPS模式，并且在运行时可以使用OpenSSL库和FIPS对象模块。FIPS模式对加密操作施加了条件，例如对可接受的加密算法的限制或对更长密钥长度的要求。请参见第6.8节“ FIPS支持”。

  • 服务器用于新连接的TLS上下文现在可以在运行时重新配置。例如，此功能可能很有用，可避免重启已经运行了很长时间的MySQL服务器（其SSL证书已过期）。请参阅 服务器端运行时配置和监视加密连接。

  • 如果服务器和客户端均使用OpenSSL 1.1.1或更高版本进行编译，则OpenSSL 1.1.1支持TLS v1.3协议进行加密连接，而MySQL 8.0.16和更高版本也支持TLS v1.3。请参见 第6.3.2节“加密的连接TLS协议和密码”。

  • 现在，MySQL将授予命名管道上的客户端的访问控制设置为在Windows上成功进行通信所需的最低要求。较新的MySQL客户端软件无需任何其他配置即可打开命名管道连接。如果不能立即升级旧的客户端软件，named_pipe_full_access_group 则可以使用新的 系统变量为Windows组授予打开命名管道连接的必要权限。完全访问权限组的成员资格应受到限制且是临时的。

• 资源管理。  MySQL现在支持创建和管理资源组，并允许将服务器中运行的线程分配给特定的组，以便线程根据该组可用的资源执行。使用组属性可以控制其资源，以启用或限制组中线程的资源消耗。DBA可以根据不同的工作负载修改这些属性。当前，CPU时间是一种可管理的资源，以“ 虚拟CPU ”的概念表示包括CPU内核，超线程，硬件线程等等的术语。服务器在启动时确定有多少个虚拟CPU可用，具有适当特权的数据库管理员可以将这些CPU与资源组关联，并为组分配线程。有关更多信息，请参见 第5.1.15节“资源组”。

• 表加密管理。  现在，可以通过定义和强制执行加密默认值来全局管理表加密。该 default_table_encryption 变量为新创建的模式和常规表空间定义加密默认值。DEFAULT ENCRYPTION创建模式时，也可以使用子句定义模式的加密默认值。默认情况下，表继承在其内创建的模式或常规表空间的加密。通过启用 table_encryption_privilege_check 变量。当使用不同于设置的加密设置创建或更改模式或常规表空间default_table_encryption 时，或者使用不同于默认模式加密的加密设置创建或更改表时，将进行特权检查 。 启用该 TABLE_ENCRYPTION_ADMIN 特权后，将允许覆盖默认的加密设置 table_encryption_privilege_check。有关更多信息，请参见 为模式和常规表空间定义加密默认值。

• InnoDB增强功能。  这些InnoDB增强功能已添加：

  • 每次值更改时，当前最大自动增量计数器值都会写入重做日志，并保存到每个检查点的引擎专用系统表中。这些更改使当前的最大自动增量计数器值在服务器重新启动后保持不变。另外：

    • 重新启动服务器不再取消 AUTO_INCREMENT = Ntable选项的作用。如果将自动递增计数器初始化为特定值，或者将自动递增计数器值更改为较大的值，则新值将在服务器重新启动后保留。

    • 在ROLLBACK 操作之后立即重新启动服务器， 不再导致重用分配给回​​滚事务的自动增量值。

    • 如果将AUTO_INCREMENT 列值修改为大于当前最大自动增量值的值（UPDATE例如，在一个 操作中），则将保留新值，并且后续 INSERT操作将从新的较大值开始分配自动增量值。

    有关更多信息，请参见 第15.6.1.6节“ InnoDB中的AUTO_INCREMENT处理”和 InnoDB AUTO_INCREMENT计数器初始化。

  • 遇到索引树损坏时， InnoDB将损坏标志写入重做日志，这会使损坏标志崩溃。InnoDB还将内存损坏标志数据写入每个检查点上的引擎专用系统表。在恢复期间， InnoDB在将内存中的表和索引对象标记为已损坏之前，从两个位置读取损坏标志并合并结果。

  • 的InnoDB memcached的插件支持多个 get操作（读取在一个单一的多键-值对分布式缓存 查询）和范围查询。请参见 第15.20.4节“ InnoDB memcached多重获取和范围查询支持”。

  • innodb_deadlock_detect可以使用 新的动态变量 禁用死锁检测。在高并发系统上，当多个线程等待相同的锁时，死锁检测会导致速度变慢。有时，禁用死锁检测并在innodb_lock_wait_timeout 发生死锁时依靠设置进行事务回滚可能会更有效 。

  • 新 INFORMATION_SCHEMA.INNODB_CACHED_INDEXES 表报告InnoDB每个索引在缓冲池中缓存的索引页数 。

  • InnoDB现在在共享临时表空间中创建临时表 ibtmp1。

  • 该InnoDB 表空间加密功能重做日志和撤销日志数据的支持加密。请参阅 重做日志加密和 撤消日志加密。

  • InnoDB支持 NOWAIT和SKIP LOCKED选项SELECT ... FOR SHARE以及SELECT ... FOR UPDATE锁定读取语句。 NOWAIT如果请求的行被另一个事务锁定，则导致该语句立即返回。SKIP LOCKED从结果集中删除锁定的行。请参阅 使用NOWAIT和SKIP LOCKED锁定读取并发。

    SELECT ... FOR SHAREreplaces SELECT ... LOCK IN SHARE MODE，但 LOCK IN SHARE MODE仍可用于向后兼容。这些语句是等效的。然而，FOR UPDATE和 FOR SHARE支持 NOWAIT，SKIP LOCKED和选项。请参见第13.2.10节“ SELECT语句”。 OF tbl_name

    OF tbl_name 将锁定查询应用于命名表。

  • ADD PARTITION，DROP PARTITION，COALESCE PARTITION，REORGANIZE PARTITION，和REBUILD PARTITION ALTER TABLE选项由本地分区就地API的支持，可能与使用 ALGORITHM={COPY|INPLACE}和 LOCK条款。

    DROP PARTITION与一起 ALGORITHM=INPLACE删除分区中存储的数据并删除分区。但是， DROP PARTITION使用 ALGORITHM=COPY或 old_alter_table=ON 重建分区表，并尝试将数据从删除的分区移动到具有兼容PARTITION ... VALUES 定义的另一个分区。无法删除的数据将被删除。

  • InnoDB现在 ，存储引擎使用MySQL数据字典，而不是其自己的特定于存储引擎的数据字典。有关数据字典的信息，请参见 第14章，MySQL数据字典。

  • mysql现在，在MySQL数据目录中InnoDB命名的单个表空间文件中 创建系统表和数据字典表 mysql.ibd。以前，这些表是InnoDB在mysql数据库目录中的单个表空间文件中创建的。

  • MySQL 8.0中引入了以下撤消表空间更改：

    • 默认情况下，撤消日志现在位于初始化MySQL实例时创建的两个撤消表空间中。撤消日志不再在系统表空间中创建。

    • 从MySQL 8.0.14开始，可以在运行时使用CREATE UNDO TABLESPACE语法在选定位置创建其他撤消表空间 。

      CREATE UNDO TABLESPACE tablespace_name ADD DATAFILE 'file_name.ibu';

      使用CREATE UNDO TABLESPACE语法创建的撤消表空间 可以在运行时使用DROP UNDO TABLESPACE语法删除 。

      DROP UNDO TABLESPACE tablespace_name;

      ALTER UNDO TABLESPACE 语法可用于将撤消表空间标记为活动或不活动。

      ALTER UNDO TABLESPACE tablespace_name SET {ACTIVE|INACTIVE};

      甲STATE，显示了表空间的状态列被添加到 INFORMATION_SCHEMA.INNODB_TABLESPACES 表中。撤消表空间必须处于 empty状态后才能删除。

    • innodb_undo_log_truncate 默认情况下启用 该 变量。

    • 该 innodb_rollback_segments 变量定义每个撤消表空间的回滚段数。以前， innodb_rollback_segments 指定了MySQL实例的回滚段总数。此更改增加了可用于并发事务的回滚段的数量。更多的回滚段会增加并发事务将单独的回滚段用于撤消日志的可能性，从而减少资源争用。

  • 修改了影响缓冲池预刷新和刷新行为的变量的默认值：

    • 现在 innodb_max_dirty_pages_pct_lwm 默认值为10。先前的默认值0禁用缓冲池预刷新。当缓冲池中的脏页百分比超过10％时，值为10启用预刷新。启用预冲洗可提高性能一致性。

    • 将 innodb_max_dirty_pages_pct 默认值从75到90。增加 InnoDB尝试刷新的数据从缓冲池，使脏页的百分比不超过这个值。增加的默认值允许缓冲池中脏页的百分比更高。

  • 现在默认 innodb_autoinc_lock_mode 设置为2（交错）。交错锁定模式允许并行执行多行插入，从而提高了并发性和可伸缩性。新的 innodb_autoinc_lock_mode 默认设置反映了从基于语句的复制到基于行的复制的更改，这是MySQL 5.7中的默认复制类型。基于语句的复制需要连续的自动增量锁定模式（以前​​的默认设置），以确保为给定的SQL语句序列以可预测和可重复的顺序分配自动增量值，而基于行的复制对SQL语句不敏感。 SQL语句的执行顺序。有关更多信息，请参见 InnoDB AUTO_INCREMENT锁定模式。

    对于使用基于语句的复制的系统，新的 innodb_autoinc_lock_mode 默认设置可能会破坏依赖于顺序自动增量值的应用程序。要恢复以前的默认设置，请设置 innodb_autoinc_lock_mode 为1。

  • ALTER TABLESPACE ... RENAME TO语法 支持重命名常规表空间 。

  • innodb_dedicated_server 默认情况下禁用 的新 变量可用于InnoDB根据服务器上检测到的内存量自动配置以下选项：

    • innodb_buffer_pool_size

    • innodb_log_file_size

    • innodb_flush_method

    此选项适用于在专用服务器上运行的MySQL服务器实例。有关更多信息，请参见 第15.8.12节“为专用的MySQL服务器启用自动配置”。

  • 新 INFORMATION_SCHEMA.INNODB_TABLESPACES_BRIEF 视图为表空间提供空间，名称，路径，标志和空间类型数据InnoDB。

  • 与MySQL捆绑在一起 的zlib库版本从1.2.3版本提高到1.2.11版本。MySQL在zlib库的帮助下实现了压缩。

    如果使用InnoDB压缩表，请参见第2.11.4节“ MySQL 8.0中的更改”以获取相关的升级含义。

  • InnoDB除全局临时表空间和撤消表空间文件外 ，所有表空间文件中都存在序列化字典信息（SDI）。SDI是表和表空间对象的序列化元数据。SDI数据的存在提供了元数据冗余。例如，如果数据字典变得不可用，则可以从表空间文件中提取字典对象元数据。使用ibd2sdi工具执行SDI提取。SDI数据以JSON格式存储。

    在表空间文件中包含SDI数据会增加表空间文件的大小。SDI记录需要一个索引页，默认情况下大小为16KB。但是，在存储SDI数据时会对其进行压缩，以减少存储空间。

  • InnoDB现在 ，存储引擎支持原子DDL，即使服务器在操作期间停止运行，它也可以确保DDL操作完全提交或回滚。有关更多信息，请参见第13.1.1节“原子数据定义语句支持”。

  • 使用该innodb_directories 选项，可以在服务器脱机时将表空间文件移动或还原到新位置 。有关更多信息，请参见 第15.6.3.6节“在服务器脱机时移动表空间文件”。

  • 实现了以下重做日志记录优化：

    • 用户线程现在可以并发写入日志缓冲区，而无需同步写入。

    • 用户线程现在可以按轻松的顺序将脏页添加到刷新列表中。

    • 现在，专用的日志线程负责将日志缓冲区写入系统缓冲区，将系统缓冲区刷新到磁盘，通知用户线程有关已写入和已刷新的重做，维持宽松的刷新列表顺序所需的滞后时间以及写入检查点。

    • 添加了系统变量，用于配置等待刷新重做的用户线程使用旋转延迟的方法：

      • innodb_log_wait_for_flush_spin_hwm：定义最大平均日志刷新时间，超过该时间后，用户线程将在等待刷新重做时不再旋转。

      • innodb_log_spin_cpu_abs_lwm：定义最小CPU使用量，在该最小使用量之下，用户线程在等待刷新重做时不再旋转。

      • innodb_log_spin_cpu_pct_hwm：定义最大CPU使用量，在该最大CPU使用量之上，用户线程在等待刷新重做时不再旋转。

    • 的 innodb_log_buffer_size 变量是现在动态的，服务器运行时其允许调整大小日志缓冲区的。

    有关更多信息，请参见 第8.5.4节“优化InnoDB重做日志”。

  • 从MySQL 8.0.12开始，对大对象（LOB）数据的小更新支持撤消日志记录，从而提高了大小为100字节或更小的LOB更新的性能。以前，LOB更新的大小至少为一个LOB页，对于可能只修改几个字节的更新而言，这不是最佳的。此增强功能基于MySQL 8.0.4中添加的对LOB数据的部分更新的支持。

  • 从MySQL 8.0.12开始，ALGORITHM=INSTANT 以下ALTER TABLE操作受支持 ：

    • 添加一列。此功能也称为 “ 即时ADD COLUMN ”。有限制条件。请参见 第15.12.1节“在线DDL操作”。

    • 添加或删除虚拟列。

    • 添加或删除列默认值。

    • 修改ENUM或 SET列的定义 。

    • 更改索引类型。

    • 重命名表。

    ALGORITHM=INSTANT仅 支持的操作会 修改数据字典中的元数据。在表上没有采取任何元数据锁，并且表数据不受影响，从而使操作立即进行。如果未明确指定，ALGORITHM=INSTANT则默认情况下由支持它的操作使用。如果 ALGORITHM=INSTANT指定但不支持，则操作立即失败并显示错误。

    有关支持的操作的更多信息 ALGORITHM=INSTANT，请参见 第15.12.1节“在线DDL操作”。

  • 从MySQL 8.0.13开始，TempTable 存储引擎支持二进制大对象（BLOB）类型列的存储。此增强功能提高了使用包含BLOB数据的临时表的查询的性能。以前，包含BLOB数据的临时表存储在定义的磁盘存储引擎中 internal_tmp_disk_storage_engine。有关更多信息，请参见 第8.4.4节“ MySQL中的内部临时表使用”。

  • 从MySQL 8.0.13开始，静态InnoDB 数据加密功能支持常规表空间。以前，只能加密每表文件表空间。一般的表空间支持加密，CREATE TABLESPACE和ALTER TABLESPACE语法扩展到包括 ENCRYPTION条款。

    该 INFORMATION_SCHEMA.INNODB_TABLESPACES 表现在包括一ENCRYPTION 列，该列指示表空间是否已加密。

    在stage/innodb/alter tablespace (encryption)加入绩效模式阶段仪器允许监测一般表的加密操作。

  • 禁用该 innodb_buffer_pool_in_core_file 变量可通过排除InnoDB缓冲池页面来减少核心文件的大小 。要使用此变量，core_file 必须启用该变量，并且操作系统必须支持Linux以及更高版本中支持的的MADV_DONTDUMP非POSIX扩展madvise()。有关更多信息，请参见第15.8.3.7节“从核心文件中排除缓冲池页面”。

  • 从MySQL 8.0.13开始，由用户创建的临时表和由优化器创建的内部临时表存储在会话临时表空间中，该会话临时表空间是从临时表空间池中分配给会话的。当会话断开连接时，其临时表空间将被截断并释放回池中。在以前的版本中，临时表是在全局临时表空间（ibtmp1）中创建的，在删除临时表后，该表不会将磁盘空间返回给操作系统。

    该 innodb_temp_tablespaces_dir 变量定义创建会话临时表空间的位置。默认位置是 #innodb_temp数据目录中的目录。

    该 INNODB_SESSION_TEMP_TABLESPACES 表提供有关会话临时表空间的元数据。

    现在，全局临时表空间（ibtmp1）存储了对用户创建的临时表所做的更改的回滚段。

  • 从MySQL 8.0.14开始，InnoDB支持并行集群索引读取，这可以提高 CHECK TABLE性能。此功能不适用于二级索引扫描。的 innodb_parallel_read_threads 并行聚簇索引读取发生会话变量必须被设置为一个大于1的值。默认值为4。用于执行并行聚集索引读取的实际线程数取决于 innodb_parallel_read_threads 设置或要扫描的索引子树的数量，以较小者为准。

  • 从8.0.14开始，innodb_dedicated_server 启用该 变量后，将根据自动配置的缓冲池大小来配置日志文件的大小和数量。以前，日志文件的大小是根据在服务器上检测到的内存量来配置的，而日志文件的数量不是自动配置的。

  • 从8.0.14开始，该 语句的ADD DATAFILE子句CREATE TABLESPACE是可选的，它允许没有FILE特权的用户 创建表空间。一个CREATE TABLESPACE没有执行的语句 ADD DATAFILE子句隐式地创建一个独特的文件名的表空间的数据文件。

  • 默认情况下，当TempTable存储引擎占用的内存量超过该temptable_max_ram 变量定义的内存限制时 ，TempTable存储引擎将开始从磁盘分配内存映射的临时文件。从MySQL 8.0.16开始，此行为由temptable_use_mmap 变量控制 。禁用 temptable_use_mmap 会使TempTable存储引擎将 InnoDB磁盘内部临时表而不是内存映射文件用作其溢出机制。有关更多信息，请参阅 内部临时表存储引擎。

  • 从MySQL 8.0.16开始，静态InnoDB 数据加密功能支持对mysql系统表空间的加密。该 mysql系统表空间包含 mysql系统数据库和MySQL数据字典表。有关更多信息，请参见 第15.13节“ InnoDB静态数据加密”。

  • innodb_spin_wait_pause_multiplier MySQL 8.0.16中引入 的 变量提供了对自旋锁轮询延迟持续时间的更好控制，自旋锁轮询延迟在线程等待获取互斥量或rw锁时发生。可以对延迟进行更精细的调整，以解决不同处理器体系结构上PAUSE指令持续时间的差异。有关更多信息，请参见 第15.8.8节“配置自旋锁定轮询”。

  • InnoDB 在MySQL 8.0.17中，通过更好地利用读取线程，减少了并行扫描期间发生的预取活动的读取线程I / O，提高了大型数据集的并行读取线程性能，并支持了分区的并行扫描。

    并行读取线程功能由innodb_parallel_read_threads 变量控制 。现在，最大设置为256，这是所有客户端连接的线程总数。如果达到线程限制，连接将退回到使用单个线程。

  • innodb_idle_flush_pct MySQL 8.0.18中引入 的 变量允许在空闲期间限制页面刷新，这可以帮助延长固态存储设备的寿命。请参见 在空闲期间限制缓冲区刷新。

  • InnoDB从MySQL 8.0.19开始，为了生成直方图统计数据，已经 对数据进行了有效采样。请参见 直方图统计分析。

  • 从MySQL 8.0.20开始，doublewrite缓冲区存储区位于doublewrite文件中。在以前的版本中，存储区位于系统表空间中。将存储区域移出系统表空间可减少写延迟，增加吞吐量并提供关于双写缓冲区页放置的灵活性。为高级双写缓冲区配置引入了以下系统变量：

    • innodb_doublewrite_dir

      定义双写缓冲区文件目录。

    • innodb_doublewrite_files

      定义双写文件的数量。

    • innodb_doublewrite_pages

      定义批量写入时每个线程的最大双写页数。

    • innodb_doublewrite_batch_size

      定义要批量写入的双写页面数。

       

      有关更多信息，请参见 第15.6.4节“ Doublewrite缓冲区”。

       

      MySQL 8.0.20中改进了竞争感知事务调度（CATS）算法，该算法优先考虑等待锁的事务。现在，事务调度权重计算完全在单独的线程中执行，从而提高了计算性能和准确性。

       

      删除了也用于事务调度的先进先出（FIFO）算法。CATS算法的增强使FIFO算法变得多余。以前由FIFO算法执行的事务调度现在由CATS算法执行。

       

      TRX_SCHEDULE_WEIGHT在INFORMATION_SCHEMA.INNODB_TRX表中添加了 一个列 ，该列允许查询由CATS算法分配的事务调度权重。

       

      INNODB_METRICS添加了 以下计数器来监视代码级事务调度事件：

       

      lock_rec_release_attempts

       

      尝试释放记录锁定的次数。

       

      lock_rec_grant_attempts

       

      授予记录锁定的尝试次数。

       

      lock_schedule_refreshes

       

      分析等待图表以更新交易计划权重的次数。

       

      有关更多信息，请参见 第15.7.6节“事务调度”。

       

      从MySQL 8.0.21开始，为了提高需要访问表和行资源的锁队列的操作的并发性，锁系统互斥锁（lock_sys->mutex）被分片闩锁代替，并且锁队列被分组为表和页锁队列分片，每个分片均受专用互斥保护。以前，单锁系统互斥锁可保护所有锁队列，这是高并发系统上的争论点。新的分片实现允许更精细地访问锁定队列。

       

      锁系统互斥锁（lock_sys->mutex）被以下分片闩锁代替：

       

      全局闩锁（lock_sys->latches.global_latch），由64个读写锁定对象（rw_lock_t）组成。访问单个锁定队列需要共享的全局闩锁和锁定队列分片上的闩锁。需要访问所有锁定队列的操作采用排他的全局闩锁，该闩锁会闩锁所有表和页面锁定队列分片。

       

      表分片锁存器（lock_sys->latches.table_shards.mutexes），由512个互斥锁组成，每个互斥锁专用于512个表锁定队列分片之一。

       

      页面分片锁存器（lock_sys->latches.page_shards.mutexes），由512个互斥锁组成，每个互斥锁专用于512个页面锁定队列分片之一。

       

      wait/synch/mutex/innodb/lock_mutex 用于监视单锁系统互斥锁 的Performance Schema 工具已由用于监视新的全局，表分片和页面分片闩锁的工具取代：

       

      wait/synch/sxlock/innodb/lock_sys_global_rw_lock

       

      wait/synch/mutex/innodb/lock_sys_table_mutex

       

      wait/synch/mutex/innodb/lock_sys_page_mutex

       

      从MySQL 8.0.21开始，使用DATA DIRECTORY子句在数据目录外部创建的表和表分区数据文件 仅限于已知的目录InnoDB。此更改允许数据库管理员控制在何处创建表空间数据文件，并确保可以在恢复期间找到这些数据文件。

       

      常规和每表文件表空间数据文件（.ibd文件）不能再在undo表空间目录（innodb_undo_directory）中创建，除非直接已知InnoDB。

       

      已知的目录那些被定义的 datadir， innodb_data_home_dir和 innodb_directories 变量。

       

      截断InnoDB驻留在每个表文件表空间中的表将删除现有表空间并创建一个新表空间。从MySQL 8.0.21开始， InnoDB如果当前表空间目录未知，则在默认位置创建新表空间，并向错误日志写入警告。要 TRUNCATE TABLE在当前位置创建表空间，请innodb_directories在运行之前将目录添加到 设置中TRUNCATE TABLE。

       

      从MySQL 8.0.21开始，可以使用ALTER INSTANCE {ENABLE|DISABLE} INNODB REDO_LOG语法启用和禁用重做日志记录。此功能旨在将数据加载到新的MySQL实例中。禁用重做日志记录可以避免重做日志写入，从而有助于加快数据加载速度。

       

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

       

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

       

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

       

      在启动时，InnoDB如果表空间文件已移动到其他位置，则对照数据字典中存储的表空间文件路径来验证已知表空间文件的路径。innodb_validate_tablespace_paths MySQL 8.0.21中引入的新 变量允许禁用表空间路径验证。此功能适用于不移动表空间文件的环境。禁用表空间路径验证可缩短具有大量表空间文件的系统上的启动时间。

       

      有关更多信息，请参见 第15.6.3.7节“禁用表空间路径验证”。

       

      从MySQL 8.0.21开始，在支持原子DDL的存储引擎上，CREATE TABLE ... SELECT当使用基于行的复制时，该 语句作为一个事务记录在二进制日志中。以前，它被记录为两个事务，一个用于创建表，另一个用于插入数据。通过此更改， CREATE TABLE ... SELECT语句现在可以安全地用于基于行的复制，并且可以与基于GTID的复制一起使用。有关更多信息，请参见 第13.1.1节“原子数据定义语句支持”。

       

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

       

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

       

      为了防止因撤消表空间的截断操作数量过多而导致潜在的问题，现在将检查点之间同一撤消表空间的截断操作限制为64。如果超过了限制，则仍可以使撤消表空间为非活动状态，但不会被截断直到下一个检查点之后。

       

      INNODB_METRICS与无效撤消的截断刷新操作相关的计数器已删除。删除了计数器包括： undo_truncate_sweep_count， undo_truncate_sweep_usec， undo_truncate_flush_count，和 undo_truncate_flush_usec。

       

      请参见第15.6.3.4节“撤消表空间”。

       

      从MySQL 8.0.22开始，新 innodb_extend_and_initialize变量允许InnoDB在Linux上配置如何为每个表文件空间和常规表空间分配空间。默认情况下，当操作需要表空间中的额外空间时，InnoDB将页面分配给表空间，并以物理方式将NULL写入这些页面。如果频繁分配新页面，此行为会影响性能。您可以innodb_extend_and_initialize在Linux系统上禁用 以避免物理上将NULL写入新分配的表空间页面。当 innodb_extend_and_initialize被禁用，空间使用分配 posix_fallocate() 调用，保留空间而无需实际写入NULL。

       

      甲posix_fallocate()操作不是原子，这使得它可能用于向表文件分配空间和更新文件元数据之间发生了故障。此类故障可能会使新分配的页面处于未初始化状态，从而导致InnoDB尝试访问这些页面时失败 。为避免这种情况，请InnoDB在分配新的表空间页之前写入重做日志记录。如果页面分配操作被中断，则在恢复期间将从重做日志记录中重播该操作。

       

      字符集支持。  默认字符集已从更改 latin1为utf8mb4。该utf8mb4字符集有几个新的排序规则，其中包括 utf8mb4_ja_0900_as_cs，提供对Unicode在MySQL中第一个日本语言特定的排序。有关更多信息，请参见 第10.10.1节“ Unicode字符集”。

       

      JSON增强。  对MySQL的JSON功能进行了以下增强或添加：

       

      添加了 ->> （内联路径）运算符，等效于调用 JSON_UNQUOTE()的结果JSON_EXTRACT()。

       

      这是-> 对MySQL 5.7中引入的列路径运算符的改进 ； col->>"$.path"等价于 JSON_UNQUOTE(col->"$.path")。内联路径运算符可以用来随时随地可以使用 JSON_UNQUOTE(JSON_EXTRACT())，如 SELECT列清单， WHERE和HAVING 条款，并ORDER BY和 GROUP BY条款。有关更多信息，请参见运算符的描述以及JSON Path Syntax。

       

      添加了两个JSON聚合函数 JSON_ARRAYAGG()和 JSON_OBJECTAGG()。 JSON_ARRAYAGG()将列或表达式作为其参数，并将结果聚合为单个JSON数组。该表达式可以求值为任何MySQL数据类型；这不一定是一个JSON值。 JSON_OBJECTAGG()接受两列或表达式，将其解释为键和值；它以单个JSON 对象的形式返回结果。有关更多信息和示例，请参见 第12.20节“聚合函数”。

       

      添加了JSON实用程序功能JSON_PRETTY()，该功能 JSON 以易于阅读的格式输出现有值；每个JSON对象成员或数组值都打印在单独的一行上，并且子对象或数组相对于其父对象要有2个空格。

       

      此函数还可以与可解析为JSON值的字符串一起使用。

       

      有关更多详细信息和示例，请参见 第12.18.8节“ JSON实用程序函数”。

       

      现在，JSON使用来对查询中的值进行 排序时ORDER BY，每个值现在都由sort键的可变长度部分表示，而不是由固定的1K大小的一部分表示。在许多情况下，这可以减少过多的使用。例如，标量INT或什至 BIGINT值实际上需要很少的字节，因此该空间的其余部分（最多90％或更多）被填充占用了。此更改具有以下性能优势：

       

      现在可以更有效地使用排序缓冲区空间，因此文件排序不需要像固定长度排序键那样早或经常刷新到磁盘。这意味着可以在内存中整理更多数据，避免不必要的磁盘访问。

       

      较短的键可以比较长的键更快地进行比较，从而显着提高了性能。对于完全在内存中执行的排序以及需要写入磁盘和从磁盘读取的排序，都是如此。

       

      在MySQL 8.0.2中添加了对JSON列值的部分就地更新的支持，这比完全删除现有JSON值并在其位置写入一个新的JSON效率更高，就像以前在更新任何JSON列时所做的那样 。要应用这种优化，更新，必须使用应用 JSON_SET()， JSON_REPLACE()或 JSON_REMOVE()。无法将新元素添加到要更新的JSON文档中；文档中的值不能占用比更新前更多的空间。请参阅 JSON值的部分更新，以详细讨论要求。

       

      可以将JSON文档的部分更新写入二进制日志，比记录完整的JSON文档占用更少的空间。使用基于语句的复制时，始终会记录部分更新。为了使其与基于行的复制一起使用，必须首先设置 binlog_row_value_options=PARTIAL_JSON; 有关更多信息，请参见此变量的说明。

       

      添加了JSON实用程序功能 JSON_STORAGE_SIZE()和 JSON_STORAGE_FREE()。 JSON_STORAGE_SIZE()在进行任何部分更新之前，返回用于JSON文档的二进制表示形式的存储空间（以字节为单位）（请参阅上一项）。 JSON_STORAGE_FREE()显示JSON使用JSON_SET()或 部分更新的类型的表列中剩余的空间量 JSON_REPLACE()。如果新值的二进制表示形式小于先前值的二进制表示形式，则该值大于零。

       

      这些函数中的每一个还接受JSON文档的有效字符串表示形式。对于此值， JSON_STORAGE_SIZE()返回其二进制表示形式在转换为JSON文档后使用的空间。对于包含JSON文档的字符串表示形式的变量， JSON_STORAGE_FREE()返回零。如果无法将其（非null）参数解析为有效的JSON文档，并且NULL参数为，则 任何一个函数都会产生错误 NULL。

       

      有关更多信息和示例，请参见 第12.18.8节“ JSON实用程序函数”。

       

      JSON_STORAGE_SIZE()并 JSON_STORAGE_FREE()在MySQL 8.0.2中实现。

       

      在MySQL 8.0.2中添加了对范围（例如 $[1 to 5]XPath表达式）的支持。在此版本中还增加了对 last关键字和相对寻址的支持，因此$[last]始终选择数组中的最后一个（最高编号）元素以及 $[last-1]最后一个相邻元素。 last使用它的表达式也可以包含在范围定义中。例如， $[last-2 to last-1]返回最后两个元素，但返回数组中的一个。有关其他信息和示例，请参见 搜索和修改JSON值。

       

      添加了旨在符合RFC 7396的JSON合并功能 。 JSON_MERGE_PATCH()，当用于2个JSON对象时，将它们合并为一个具有以下集合的并集的单个JSON对象：

       

      第一个对象的每个成员，在第二个对象中不存在具有相同键的成员。

       

      第二个对象的每个成员，在第一个对象中没有成员具有相同的键，并且其值不是JSON null文字。

       

      每个成员都具有在两个对象中都存在的键，并且其在第二个对象中的值不是JSON null文字。

       

      作为这项工作的一部分，该 JSON_MERGE()功能已重命名 JSON_MERGE_PRESERVE()。 JSON_MERGE()仍然被认为是JSON_MERGE_PRESERVE()MySQL 8.0 的别名 ，但现在已弃用，并且在将来的MySQL版本中会被删除。

       

      有关更多信息和示例，请参见 第12.18.4节“修改JSON值的函数”。

       

      实现了重复密钥的 “ 最后重复密钥获胜 ” 规范化，与 RFC 7159和大多数JavaScript解析器一致。此行为的示例在此处显示，其中仅x保留具有密钥的最右边的成员：

       

      mysql> SELECT JSON_OBJECT('x', '32', 'y', '[true, false]',

           >                     'x', '"abc"', 'x', '100') AS Result;

      +------------------------------------+

      | Result                             |

      +------------------------------------+

      | {"x": "100", "y": "[true, false]"} |

      +------------------------------------+

      1 row in set (0.00 sec)

      插入MySQL JSON列中的值 也以这种方式标准化，如以下示例所示：

       

      mysql> CREATE TABLE t1 (c1 JSON);

       

      mysql> INSERT INTO t1 VALUES ('{"x": 17, "x": "red", "x": [3, 5, 7]}');

       

      mysql> SELECT c1 FROM t1;

      +------------------+

      | c1               |

      +------------------+

      | {"x": [3, 5, 7]} |

      +------------------+

      与以前的MySQL版本相比，这是一个不兼容的更改，以前的版本 在这种情况下使用了“ 首次重复键赢 ”算法。

       

      有关更多信息和示例，请参见JSON值的规范化，合并和自动包装。

       

      JSON_TABLE() 在MySQL 8.0.4中 添加了该功能。此函数接受JSON数据，并将其作为具有指定列的关系表返回。

       

      此函数的语法为 ，其中 是返回JSON数据的表达式，是应用于源的JSON路径以及 列定义的列表。这里显示一个示例： JSON_TABLE(expr, path COLUMNS column_list) [AS] alias)exprpathcolumn_list

       

      mysql> SELECT *

          -> FROM

          ->   JSON_TABLE(

          ->     '[{"a":3,"b":"0"},{"a":"3","b":"1"},{"a":2,"b":1},{"a":0},{"b":[1,2]}]',

          ->     "$[*]" COLUMNS(

          ->       rowid FOR ORDINALITY,

          ->

          ->       xa INT EXISTS PATH "$.a",

          ->       xb INT EXISTS PATH "$.b",

          ->

          ->       sa VARCHAR(100) PATH "$.a",

          ->       sb VARCHAR(100) PATH "$.b",

          ->

          ->       ja JSON PATH "$.a",

          ->       jb JSON PATH "$.b"

          ->     )

          ->   ) AS  jt1;

      +-------+------+------+------+------+------+--------+

      | rowid | xa   | xb   | sa   | sb   | ja   | jb     |

      +-------+------+------+------+------+------+--------+

      |     1 |    1 |    1 | 3    | 0    | 3    | "0"    |

      |     2 |    1 |    1 | 3    | 1    | "3"  | "1"    |

      |     3 |    1 |    1 | 2    | 1    | 2    | 1      |

      |     4 |    1 |    0 | 0    | NULL | 0    | NULL   |

      |     5 |    0 |    1 | NULL | NULL | NULL | [1, 2] |

      +-------+------+------+------+------+------+--------+

      JSON源表达式可以是产生有效JSON文档的任何表达式，包括JSON文字，表列或返回JSON的函数调用，例如JSON_EXTRACT(t1, data, '$.post.comments')。有关更多信息，请参见 第12.18.6节“ JSON表函数”。

       

      数据类型支持。  MySQL现在支持使用表达式作为数据类型规范中的默认值。这包括使用表达式作为默认值 BLOB， TEXT， GEOMETRY，和 JSON数据类型，这在以前是根本不会被分配缺省值。有关详细信息，请参见第11.6节“数据类型默认值”。

       

      优化器。  添加了这些优化器增强功能：

       

      MySQL现在支持不可见索引。优化器根本不使用不可见索引，但否则将正常维护它。默认情况下，索引可见。不可见的索引可以测试删除索引对查询性能的影响，而无需进行破坏性的更改，如果需要该索引，则必须撤消该更改。请参见 第8.3.12节“不可见索引”。

       

      MySQL现在支持降序索引： DESC索引定义不再被忽略，而是导致键值以降序存储。以前，可以以相反的顺序扫描索引，但是会降低性能。降序索引可以按向前顺序进行扫描，这样效率更高。当最有效的扫描顺序将某些列的升序与其他列的降序混合时，降序索引还使优化程序可以使用多列索引。请参见第8.3.13节“降序索引”。

       

      MySQL现在支持创建索引表达式值而不是列值的功能索引键部分。功能性关键部分支持对无法通过其他方式索引的值（例如JSON值）进行索引 。有关详细信息，请参见第13.1.15节“ CREATE INDEX语句”。

       

      在MySQL 8.0.14和更高版本中，WHERE常量常量表达式引起的琐碎 条件在准备过程中被删除，而不是在优化过程中被删除。在过程的早期删除条件可以简化具有琐碎条件的外部联接的查询的联接，例如：

       

      SELECT * FROM t1 LEFT JOIN t2 ON condition_1 WHERE condition_2 OR 0 = 1

      现在，优化器在准备过程中会看到0 = 1始终为false，从而使其具有OR 0 = 1 冗余，然后将其删除，从而保持以下状态：

       

      SELECT * FROM t1 LEFT JOIN t2 ON condition_1 where condition_2

      现在，优化器可以将查询重写为内部联接，如下所示：

       

      SELECT * FROM t1 LEFT JOIN t2 WHERE condition_1 AND condition_2

      有关更多信息，请参见 第8.2.1.9节“外部联接优化”。

       

      在MySQL 8.0.16和更高版本中，MySQL可以在优化时使用常量折叠来处理列与常量值之间的比较，其中常量超出范围或相对于列的类型在范围边界上，而不是执行因此对于执行时的每一行。例如，给定一个t带有TINYINT UNSIGNED列的表 c，优化器可以重写条件，例如WHERE c < 256to WHERE 1（并完全优化该条件）或 WHERE c >= 255to WHERE c = 255。

       

      有关更多信息，请参见第8.2.1.14节“恒定折叠优化”。

       

      从MySQL 8.0.16开始，与IN子查询一起使用的半联接优化现在也可以应用于EXISTS子查询。另外，优化器现在WHERE在子查询所附加的条件下对琐碎相关的相等谓词进行解相关 ，以便可以将它们与子查询中的表达式进行类似的处理IN。这适用于EXISTS和 IN子查询。

       

      有关更多信息，请参见第8.2.2.1节“使用半联接转换优化IN和EXISTS子查询谓词”。

       

      从MySQL 8.0.17开始，服务器会在上下文化 阶段内部在内部重写所有不完整的SQL谓词（即，谓词的形式为 ，其中 是列名或常量表达式，并且不使用比较运算符），以便查询解析程序，查询优化程序和查询执行程序仅需要使用完整的谓词。 WHERE valuevalueWHERE value <> 0

       

      此更改的明显效果是，对于布尔值，EXPLAIN现在输出显示trueand false，而不是 1and 0。

       

      此更改的另一个效果是，对SQL布尔上下文中的JSON值求值会对JSON整数0进行隐式比较。考虑如下所示创建和填充的表：

       

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

       

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

      以前，服务器 在SQL布尔上下文中进行比较时，尝试将提取的true或false值转换为 SQL布尔，如以下查询所示 IS TRUE：

       

      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和更高版本中，提取的值与JSON整数0的隐式copmparison导致不同的结果：

       

      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        |

      +------+----------------+--------------+

      从MySQL 8.0.21开始，您可以 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         |

      +------+---------------+--------------+

      同样从MySQL 8.0.21开始，服务器提供警告。在SQL布尔上下文中评估JSON值会对JSON整数0进行隐式比较。如果这不是您想要的，则以这种方式在SQL布尔上下文中比较提取的值时，请考虑使用JSON_VALUE RETURNING将JSON转换为SQL数字类型。

       

      在MySQL 8.0.17及更高版本中，WHERE 具有或 的条件在内部转换为反连接。（一个反联接返回表中没有与联接条件相匹配的行的表中的所有行，并且符合联接条件。）这将删除子查询，因为该子查询的表现在在顶部处理，因此可以更快地执行查询。水平。 NOT IN (subquery)NOT EXISTS (subquery)

       

      这类似于并重用现有的IS NULL（Not exists）外连接优化。请参阅 EXPLAIN Extra Information。

       

      从MySQL 8.0.21开始，单表 UPDATE或 DELETE语句现在可以在许多情况下利用半联接转换或子查询实现。这适用于此处所示形式的语句：

       

      UPDATE t1 SET t1.a=value WHERE t1.a IN (SELECT t2.a FROM t2)

       

      DELETE FROM t1 WHERE t1.a IN (SELECT t2.a FROM t2)

       

      可以针对单个表 UPDATE或DELETE 满足以下条件进行此操作：

       

      该UPDATE或 DELETE语句使用具有一个子查询[NOT] IN或 [NOT] EXISTS谓语。

       

      该语句没有ORDER BY 子句，也没有LIMIT子句。

       

      （的多表版本 UPDATE和 DELETE不支持 ORDER BY或 LIMIT）。

       

      目标表不支持写前读删除（仅与NDB表相关 ）。

       

      基于子查询中包含的任何提示以及的值，允许半联接或子查询实现 optimizer_switch。

       

      当将半联接优化用于合格的单表DELETE或时 UPDATE，这在优化程序跟踪中可见：对于多表语句join_optimization，跟踪中有一个 对象，而对于单表语句则没有。转换在EXPLAIN FORMAT=TREE或 的输出中也可见 EXPLAIN ANALYZE。单表语句显示<not executable by iterator executor>，而多表语句报告完整计划。

       

      Alo从MySQL 8.0.21开始，UPDATE 使用InnoDB 表的多表语句支持半一致性读取，因为事务隔离级别比弱 REPEATABLE READ。

       

      常用表表达式。  MySQL现在支持非递归和递归的通用表表达式。公用表表达式允许使用命名的临时结果集，通过允许在WITH语句之前的子句SELECT和某些其他语句来实现。有关更多信息，请参见 第13.2.15节“ WITH（公用表表达式）”。

       

      从MySQL 8.0.19开始，SELECT递归公用表表达式（CTE）的递归 部分支持 LIMIT子句。LIMIT 与OFFSET也支持。有关更多信息，请参见 递归公用表表达式。

       

      窗口功能。  MySQL现在支持窗口函数，对于查询中的每一行，都使用与该行相关的行来执行计算。这些包括诸如 RANK()， LAG()，和 NTILE()。此外，现在可以将几个现有的聚合函数用作窗口函数（例如 SUM()和 AVG()）。有关更多信息，请参见第12.21节“窗口函数”。

       

      横向派生表。  现在，派生表之前可以带有 LATERAL关键字，以指定允许它引用（取决于）同一FROM子句中先前表的列。横向派生表使某些SQL操作可能无法通过非横向派生表完成，或者需要效率较低的解决方法。请参见 第13.2.11.9节“侧面衍生表”。

       

      单表DELETE语句中的别名。  在MySQL 8.0.16和更高版本中，单表 DELETE语句支持使用表别名。

       

      正则表达式支持。  此前，MySQL的使用的亨利斯宾塞正则表达式库来支持正则表达式运算符（REGEXP， RLIKE）。使用Unicode国际组件（ICU）重新实现了对正则表达式的支持，该组件提供了完整的Unicode支持并且是多字节安全的。该 REGEXP_LIKE()函数以REGEXP和 RLIKE 运算符的方式执行正则表达式匹配 ，它们现在是该函数的同义词。此外， REGEXP_INSTR()， REGEXP_REPLACE()，和 REGEXP_SUBSTR()函数可用于查找匹配位置并分别执行子字符串替换和提取。该 regexp_stack_limit和 regexp_time_limit系统变量提供由发动机匹配了资源消耗的控制。有关更多信息，请参见 第12.8.2节“正则表达式”。有关实现更改可能影响使用正则表达式的应用程序的方式的信息，请参见 正则表达式兼容性注意事项。

       

      内部临时表。  的TempTable存储引擎替换MEMORY存储引擎作为默认发动机用于在内存中的内部临时表。该TempTable存储引擎提供了有效的存储 VARCHAR和 VARBINARY列。的 internal_tmp_mem_storage_engine 会话变量定义了用于在存储器内的临时表的存储引擎。允许的值为 TempTable（默认值）和 MEMORY。该 temptable_max_ram 变量定义TempTable在将数据存储到磁盘之前存储引擎可以使用的最大内存量 。

       

      正在记录。  错误记录已重写为使用MySQL组件体系结构。传统的错误日志记录是使用内置组件实现的，而使用系统日志的日志记录则是可加载的组件。此外，还提供了可加载的JSON日志编写器。要控制要启用的日志组件，请使用 log_error_services系统变量。有关更多信息，请参见 第5.4.2节“错误日志”。

       

      备用锁。  一种新型的备份锁可以在联机备份期间允许DML，同时防止可能导致快照不一致的操作。LOCK INSTANCE FOR BACKUP 和 UNLOCK INSTANCE语法支持新的备份锁 。该 BACKUP_ADMIN权限才能使用这些语句。

       

      复制。  对MySQL复制进行了以下增强：

       

      MySQL复制现在支持使用紧凑的二进制格式对JSON文档的部分更新进行二进制日志记录，从而在记录完整的JSON文档时节省了日志空间。当使用基于语句的日志记录时，这种紧凑的日志记录会自动完成，并且可以通过将新的binlog_row_value_options系统变量设置为来启用 PARTIAL_JSON。有关更多信息，请参见JSON值的部分更新以及的描述 binlog_row_value_options。

       

      连接管理。  MySQL服务器现在允许专门为管理连接配置TCP / IP端口。这提供了用于普通连接的网络接口上允许的单个管理连接的替代方法，即使 max_connections 已经建立连接也是如此。请参见 第5.1.12.1节“连接接口”。

       

      MySQL现在提供了对压缩使用的更多控制，以最大程度地减少通过与服务器的连接发送的字节数。以前，给定的连接未压缩或已使用zlib压缩算法。现在，也可以使用该 zstd算法，并选择zstd连接的压缩级别。可以在服务器端以及连接原始端配置允许的压缩算法，以通过客户端程序以及参与源/副本复制或组复制的服务器进行连接。有关更多信息，请参见 第4.2.8节“连接压缩控制”。

       

      组态。  在整个MySQL中，主机名的最大允许长度已增加到255个ASCII字符，之前的限制是60个字符。例如，这适用于数据字典中与主机名相关的列， mysql系统架构，性能架构INFORMATION_SCHEMA和 sys；陈述的 MASTER_HOST价值 CHANGE MASTER TO；语句输出中的Host列 SHOW PROCESSLIST；帐户名称中的主机名（例如帐户管理对帐单和 DEFINER属性）；以及与主机名相关的命令选项和系统变量。

       

      注意事项：

       

      允许的主机名长度增加会影响在主机名列上具有索引的表。例如，mysql系统架构中索引主机名的表现在具有显式 ROW_FORMAT属性， DYNAMIC以容纳更长的索引值。

       

      某些基于文件名的配置设置可能是基于服务器主机名构造的。允许的值受基础操作系统的约束，该操作系统可能不允许文件名足够长以包含255个字符的主机名。这会影响到 general_log_file， log_error， pid_file， relay_log，和 slow_query_log_file 系统变量和相应的选项。如果基于主机名的值对于OS而言太长，则必须提供明确的较短值。

       

      尽管服务器现在支持255个字符的主机名，但使用该--ssl-mode=VERIFY_IDENTITY 选项建立的服务器的连接 受到OpenSSL支持的最大主机名长度的限制。主机名匹配与SSL证书的两个字段有关，其最大长度如下：公用名：最大长度为64；最大名称为64。主题备用名称：根据RFC＃1034的最大长度。

       

      插件。  以前，MySQL插件可以用C或C ++编写。插件使用的MySQL头文件现在包含C ++代码，这意味着插件必须使用C ++而不是C编写。

       

      C API。  MySQL C API现在支持异步功能，用于与MySQL服务器的非阻塞通信。每个功能都是现有同步功能的异步对应项。如果从服务器连接读取或写入服务器连接，则必须等待同步功能。异步功能使应用程序可以检查服务器连接上的工作是否准备就绪。如果不是，应用程序可以执行其他工作，然后再进行检查。请参阅 C API异步接口。

       

      演员的其他目标类型。  功能CAST()和 CONVERT()现在支持转换到类型 DOUBLE， FLOAT和 REAL。在MySQL 8.0.17中添加。请参见第12.11节“广播函数和运算符”。

       

      JSON模式验证。  MySQL 8.0.17添加了两个功能 JSON_SCHEMA_VALID()， JSON_SCHEMA_VALIDATION_REPORT() 用于再次验证JSON文档JSON模式。 JSON_SCHEMA_VALID()如果文档根据模式进行验证，则返回TRUE（1），否则通过FALSE（0）返回。 JSON_SCHEMA_VALIDATION_REPORT()返回一个JSON文档，其中包含有关验证结果的详细信息。以下语句适用于这两个功能：

       

      模式必须符合JSON模式规范的草案4。

       

      required 支持属性。

       

      $ref 不支持 外部资源和关键字。

       

      支持正则表达式模式；无效模式将被静默忽略。

       

      有关更多信息和示例，请参见第12.18.7节“ JSON模式验证函数”。

       

      多值索引。  从MySQL 8.0.17开始， InnoDB支持创建多值索引，该索引是在JSON存储值数组的列上定义的辅助索引，并且单个数据记录可以具有多个索引记录。这样的索引使用诸如的关键部分定义 CAST(data->'$.zipcode' AS UNSIGNED ARRAY)。MySQL优化程序会自动使用多值索引进行合适的查询，如的输出所示 EXPLAIN。

       

      作为这项工作的一部分，MySQL添加了一个新功能 JSON_OVERLAPS()和一个MEMBER OF()用于处理JSON文档的新 运算符，此外，还CAST()使用一个新ARRAY关键字扩展了该 功能， 如下表所示：

       

      JSON_OVERLAPS()比较两个 JSON文档。如果它们包含任何共同的键值对或数组元素，则该函数返回TRUE（1）; 否则返回FALSE（0）。如果两个值都是标量，则该函数将执行一个简单的相等性测试。如果一个参数是JSON数组，另一个参数是标量，则将标量视为数组元素。因此，可 JSON_OVERLAPS()作为的补充JSON_CONTAINS()。

       

      MEMBER OF()测试第一个操作数（标量或JSON文档）是否是作为第二个操作数传递的JSON数组的成员，如果是则返回TRUE（1），否则返回FALSE（0）。不执行操作数的类型转换。

       

      CAST(expression AS type ARRAY)允许通过将在JSON文档中找到的JSON数组json_path转换为SQL数组来创建功能索引 。类型说明符仅限于由已经支持的那些CAST()，以除外 BINARY（不支持）。CAST()（和 ARRAY关键字）的这种用法 仅受支持 InnoDB，并且仅用于创建多值索引。

       

      有关多值索引的详细信息（包括示例），请参阅“ 多值索引”。 第12.18.3节“搜索JSON值的函数”，提供了有关JSON_OVERLAPS()和的 信息MEMBER OF()以及使用示例。

       

      提示time_zone。  从MySQL 8.0.17开始， time_zone使用可以提示会话变量 SET_VAR。

       

      重做日志归档。  从MySQL 8.0.17开始，InnoDB支持重做日志归档。在执行备份操作时，复制重做日志记录的备份实用程序有时可能无法跟上重做日志生成的步伐，由于这些记录被覆盖，导致丢失重做日志记录。重做日志归档功能通过将重做日志记录顺序写入存档文件来解决此问题。备份实用程序可以根据需要从存档文件复制重做日志记录，从而避免潜在的数据丢失。有关更多信息，请参阅重做日志归档。

       

      克隆插件。  从MySQL 8.0.17开始，MySQL提供了一个克隆插件，该插件允许InnoDB在本地或从远程MySQL服务器实例克隆数据。本地克隆操作将克隆的数据存储在运行MySQL实例的同一服务器或节点上。远程克隆操作通过网络将克隆的数据从施主MySQL服务器实例传输到发起克隆操作的接收者服务器或节点。

       

      克隆插件支持复制。除了克隆数据之外，克隆操作还从供体提取并传输复制坐标，并将其应用于接收者，从而可以使用克隆插件来配置组复制成员和副本。与复制大量事务相比，使用克隆插件进行配置要快得多，效率也更高。还可以将组复制成员配置为使用克隆插件作为替代的恢复方法，以便成员自动选择从种子成员中检索组数据的最有效方法。

       

      有关更多信息，请参见第5.6.7节“克隆插件”和第18.4.3.2节“克隆分布式恢复”。

       

      哈希联接优化。  从MySQL 8.0.18开始，只要联接中的每对表都包含至少一个等联接条件，就使用哈希联接。哈希联接不需要索引，并且在大多数情况下比块嵌套循环算法更有效。可以通过这种方式优化如此处所示的联接：

       

      SELECT *

          FROM t1

          JOIN t2

              ON t1.c1=t2.c1;

       

      SELECT *

          FROM t1

          JOIN t2

              ON (t1.c1 = t2.c1 AND t1.c2 < t2.c2)

          JOIN t3

              ON (t2.c1 = t3.c1)

      哈希联接还可以用于笛卡尔积-即，未指定联接条件时。

       

      您可以使用EXPLAIN FORMAT=TREE或查看何时将哈希联接优化用于特定查询 EXPLAIN ANALYZE。（在MySQL 8.0.20及更高版本中，您也可以使用EXPLAIN，省略 FORMAT=TREE。）

       

      哈希联接可用的内存量受的值限制 join_buffer_size。在磁盘上执行需要更多内存的哈希联接；磁盘上的哈希联接可以使用的磁盘文件数受限制 open_files_limit。

       

      从MySQL 8.0.19开始，hash_join 不再支持MySQL 8.0.18中引入的优化器开关（hash_join = on仍显示为optimizer_switch值的一部分，但设置不再有效）。该HASH_JOIN和 NO_HASH_JOIN优化提示也不再支持。开关和提示现在都已弃用，并将在将来的MySQL版本中删除。在MySQL 8.0.18及更高版本中，可以使用NO_BNL优化器开关禁用哈希联接 。

       

      在MySQL 8.0.20及更高版本中，MySQL服务器中不再使用块嵌套循环，并且即使查询中不包含等联接条件，只要以前会使用块嵌套循环，就将使用哈希联接。这适用于内部非等联接，半联接，反联接，左外部联接和右外部联接。T 系统变量的 block_nested_loop标志 以及 optimizer_switchBNLNO_BNL仍然支持优化程序提示，但此后仅控制对哈希联接的使用。此外，内部联接和外部联接（包括半联接和反联接）现在都可以使用批处理密钥访问（BKA），该批处理密钥访问会增量分配联接缓冲内存，这样单个查询就不需要消耗解析所需的大量资源。 。从MySQL 8.0.18开始，仅支持内部联接的BKA。

       

      MySQL 8.0.20还用迭代器执行器替换了以前版本的MySQL中使用的执行器。这项工作包括为那些尚未优化为半联接的查询替换管理该格式查询的旧索引子查询引擎，以及以相同格式实现的查询，这些查询以前依赖于旧执行程序。 WHERE value IN (SELECT column FROM table WHERE ...)IN

       

      有关更多信息和示例，请参见 第8.2.1.4节“哈希联接优化”。另请参阅 批处理密钥访问联接。

       

      EXPLAIN ANALYZE语句。 MySQL 8.0.18中实现了 一种新形式的EXPLAIN 语句，它以处理查询所用的每个迭代器的格式EXPLAIN ANALYZE提供了有关SELECT语句 执行的扩展信息 TREE，并使得可以将估计成本与查询的实际成本进行比较。此信息包括启动成本，总成本，此迭代器返回的行数以及执行的循环数。

       

      在MySQL 8.0.21和更高版本中，该语句还支持 FORMAT=TREE说明符。 TREE是唯一受支持的格式。

       

      有关更多信息，请参见使用EXPLAIN ANALYZE获取信息。

       

      查询演员表注入。  在8.0.18及更高版本中，MySQL将强制转换操作注入表达式和条件内的查询项树中，在该表达式和条件中，参数的数据类型与预期的数据类型不匹配。这对查询结果或执行速度没有影响，但是使查询的执行等同于符合SQL标准的查询，同时保持了与MySQL早期版本的向后兼容性。

       

      现在这样的隐式转换的时间类型（之间执行DATE， DATETIME， TIMESTAMP， TIME）和数字类型（SMALLINT， TINYINT， MEDIUMINT， INT/ INTEGER， BIGINT; DECIMAL/ NUMERIC; FLOAT， DOUBLE， REAL， BIT），只要他们正在使用任何标准的数字比较运算符（相较=， >=， >， <， <=， <>/ !=，要么 <=>）。在这种情况下，任何尚未为a的值 DOUBLE都将强制转换为1。现在也可以执行强制转换注入，以比较DATE或 TIME值与 DATETIME值，其中在必要时将参数强制转换 为 DATETIME。

       

      从MySQL 8.0.21开始，在将字符串类型与其他类型进行比较时，也会执行此类转换。被投字符串类型包括CHAR， VARCHAR， BINARY， VARBINARY， BLOB， TEXT， ENUM，和 SET。将字符串类型的值与数值类型或进行比较时 YEAR，字符串强制转换为 DOUBLE; 如果其他参数的类型不是FLOAT，DOUBLE或者REAL，它也投来 DOUBLE。当将字符串类型与a DATETIME或TIMESTAMP value 进行比较时 ，字符串强制转换为DATETIME; 将字符串类型与比较时DATE，字符串被强制转换为DATE。

       

      因此能够看到通过查看的输出时石膏注入到一个给定的查询EXPLAIN ANALYZE，EXPLAIN FORMAT=JSON或者，如下所示，EXPLAIN FORMAT=TREE：

       

      mysql> CREATE TABLE d (dt DATETIME, d DATE, t TIME);

      Query OK, 0 rows affected (0.62 sec)

       

      mysql> CREATE TABLE n (i INT, d DECIMAL, f FLOAT, dc DECIMAL);

      Query OK, 0 rows affected (0.51 sec)

       

      mysql> CREATE TABLE s (c CHAR(25), vc VARCHAR(25),

          ->     bn BINARY(50), vb VARBINARY(50), b BLOB, t TEXT,

          ->     e ENUM('a', 'b', 'c'), se SET('x' ,'y', 'z'));

      Query OK, 0 rows affected (0.50 sec)

       

      mysql> EXPLAIN FORMAT=TREE SELECT * from d JOIN n ON d.dt = n.i\G

      *************************** 1. row ***************************

      EXPLAIN: -> Inner hash join (cast(d.dt as double) = cast(n.i as double))

      (cost=0.70 rows=1)

          -> Table scan on n  (cost=0.35 rows=1)

          -> Hash

              -> Table scan on d  (cost=0.35 rows=1)

       

      mysql> EXPLAIN FORMAT=TREE SELECT * from s JOIN d ON d.dt = s.c\G

      *************************** 1. row ***************************

      EXPLAIN: -> Inner hash join (d.dt = cast(s.c as datetime(6)))  (cost=0.72 rows=1)

          -> Table scan on d  (cost=0.37 rows=1)

          -> Hash

              -> Table scan on s  (cost=0.35 rows=1)

       

      1 row in set (0.01 sec)

       

      mysql> EXPLAIN FORMAT=TREE SELECT * from n JOIN s ON n.d = s.c\G

      *************************** 1. row ***************************

      EXPLAIN: -> Inner hash join (cast(n.d as double) = cast(s.c as double))  (cost=0.70 rows=1)

          -> Table scan on s  (cost=0.35 rows=1)

          -> Hash

              -> Table scan on n  (cost=0.35 rows=1)

       

      1 row in set (0.00 sec)

      也可以通过执行看到这种强制类型转换EXPLAIN [FORMAT=TRADITIONAL]，在这种情况下，也有必要SHOW WARNINGS在执行EXPLAIN语句后 发出。

       

      TIMESTAMP和DATETIME的时区支持。  从MySQL 8.0.19开始，服务器接受带有插入的datetime（TIMESTAMP和 DATETIME）值的时区偏移量。该偏移量使用与设置time_zone系统变量时使用的格式相同的格式，不同之处在于，当偏移量的小时部分小于10且'-00:00'不允许时，前导零是必需的 。日期时间文字，其中包括时区偏移的例子是 '2019-12-11 10:40:30-05:00'， '2003-04-14 03:30:00+10:00'和 '2020-01-01 15:35:45+05:30'。

       

      选择日期时间值时不显示时区偏移量。

       

      包含时区偏移量的Datetime文字可用作准备好的语句参数值。

       

      作为这项工作的一部分，用于设置 time_zone系统变量的值现在也被限制 -14:00为+14:00，包括在内。（它仍然可以分配名称值以 time_zone诸如 'EST'， 'Posix/Australia/Brisbane'和 'Europe/Stockholm'该变量，条件是MySQL的时区表被加载;另见 填充的时区表）。

       

      有关更多信息和示例，请参见 第5.1.14节“ MySQL服务器时区支持”以及 第11.2.2节“ DATE，DATETIME和TIMESTAMP类型”。

       

      JSON模式检查约束失败的准确信息。  当 JSON_SCHEMA_VALID()用于指定CHECK约束时，MySQL 8.0.19和更高版本提供有关此类约束失败原因的准确信息。

       

      有关示例和更多信息，请参见 JSON_SCHEMA_VALID（）和CHECK约束。另请参见第13.1.20.6节“检查约束”。

       

      行和列别名带有ON DUPLICATE KEY UPDATE。  从MySQL 8.0.19开始，可以使用别名引用要插入的行，以及（可选）引用其列。考虑在具有列 和INSERT的表t上的以下 语句 ： ab

       

      INSERT INTO t SET a=9,b=5

          ON DUPLICATE KEY UPDATE a=VALUES(a)+VALUES(b);

      使用new新行的别名，在某些情况下，使用别名m以及 n该行的列，INSERT可以用许多不同的方式重写该 语句，此处显示了一些示例：

       

      INSERT INTO t SET a=9,b=5 AS new

          ON DUPLICATE KEY UPDATE a=new.a+new.b;

       

      INSERT INTO t VALUES(9,5) AS new

          ON DUPLICATE KEY UPDATE a=new.a+new.b;

       

      INSERT INTO t SET a=9,b=5 AS new(m,n)

          ON DUPLICATE KEY UPDATE a=m+n;

       

      INSERT INTO t VALUES(9,5) AS new(m,n)

          ON DUPLICATE KEY UPDATE a=m+n;

      欲了解更多信息和示例，请参见 第13.2.6.2，“INSERT ... ON DUPLICATE KEY UPDATE语句”。

       

      SQL标准的显式表子句和表值构造函数。  根据SQL标准添加了表值构造函数和显式表子句。这些分别在MySQL 8.0.19中作为 TABLE语句和 VALUES语句实现。

       

      该TABLE语句具有格式，并且等效于。它支持 和 子句（后者带有optional ），但不允许选择单个表列。 可以在您使用等效 语句的任何地方使用；这包括连接，联合， ，， 语句和子查询。例如： TABLE table_nameSELECT * FROM table_nameORDER BYLIMITOFFSETTABLESELECTINSERT ... SELECTREPLACECREATE TABLE ... SELECT

       

      TABLE t1 UNION TABLE t2 相当于 SELECT * FROM t1 UNION SELECT * FROM t2

       

      CREATE TABLE t2 TABLE t1 相当于 CREATE TABLE t2 SELECT * FROM t1

       

      SELECT a FROM t1 WHERE b > ANY (TABLE t2)等价于SELECT a FROM t1 WHERE b > ANY (SELECT * FROM t2)。

       

      VALUES可用于一个表值提供给一个INSERT， REPLACE或 SELECT语句，和由的VALUES关键字随后进行了一系列行构造（的ROW()）由逗号分隔。例如，该语句 INSERT INTO t1 VALUES ROW(1,2,3), ROW(4,5,6), ROW(7,8,9)提供与SQL兼容的等效于MySQL特定的INSERT INTO t1 VALUES (1,2,3), (4,5,6), (7,8,9)。您还可以像选择VALUES表一样从表值构造函数中进行选择 ，请记住，这样做时必须提供表别名，并像使用SELECT其他别名一样使用它 。这包括联接，联合和子查询。

       

      有关详细信息TABLE，并 VALUES和其使用的示例，请参阅本文档的以下部分：

       

      第13.2.12节“ TABLE语句”

       

      第13.2.14节“ VALUES语句”

       

      第13.1.20.4节“ CREATE TABLE ... SELECT语句”

       

      第13.2.6.1节“ INSERT ... SELECT语句”

       

      第13.2.10.2节“ JOIN子句”

       

      第13.2.11节“子查询”

       

      第13.2.10.3节“ UNION子句”

       

      FORCE INDEX，IGNORE INDEX的优化程序提示。  MySQL 8.0引入了索引级优化器提示，这些提示与第8.9.4节“索引提示”中所述的传统索引提示类似。新的提示这里列出，与他们一起FORCE INDEX或IGNORE INDEX 等价物：

       

      GROUP_INDEX： 相当于 FORCE INDEX FOR GROUP BY

       

      NO_GROUP_INDEX： 相当于 IGNORE INDEX FOR GROUP BY

       

      JOIN_INDEX： 相当于 FORCE INDEX FOR JOIN

       

      NO_JOIN_INDEX： 相当于 IGNORE INDEX FOR JOIN

       

      ORDER_INDEX： 相当于 FORCE INDEX FOR ORDER BY

       

      NO_ORDER_INDEX： 相当于 IGNORE INDEX FOR ORDER BY

       

      INDEX：与GROUP_INDEX加 JOIN_INDEX号 相同 ORDER_INDEX; 等效于FORCE INDEX没有修饰符

       

      NO_INDEX：与NO_GROUP_INDEX加 NO_JOIN_INDEX号 相同 NO_ORDER_INDEX; 等效于IGNORE INDEX没有修饰符

       

      例如，以下两个查询是等效的：

       

      SELECT a FROM t1 FORCE INDEX (i_a) FOR JOIN WHERE a=1 AND b=2;

       

      SELECT /*+ JOIN_INDEX(t1 i_a) */ a FROM t1 WHERE a=1 AND b=2;

      前面列出的优化器提示在语法和用法上与现有索引级优化器提示遵循相同的基本规则。

       

      这些优化器提示旨在替换FORCE INDEX和IGNORE INDEX，我们计划在将来的MySQL版本中弃用和，然后从MySQL中删除。他们没有实现的一个完全等同的形式USE INDEX；相反，你可以使用一个或多个 NO_INDEX， NO_JOIN_INDEX， NO_GROUP_INDEX，或 NO_ORDER_INDEX达到同样的效果。

       

      有关更多信息和使用示例，请参见“ 索引级优化器提示”。

       

      JSON_VALUE（）函数。  MySQL 8.0.21实现了一个JSON_VALUE()旨在简化JSON 列索引的新功能 。在最基本的形式中，它以JSON文档和指向该文档中单个值的JSON路径作为参数，并且（可选）允许您使用RETURNING关键字指定返回类型 。 等效于此： JSON_VALUE(json_doc, path RETURNING type)

       

      CAST(

          JSON_UNQUOTE( JSON_EXTRACT(json_doc, path) )

          AS type

      );

      您还可以指定ON EMPTY， ON ERROR或两个子句，与一起使用 JSON_TABLE()。

       

      您可以使用JSON_VALUE()在这样的JSON列上的表达式上创建索引：

       

      CREATE TABLE t1(

          j JSON,

          INDEX i1 ( (JSON_VALUE(j, '$.id' RETURNING UNSIGNED)) )

      );

       

      INSERT INTO t1 VALUES ROW('{"id": "123", "name": "shoes", "price": "49.95"}');

      使用此表达式的查询（例如此处所示）可以使用索引：

       

      SELECT name, price FROM t1

          WHERE JSON_VALUE(j, '$.id' RETURNING UNSIGNED) = 123;

      在许多情况下，这比从该JSON列创建一个生成的列然后在生成的列上创建索引要简单得多。

       

      有关更多信息和示例，请参见的描述 JSON_VALUE()。

       

      用户评论和用户属性。  MySQL 8.0.21引入了在创建或更新用户帐户时设置用户注释和用户属性的功能。用户注释包括作为参数传递COMMENT给与CREATE USERor ALTER USER语句一起使用的子句的任意文本。用户属性由JSON对象形式的数据组成，该数据作为参数传递给与ATTRIBUTE这两个语句之一一起使用的 子句。该属性可以包含JSON对象表示法中的任何有效键值对。仅一个 COMMENT或ATTRIBUTE 可以在单一使用CREATE USER或 ALTER USER 声明。

       

      用户注释和用户属性在内部作为JSON对象存储在一起，注释文本作为元素的值comment作为其键。可以从 表的ATTRIBUTE列中 检索此信息 INFORMATION_SCHEMA.USER_ATTRIBUTES。因为它是JSON格式，所以您可以使用MySQL的JSON函数和运算符来解析其内容（请参见 第12.18节“ JSON函数”）。与使用JSON_MERGE_PATCH() 函数时一样，对用户属性的连续更改将与其当前值合并。

       

      例：

       

      mysql> CREATE USER 'mary'@'localhost' COMMENT 'This is Mary Smith\'s account';

      Query OK, 0 rows affected (0.33 sec)

       

      mysql> ALTER USER 'mary'@'localhost'

          -≫     ATTRIBUTE '{"fname":"Mary", "lname":"Smith"}';

      Query OK, 0 rows affected (0.14 sec)

       

      mysql> ALTER USER 'mary'@'localhost'

          -≫     ATTRIBUTE '{"email":"mary.smith@example.com"}';

      Query OK, 0 rows affected (0.12 sec)

       

      mysql> SELECT

          ->    USER,

          ->    HOST,

          ->    ATTRIBUTE->>"$.fname" AS 'First Name',

          ->    ATTRIBUTE->>"$.lname" AS 'Last Name',

          ->    ATTRIBUTE->>"$.email" AS 'Email',

          ->    ATTRIBUTE->>"$.comment" AS 'Comment'

          -> FROM INFORMATION_SCHEMA.USER_ATTRIBUTES

          -> WHERE USER='mary' AND HOST='localhost'\G

      *************************** 1. row ***************************

            USER: mary

            HOST: localhost

      First Name: Mary

       Last Name: Smith

           Email: mary.smith@example.com

         Comment: This is Mary Smith's account

      1 row in set (0.00 sec)

      有关更多信息和示例，请参见 第13.7.1.3节“ CREATE USER语句”，第13.7.1.1节“ ALTER USER语句”和 第25.46节“ INFORMATION_SCHEMA USER_ATTRIBUTES表”。

       

      新的optimizer_switch标志。  MySQL 8.0.21为optimizer_switch系统变量添加了两个新标志， 如下表所示：

       

      prefer_ordering_index 旗

       

      默认情况下， 只要优化器确定这将导致更快的执行速度，MySQL就会尝试对具有子句的任何查询ORDER BY或GROUP BY查询使用有序索引LIMIT。由于在某些情况下为此类查询选择其他优化效果实际上可能会更好，因此现在可以通过将prefer_ordering_index标志 设置为来禁用此优化 off。

       

      此标志的默认值为 on。

       

      subquery_to_derived 旗

       

      当此标志设置on为时，优化程序将合格的标量子查询转换为派生表上的联接。例如，查询 SELECT * FROM t1 WHERE t1.a > (SELECT COUNT(a) FROM t2)被重写为 SELECT t1.a FROM t1 JOIN ( SELECT COUNT(t2.a) AS c FROM t2 ) AS d WHERE t1.a > d.c。

       

      这种优化可以应用到子查询其是的一部分SELECT， WHERE，JOIN，或 HAVING条款; 包含一个或多个聚合函数，但没有GROUP BY 子句；不相关 并且不使用任何不确定的函数。

       

      优化也可应用于表子查询这对参数IN， NOT IN，EXISTS，或 NOT EXISTS，并且其不包含GROUP BY。例如，查询SELECT * FROM t1 WHERE t1.b < 0 OR t1.a IN (SELECT t2.a + 1 FROM t2)被重写为SELECT a, b FROM t1 LEFT JOIN (SELECT DISTINCT 1 AS e1, t2.a AS e2 FROM t2) d ON t1.a + 1 = d.e2 WHERE t1.b < 0 OR d.e1 IS NOT NULL。

       

      通常禁用此优化，因为在大多数情况下它不会产生明显的性能优势，因此off默认情况下将标志设置为。

       

      有关更多信息，请参见 第8.9.2节“可切换的优化”。另请参见 第8.2.1.19节“ LIMIT查询优化”， 第8.2.2.1节“使用半联接转换优化IN和EXISTS子查询谓词”和 第8.2.2.4节“通过合并优化派生表，视图引用和公用表表达式”或物化”。

       

      XML增强功能。  从MySQL 8.0.21开始，该LOAD XML语句现在支持 CDATA要导入的XML中的部分。

       

      现在支持转换为YEAR类型。  从MySQL 8.0.22开始，服务器允许强制转换为 YEAR。无论是 CAST()与 CONVERT()功能支持单位，两位数字，和四位 YEAR值。对于一位和两位数的值，允许的范围是0-99。四位数的值必须在1901-2155范围内。 YEAR也可以用作JSON_VALUE() 函数的返回类型；此功能仅支持四位数的年份。

       

      字符串，时间和日期以及浮点值都可以转换为YEAR。不支持将GEOMETRY值 强制转换为 YEAR。

       

      有关更多信息，包括转换规则，请参见CONVERT() 功能说明。

       

      将TIMESTAMP值检索为UTC。  MySQL 8.0.22和更高版本支持在检索时使用，将 TIMESTAMP列值从系统时区转换为UTC ，其中指定符是 或之一 。如果需要，可以将转换类型返回的值的精度 指定为最多6个小数位。此结构不支持该 关键字。 DATETIMECAST(value AT TIME ZONE specifier AS DATETIME)[INTERVAL] '+00:00''UTC'DATETIMEARRAY

       

      TIMESTAMP还支持使用时区偏移量插入表中的值。使用 AT TIME ZONE不支持 CONVERT()或任何其他MySQL功能或结构。

       

      有关更多信息和示例，请参见CAST()功能说明。

       

      转储文件输出同步。  当通过SELECT INTO DUMPFILE和SELECT INTO OUTFILE语句写入文件时，MySQL 8.0.22和更高版本支持定期同步 。可以通过将select_into_disk_sync 系统变量设置为ON; 来启用 。写缓冲区的大小由为设置的值确定 select_into_buffer_size; 默认值为131072（2 17）字节。

       

      另外，可以使用设置与磁盘同步后的可选延迟 select_into_disk_sync_delay。默认值为无延迟（0毫秒）。

       

      有关更多信息，请参阅此项目之前引用的变量说明。

       

      单一准备报表。  从MySQL 8.0.22开始，一个prepared语句只准备一次，而不是每次执行一次。这是在执行时完成的 PREPARE。对于存储过程中的任何语句也是如此。第一次执行存储过程时，该语句仅准备一次。

       

      更改的结果是，解决准备好的语句中使用的动态参数的方式也以以下方式更改：

       

      在执行形式的预备语句时 ， 为参数传递整数值不再导致 选择列表中第th个表达式对结果进行排序 ；结果不再像预期的那样排序。 SELECT expr1, expr2, ... FROM table ORDER BY ?NNORDER BY constant

       

      在准备好的语句中不再接受以下窗口函数：

       

      NTILE(NULL)

       

      NTH_VALUE(expr, NULL)

       

      LEAD(expr, nn)和 ，其中 是负数 LAG(expr, nn)nn

       

      这有助于更好地符合SQL标准。

       

      现在，在准备好的语句中引用的用户变量具有在准备语句时确定其数据类型的功能。该类型在每次后续执行语句时都会保留。

       

      现在，由存储过程中发生的语句引用的用户变量具有在首次执行该语句时确定的数据类型；对于包含存储过程的任何后续调用，该类型都会保留。

       

      仅将一次语句用作预备语句或在存储过程中使用，可以提高语句的性能，因为这样可以避免重复准备的额外费用。这样做还避免了准备结构的可能的多个回滚，这是MySQL中众多问题的根源。

       

      另外，作为这项工作的一部分，已经作了修改如何每个窗口的功能 LAG()， LEAD()以及 NTILE()处理其第一个参数。有关详细信息，请参见功能说明。

       

      RIGHT JOIN作为LEFT JOIN处理。  从MySQL 8.0.22开始，服务器将RIGHT JOIN内部的所有实例处理 为LEFT JOIN，从而消除了许多特殊情况，在这些特殊情况下，解析时未执行完整的转换。

       

      派生条件下推优化。  MySQL 8.0.22（及更高版本）为具有实体化派生表的查询实现派生条件下推。对于诸如之类的查询，现在可以在许多情况下将外部 条件下推到派生表，在这种情况下结果为。 SELECT * FROM (SELECT i, j FROM t1) AS dt WHERE i > constantWHERESELECT * FROM (SELECT i, j FROM t1 WHERE i > constant) AS dt

       

      以前，如果派生表已实现且未合并，则MySQL实现整个表，然后使用WHERE条件限定行。WHERE使用派生条件下推优化将条件移入子查询通常可以减少必须处理的行数，这可以减少执行查询所需的时间。

       

      WHERE当派生表不使用任何聚合或窗口函数时，可以将 外部条件直接下推到物化派生表。当派生表具有a GROUP BY并且不使用任何窗口函数时，WHERE可以将外部条件作为HAVING 条件下推到派生表。WHERE当派生表使用窗口函数并且WHERE窗口函数的PARTITION子句中使用外部引用列 时，也可以向下推该条件。

       

      默认情况下，派生条件下推处于启用状态，如 optimizer_switch系统变量的 derived_condition_pushdown标志所示。MySQL 8.0.22中添加的标志on 默认设置为；要禁用特定查询的优化，可以使用 NO_DERIVED_CONDITION_PUSHDOWN 优化器提示（也在MySQL 8.0.22中添加）。如果优化是禁用的，由于 derived_condition_pushdown设定为 off，您可以启用它使用给定的查询 DERIVED_CONDITION_PUSHDOWN。

       

      派生条件下推优化不能用于包含UNIONor LIMIT子句的派生表 。此外，本身使用子查询的条件不能被下推，并且 WHERE条件不能被下推到也是外部联接的内部表的派生表。有关更多信息和示例，请参见 第8.2.2.5节“派生条件下推优化”。

       

      对MySQL授权表的非锁定读取。  从MySQL 8.0.22开始，为了允许在MySQL授权表上进行并发DML和DDL操作，以前在MySQL授权表上获得行锁的读取操作将作为非锁定读取执行。

       

      现在，作为对MySQL授权表的非锁定读取而执行的操作包括：

       

      SELECT语句和其他只读SELECT ... FOR SHARE语句，它们使用任何事务隔离级别通过联接列表和子查询（包括语句）从授予表中读取数据 。

       

      DML操作使用任何事务隔离级别从授权表中读取数据（通过联接列表或子查询），但不修改它们。

       

      MySQL 8.0中不推荐使用的功能

      以下功能在MySQL 8.0中已弃用，并且可能在以后的系列中被删除或将被删除。在显示替代方案的地方，应更新应用程序以使用它们。

       

      对于使用在更高版本的MySQL系列中已删除的MySQL 8.0中不推荐使用的功能的应用程序，将语句从MySQL 8.0源复制到更高版本的副本时，语句可能会失败，或者可能对源和副本产生不同的影响。为避免此类问题，应修改使用8.0中不推荐使用的功能的应用程序，以避免出现这种情况，并在可能的情况下使用替代方法。

       

      该utf8mb3字符集已被弃用。请utf8mb4改用。

       

      因为它caching_sha2_password是MySQL 8.0中的默认身份验证插件，并且提供了该sha256_password身份验证插件的功能的超集 ， sha256_password所以已弃用，并将在以后的MySQL版本中将其删除。使用sha256_password进行身份验证的MySQL帐户应迁移为使用caching_sha2_password 。

       

      该validate_password插件已被重新实现以使用服务器组件基础结构。的插件形式validate_password仍然可用，但已过时，并将在MySQL的未来版本中删除。使用插件的MySQL安装应过渡到使用组件。请参见 第6.4.3.3节“过渡到密码验证组件”。

       

      和 语句 的ENGINE子句 已弃用。 ALTER TABLESPACEDROP TABLESPACE

       

      在 PAD_CHAR_TO_FULL_LENGTH SQL模式已经过时了。

       

      AUTO_INCREMENT不支持type FLOAT和 DOUBLE（以及任何同义词）的列。考虑AUTO_INCREMENT 从此类列中删除属性，或将其转换为整数类型。

       

      的UNSIGNED属性被弃用类型的列FLOAT， DOUBLE和 DECIMAL（和任何同义词）。考虑CHECK对此类列使用简单约束。

       

      FLOAT(M,D) 和 语法指定的位数类型的列的数目 和 （和任何同义词）是一个非标准MySQL扩展。不建议使用此语法。 DOUBLE(M,D)FLOATDOUBLE

       

      ZEROFILL对于数字数据类型，不建议使用 该属性，对于整数数据类型，则不建议使用显示宽度属性。考虑使用替代方法来产生这些属性的效果。例如，应用程序可以使用该 LPAD()功能将数字零填充到所需宽度，或者可以将格式化的数字存储在CHAR 列中。

       

      对于字符串数据类型，该BINARY 属性是非标准的MySQL扩展，它是用于指定_bin列字符集（或未指定列字符集的表默认字符集）的二进制（）归类的简写形式。在MySQL 8.0中，这种非标准用法 BINARY是不明确的，因为 utf8mb4字符集具有多个 _bin排序规则，因此BINARY不赞成使用该属性，并且在将来的MySQL版本中将删除对该 属性的支持。应将应用程序调整为使用显式 _bin排序规则。

       

      BINARY用于指定数据类型或字符集 的用法保持不变。

       

      非标准C风格 &&， ||和 !运营商认为是标准的SQL同义词 AND， OR和 NOT运营商，分别已被取消。使用非标准运算符的应用程序应调整为使用标准运算符。

       

      注意

      使用的||，除非被弃用 PIPES_AS_CONCAT启用SQL模式。在这种情况下，||表示SQL标准字符串串联运算符。

       

      该JSON_MERGE()功能已弃用。使用 JSON_MERGE_PRESERVE() 代替。

       

      不建议使用SQL_CALC_FOUND_ROWS查询修饰符和附带FOUND_ROWS() 功能。有关FOUND_ROWS()替代策略的信息，请参见 说明。

       

      从MySQL 8.0.13开始，不 支持TABLESPACE = innodb_file_per_tableand TABLESPACE = innodb_temporary子句 CREATE TEMPORARY TABLE。

       

      对于SELECT报表，使用的INTO条款之后， FROM而不是在的结尾 SELECT被弃用的MySQL 8.0.20的。最好将放在 INTO语句的末尾。

       

      对于UNION语句，INTO自MySQL 8.0.20起已弃用了这两个变体：

       

      在查询表达式的结尾查询块中，使用INTObefore FROM。

       

      在查询表达式的带括号的尾随块中，请使用INTO，而无论其相对于的位置FROM。

       

      请参见第13.2.10.1节“ SELECT ... INTO语句”和 第13.2.10.3节“ UNION子句”。

       

      该mysql_upgrade客户端已被弃用，因为它的功能升级的系统表mysql系统架构和对象在其他模式已移动到MySQL服务器。请参见 第2.11.3节“ MySQL升级过程将升级什么”。

       

      该--no-dd-upgrade服务器选项已被弃用。该--upgrade选件取代了该 选件，该选件可以更好地控制数据字典和服务器升级行为。

       

      该mysql_upgrade_info文件（已创建数据目录并用于存储MySQL版本号）已被弃用，并将在以后的MySQL版本中删除。

       

      不建议使用relay_log_info_file系统变量和--master-info-file选项。以前，这些被用来当指定中继日志信息记录和源信息日志的名称 relay_log_info_repository=FILE ，并 master_info_repository=FILE 分别设置，但这些设置已被弃用。崩溃安全副本表已取代了用于中继日志信息日志和源信息日志的文件，这是MySQL 8.0中的默认设置。

       

      max_length_for_sort_data 由于优化器的更改， 该变量已过时且无效，现在已弃用该 系统变量。

       

      不建议使用这些旧参数来压缩与服务器的连接： --compress客户端命令行选项；C API函数的 MYSQL_OPT_COMPRESS选项 mysql_options()；该 slave_compressed_protocol 系统变量。有关替代使用的参数的信息，请参见 第4.2.8节“连接压缩控制”。

       

      不建议使用MYSQL_PWD环境变量来指定MySQL密码。

       

      从MySQL 8.0.20开始，不赞成 使用VALUES()来访问中的新行值 INSERT ... ON DUPLICATE KEY UPDATE。请为新的行和列使用别名。

       

      因为ON ERROR在ON EMPTY调用时指定before 违反 JSON_TABLE()了SQL标准，所以现在在MySQL中不推荐使用此语法。从MySQL 8.0.20开始，只要您尝试这样做，服务器就会打印警告。在单个JSON_TABLE() 调用中指定这两个子句时，请确保ON EMPTY首先使用该子句。

       

      从未将具有索引前缀的列作为表分区键的一部分来支持。以前，在创建，更改或升级分区表时允许使用这些表，但表的分区功能将其排除在外，服务器也不会发出警告，表明已发生这种情况。现在已弃用这种允许的行为，并且会在将来的MySQL版本中删除该行为，在该版本的MySQL中，在分区键中使用任何此类列将导致拒绝CREATE TABLEor ALTER TABLE语句。

       

      从MySQL 8.0.21开始，只要将使用索引前缀的列指定为分区键的一部分，就会为每个此类列生成警告。每当 CREATE TABLEor ALTER TABLE语句由于提议的分区键中的所有列都具有索引前缀而被拒绝时，所产生的错误现在将提供拒绝的确切原因。在这两种情况下，都包括通过使用空PARTITION BY KEY()子句将分区函数中使用的列隐式定义为表的主键中的列的情况 。

       

      有关更多信息和示例，请参阅 键分区不支持的列索引前缀。

       

      从MySQL 8.0.22开始不推荐使用InnoDB memcached插件，并且在将来的MySQL版本中将不再支持它。

       

      MySQL 8.0中删除的功能

      以下各项已过时，并且已在MySQL 8.0中删除。在显示替代方案的地方，应更新应用程序以使用它们。

       

      对于使用MySQL 8.0中已删除功能的MySQL 5.7应用程序，将语句从MySQL 5.7源复制到MySQL 8.0副本时，语句可能会失败，或对源和副本产生不同的影响。为避免此类问题，应修改使用MySQL 8.0中删除的功能的应用程序以避免这些问题，并在可能的情况下使用替代方法。

       

      在innodb_locks_unsafe_for_binlog除去系统变量。该READ COMMITTED隔离级别提供了类似的功能。

       

      information_schema_statsMySQL 8.0.0中引入 的变量已被删除，并information_schema_stats_expiry 在MySQL 8.0.3中被替换 。

       

      information_schema_stats_expiry定义缓存INFORMATION_SCHEMA表统计信息的到期设置 。有关更多信息，请参见 第8.2.3节“优化INFORMATION_SCHEMA查询”。

       

      与已过时的InnoDB系统表相关的代码已在MySQL 8.0.3中删除。 INFORMATION_SCHEMA基于InnoDB系统表的视图被数据字典表上的内部系统视图替换。受影响的 InnoDB INFORMATION_SCHEMA视图已重命名：

       

      表1.1重命名的InnoDB信息架构视图

       

      旧名称新名字

      INNODB_SYS_COLUMNSINNODB_COLUMNS

      INNODB_SYS_DATAFILESINNODB_DATAFILES

      INNODB_SYS_FIELDSINNODB_FIELDS

      INNODB_SYS_FOREIGNINNODB_FOREIGN

      INNODB_SYS_FOREIGN_COLSINNODB_FOREIGN_COLS

      INNODB_SYS_INDEXESINNODB_INDEXES

      INNODB_SYS_TABLESINNODB_TABLES

      INNODB_SYS_TABLESPACESINNODB_TABLESPACES

      INNODB_SYS_TABLESTATSINNODB_TABLESTATS

      INNODB_SYS_VIRTUALINNODB_VIRTUAL

       

      升级到MySQL 8.0.3或更高版本后，请更新所有引用先前InnoDB INFORMATION_SCHEMA视图名称的脚本。

       

      与帐户管理相关的以下功能已删除：

       

      使用GRANT创建用户。而是使用CREATE USER。遵循这种做法会使 NO_AUTO_CREATE_USERSQL模式对GRANT 语句不重要，因此也将其删除，并且当sql_mode选项文件中选项的此值的存在阻止mysqld启动时，现在会将错误写入服务器日志。

       

      使用GRANT修改不是权限指派其他帐户属性。这包括身份验证，SSL和资源限制属性。而是在创建帐户时使用CREATE USER或在之后使用修改这些 属性ALTER USER。

       

      IDENTIFIED BY PASSWORD 'auth_string'CREATE USER 和的 语法GRANT。而是使用 for 和 ，其中 值的格式与命名插件兼容。 IDENTIFIED WITH auth_plugin AS 'auth_string'CREATE USERALTER USER'auth_string'

       

      此外，由于IDENTIFIED BY PASSWORD删除了语法，因此 log_builtin_as_identified_by_password 系统变量是多余的，因此已删除。

       

      该PASSWORD()功能。此外，PASSWORD()删除意味着 语法不再可用。 SET PASSWORD ... = PASSWORD('auth_string')

       

      该old_passwords系统变量。

       

      查询缓存已删除。删除包括以下项目：

       

      该FLUSH QUERY CACHE和 RESET QUERY CACHE语句。

       

      这些系统变量： query_cache_limit， query_cache_min_res_unit， query_cache_size， query_cache_type， query_cache_wlock_invalidate。

       

      这些状态变量： Qcache_free_blocks， Qcache_free_memory， Qcache_hits， Qcache_inserts， Qcache_lowmem_prunes， Qcache_not_cached， Qcache_queries_in_cache， Qcache_total_blocks。

       

      这些线程状态：checking privileges on cached query，checking query cache for query，invalidating query cache entries，sending cached result to client，storing result in query cache，Waiting for query cache lock。

       

      该SQL_CACHE SELECT修改。

       

      这些不建议使用的查询缓存项仍然不建议使用，但没有效果，将在以后的MySQL版本中删除：

       

      该SQL_NO_CACHE SELECT修改。

       

      该ndb_cache_check_time系统变量。

       

      该have_query_cache系统变量保持过时，总有一个价值 NO，并会在将来的MySQL版本中删除。

       

      数据字典提供有关数据库对象的信息，因此服务器不再检查数据目录中的目录名称以查找数据库。因此， --ignore-db-dir选项和 ignore_db_dirs系统变量是多余的并被删除。

       

      DDL日志（也称为元数据日志）已被删除。从MySQL 8.0.3开始，此功能由数据字典innodb_ddl_log表处理 。请参阅 查看DDL日志。

       

      该tx_isolation和 tx_read_only系统变量已被删除。使用transaction_isolation和 transaction_read_only代替。

       

      该sync_frm系统变量已被删除，因为.frm文件已经过时。

       

      该secure_auth系统变量和 --secure-auth客户端选项已被删除。C API函数的MYSQL_SECURE_AUTH选项mysql_options()已删除。

       

      的multi_range_count系统变量被移除。

       

      该log_warnings系统变量和 --log-warnings服务器选项已被删除。请改用 log_error_verbosity系统变量。

       

      sql_log_bin系统变量 的全局范围 已删除。sql_log_bin仅具有会话作用域，@@GLOBAL.sql_log_bin应调整依赖于访问的应用程序 。

       

      该metadata_locks_cache_size和 metadata_locks_hash_instances系统变量被删除。

       

      未使用date_format， datetime_format， time_format，和 max_tmp_tables系统变量被删除。

       

      这些弃用兼容性SQL模式被移除： DB2，MAXDB， MSSQL，MYSQL323， MYSQL40，ORACLE， POSTGRESQL， NO_FIELD_OPTIONS， NO_KEY_OPTIONS， NO_TABLE_OPTIONS。它们不能再分配给sql_mode系统变量或用作mysqldump --compatible选项的允许值 。

       

      删除MAXDB意味着将或 的 TIMESTAMP数据类型 视为 ，而不再视为。 CREATE TABLEALTER TABLETIMESTAMPDATETIME

       

      子句 的不推荐使用ASC或 DESC限定符将GROUP BY被删除。先前依赖于GROUP BY排序的查询所产生的结果可能与以前的MySQL版本不同。要产生给定的排序顺序，请提供一个ORDER BY 子句。

       

      该语句的EXTENDED和 PARTITIONS关键字 EXPLAIN已删除。这些关键字是不必要的，因为它们的效果始终处于启用状态。

       

      这些与加密有关的项目已删除：

       

      该ENCODE()和 DECODE()功能。

       

      该ENCRYPT()功能。

       

      的DES_ENCRYPT()，和 DES_DECRYPT()功能的 --des-key-file选项， have_crypt系统变量，则 DES_KEY_FILE该选项 FLUSH语句和 HAVE_CRYPT CMake的 选项。

       

      代替已删除的加密功能：对于 ENCRYPT()，请考虑SHA2()改为使用 单向哈希。对于其他，请考虑使用 AES_ENCRYPT()和 AES_DECRYPT()代替。

       

      在MySQL 5.7，在多个名称提供了一些空间函数被弃用使得空间功能的命名空间更一致的方向移动，其目标是使每个空间的功能名称开头ST_，如果执行精确的操作，或者MBR如果它执行基于最小边界矩形的操作。在MySQL 8.0中，不赞成使用的函数被删除，仅留下相应的ST_和 MBR函数：

       

      这些功能有利于去除 MBR名称： Contains()， Disjoint()， Equals()， Intersects()， Overlaps()， Within()。

       

      这些功能有利于去除 ST_名称：Area()， AsBinary()， AsText()，AsWKB()， AsWKT()，Buffer()， Centroid()， ConvexHull()， Crosses()， Dimension()， Distance()， EndPoint()， Envelope()， ExteriorRing()， GeomCollFromText()， GeomCollFromWKB()， GeomFromText()， GeomFromWKB()， GeometryCollectionFromText()， GeometryCollectionFromWKB()， GeometryFromText()， GeometryFromWKB()， GeometryN()， GeometryType()， InteriorRingN()， IsClosed()， IsEmpty()， IsSimple()， LineFromText()， LineFromWKB()， LineStringFromText()， LineStringFromWKB()， MLineFromText()， MLineFromWKB()， MPointFromText()， MPointFromWKB()， MPolyFromText()， MPolyFromWKB()， MultiLineStringFromText()， MultiLineStringFromWKB()， MultiPointFromText()， MultiPointFromWKB()， MultiPolygonFromText()， MultiPolygonFromWKB()， NumGeometries()， NumInteriorRings()， NumPoints()， PointFromText()， PointFromWKB()， PointN()， PolyFromText()， PolyFromWKB()， PolygonFromText()， PolygonFromWKB()， SRID()， StartPoint()， Touches()，X()， Y()。

       

      GLength()被取消赞成 ST_Length()。

       

      第12.17.4节“从WKB值创建几何值 的函数”中描述的函数 以前接受WKB字符串或几何参数。几何参数不再被允许并产生错误。有关从不使用几何参数迁移查询的准则，请参见该部分。

       

      解析器不再视为SQL语句中\N的同义词NULL。使用 NULL代替。

       

      这种变化不影响文本文件导入和导出操作与执行LOAD DATA或 SELECT ... INTO OUTFILE用于其NULL 继续受到代表\N。请参见 第13.2.7节“ LOAD DATA语句”。

       

      PROCEDURE ANALYSE() 语法已删除。

       

      客户端--ssl和 --ssl-verify-server-cert选项已被删除。使用 --ssl-mode=REQUIRED代替--ssl=1或 --enable-ssl。使用 --ssl-mode=DISABLED替代--ssl=0，--skip-ssl或 --disable-ssl。使用 --ssl-mode=VERIFY_IDENTITY 代替--ssl-verify-server-cert 选项。（服务器端 --ssl选项保持不变。）

       

      对于C API，MYSQL_OPT_SSL_ENFORCE和的 MYSQL_OPT_SSL_VERIFY_SERVER_CERT选项mysql_options() 对应于客户端--ssl和 --ssl-verify-server-cert选项，并被删除。使用MYSQL_OPT_SSL_MODE选项值SSL_MODE_REQUIRED或 SSL_MODE_VERIFY_IDENTITY代替。

       

      该--temp-pool移除服务器选项。

       

      的ignore_builtin_innodb系统变量被移除。

       

      服务器不再执行将包含特殊字符的MySQL 5.1之前的数据库名称转换为带有附加#mysql50#前缀的5.1格式的操作。由于不再执行这些转换，因此删除了mysqlcheck的 --fix-db-names和 --fix-table-names选项， 语句的UPGRADE DATA DIRECTORY NAME子句 ALTER DATABASE以及Com_alter_db_upgrade状态变量。

       

      仅支持从一个主要版本升级到另一个主要版本（例如，从5.0升级到5.1，或从5.1升级到5.5），因此将旧的5.0数据库名称转换为当前版本的MySQL几乎不需要。解决方法是，先将MySQL 5.0安装升级到MySQL 5.1，然后再升级到最新版本。

       

      该mysql_install_db的计划已经从MySQL分发中删除。数据目录初始化应通过使用 或 选项调用mysqld来执行 。另外，删除了mysql_install_db使用的 mysqld 选项，并删除 了控制mysql_install_db安装位置的 选项。 --initialize--initialize-insecure--bootstrapINSTALL_SCRIPTDIR CMake

       

      通用分区处理程序已从MySQL服务器中删除。为了支持给定表的分区，用于该表的存储引擎现在必须提供其自己的（“ 本机 ”）分区处理程序。在 --partition和 --skip-partition选项从MySQL服务器删除，分区相关条目中的输出不再显示SHOW PLUGINS或在 INFORMATION_SCHEMA.PLUGINS 表中。

       

      当前有两个MySQL存储引擎提供本机分区支持：InnoDB 和NDB。其中，InnoDBMySQL 8.0 仅 支持。使用任何其他存储引擎在MySQL 8.0中创建分区表的任何尝试都会失败。

       

      升级的后果。 不支持 使用除InnoDB（例如 MyISAM）以外的存储引擎将分区表从MySQL 5.7（或更早版本）直接升级到MySQL 8.0。处理此类表有两种选择：

       

      使用删除表的分区 ALTER TABLE ... REMOVE PARTITIONING。

       

      更改用于表的存储引擎 InnoDB，用 ALTER TABLE ... ENGINE=INNODB。

       

      在InnoDB 将服务器升级到MySQL 8.0之前，必须对每个分区的非表至少执行上述两个操作之一。否则，升级后将无法使用该表。

       

      由于事实会导致使用存储引擎使用分区表而没有分区支持的表创建语句现在失败，并显示错误（ER_CHECK_NOT_IMPLEMENTED），因此必须确保转储文件中的所有语句（例如mysqldump编写的语句）从您希望导入到创建分区表的MySQL 8.0服务器的MySQL的旧版本中，也没有指定MyISAM没有本地分区处理程序的存储引擎 。您可以通过执行以下任一操作来执行此操作：

       

      从CREATE TABLE使用STORAGE ENGINE选项以外的值的语句中删除对分区的所有引用 InnoDB。

       

      将存储引擎指定为 InnoDB，或者InnoDB默认情况下允许 用作表的存储引擎。

       

      有关更多信息，请参见 第23.6.2节“与存储引擎有关的分区限制”。

       

      系统和状态变量信息不再保存在中INFORMATION_SCHEMA。这些表被删除： GLOBAL_VARIABLES， SESSION_VARIABLES， GLOBAL_STATUS， SESSION_STATUS。请改用相应的性能架构表。请参见 第26.12.14节“性能模式系统变量表”和 第26.12.15节“性能模式状态变量表”。另外，show_compatibility_56 系统变量也被删除。它用于过渡时期，在此期间，系统和状态变量信息INFORMATION_SCHEMA表已移至Performance Schema表，并且不再需要。这些状态变量被删除： Slave_heartbeat_period， Slave_last_heartbeat， Slave_received_heartbeats， Slave_retried_transactions， Slave_running。性能架构表中提供了它们提供的信息。请参阅 迁移到性能模式系统和状态变量表。

       

      性能模式setup_timers表已删除，表中的TICK行 也已删除performance_timers。

       

      该libmysqld嵌入式服务器库被删除，连同：

       

      在， ， ，和 选项 mysql_options() MYSQL_OPT_GUESS_CONNECTIONMYSQL_OPT_USE_EMBEDDED_CONNECTIONMYSQL_OPT_USE_REMOTE_CONNECTIONMYSQL_SET_CLIENT_IP

       

      该mysql_config --libmysqld-libs， --embedded-libs和 --embedded选项

       

      该CMake的 WITH_EMBEDDED_SERVER， WITH_EMBEDDED_SHARED_LIBRARY和 INSTALL_SECURE_FILE_PRIV_EMBEDDEDDIR 选项

       

      （未记录）mysql --server-arg选项

       

      该mysqltest --embedded-server， --server-arg和 --server-file选项

       

      该mysqltest_embedded和 mysql_client_test_embedded测试程序

       

      该mysql_plugin移除工具。替代方法包括在服务器启动时使用--plugin-load或 --plugin-load-add选项或在运行时使用该INSTALL PLUGIN语句加载插件。

       

      该的resolveip工具被删除。 可以改用nslookup，host或 dig。

       

      该resolve_stack_dump工具被删除。官方MySQL构建中的堆栈跟踪始终是符号化的，因此无需使用 resolve_stack_dump。

       

      以下服务器错误代码未使用且已删除。专门测试其中任何一个错误的应用程序都应该更新。

       

      ER_BINLOG_READ_EVENT_CHECKSUM_FAILURE

      ER_BINLOG_ROW_RBR_TO_SBR

      ER_BINLOG_ROW_WRONG_TABLE_DEF

      ER_CANT_ACTIVATE_LOG

      ER_CANT_CHANGE_GTID_NEXT_IN_TRANSACTION

      ER_CANT_CREATE_FEDERATED_TABLE

      ER_CANT_CREATE_SROUTINE

      ER_CANT_DELETE_FILE

      ER_CANT_GET_WD

      ER_CANT_SET_GTID_PURGED_WHEN_GTID_MODE_IS_OFF

      ER_CANT_SET_WD

      ER_CANT_WRITE_LOCK_LOG_TABLE

      ER_CREATE_DB_WITH_READ_LOCK

      ER_CYCLIC_REFERENCE

      ER_DB_DROP_DELETE

      ER_DELAYED_NOT_SUPPORTED

      ER_DIFF_GROUPS_PROC

      ER_DISK_FULL

      ER_DROP_DB_WITH_READ_LOCK

      ER_DROP_USER

      ER_DUMP_NOT_IMPLEMENTED

      ER_ERROR_DURING_CHECKPOINT

      ER_ERROR_ON_CLOSE

      ER_EVENTS_DB_ERROR

      ER_EVENT_CANNOT_DELETE

      ER_EVENT_CANT_ALTER

      ER_EVENT_COMPILE_ERROR

      ER_EVENT_DATA_TOO_LONG

      ER_EVENT_DROP_FAILED

      ER_EVENT_MODIFY_QUEUE_ERROR

      ER_EVENT_NEITHER_M_EXPR_NOR_M_AT

      ER_EVENT_OPEN_TABLE_FAILED

      ER_EVENT_STORE_FAILED

      ER_EXEC_STMT_WITH_OPEN_CURSOR

      ER_FAILED_ROUTINE_BREAK_BINLOG

      ER_FLUSH_MASTER_BINLOG_CLOSED

      ER_FORM_NOT_FOUND

      ER_FOUND_GTID_EVENT_WHEN_GTID_MODE_IS_OFF__UNUSED

      ER_FRM_UNKNOWN_TYPE

      ER_GOT_SIGNAL

      ER_GRANT_PLUGIN_USER_EXISTS

      ER_GTID_MODE_REQUIRES_BINLOG

      ER_GTID_NEXT_IS_NOT_IN_GTID_NEXT_LIST

      ER_HASHCHK

      ER_INDEX_REBUILD

      ER_INNODB_NO_FT_USES_PARSER

      ER_LIST_OF_FIELDS_ONLY_IN_HASH_ERROR

      ER_LOAD_DATA_INVALID_COLUMN_UNUSED

      ER_LOGGING_PROHIBIT_CHANGING_OF

      ER_MALFORMED_DEFINER

      ER_MASTER_KEY_ROTATION_ERROR_BY_SE

      ER_NDB_CANT_SWITCH_BINLOG_FORMAT

      ER_NEVER_USED

      ER_NISAMCHK

      ER_NO_CONST_EXPR_IN_RANGE_OR_LIST_ERROR

      ER_NO_FILE_MAPPING

      ER_NO_GROUP_FOR_PROC

      ER_NO_RAID_COMPILED

      ER_NO_SUCH_KEY_VALUE

      ER_NO_SUCH_PARTITION__UNUSED

      ER_OBSOLETE_CANNOT_LOAD_FROM_TABLE

      ER_OBSOLETE_COL_COUNT_DOESNT_MATCH_CORRUPTED

      ER_ORDER_WITH_PROC

      ER_PARTITION_SUBPARTITION_ERROR

      ER_PARTITION_SUBPART_MIX_ERROR

      ER_PART_STATE_ERROR

      ER_PASSWD_LENGTH

      ER_QUERY_ON_MASTER

      ER_RBR_NOT_AVAILABLE

      ER_SKIPPING_LOGGED_TRANSACTION

      ER_SLAVE_CHANNEL_DELETE

      ER_SLAVE_MULTIPLE_CHANNELS_HOST_PORT

      ER_SLAVE_MUST_STOP

      ER_SLAVE_WAS_NOT_RUNNING

      ER_SLAVE_WAS_RUNNING

      ER_SP_GOTO_IN_HNDLR

      ER_SP_PROC_TABLE_CORRUPT

      ER_SQL_MODE_NO_EFFECT

      ER_SR_INVALID_CREATION_CTX

      ER_TABLE_NEEDS_UPG_PART

      ER_TOO_MUCH_AUTO_TIMESTAMP_COLS

      ER_UNEXPECTED_EOF

      ER_UNION_TABLES_IN_DIFFERENT_DIR

      ER_UNSUPPORTED_BY_REPLICATION_THREAD

      ER_UNUSED1

      ER_UNUSED2

      ER_UNUSED3

      ER_UNUSED4

      ER_UNUSED5

      ER_UNUSED6

      ER_VIEW_SELECT_DERIVED_UNUSED

      ER_WRONG_MAGIC

      ER_WSAS_FAILED

      不推荐使用INFORMATION_SCHEMA INNODB_LOCKS，并 INNODB_LOCK_WAITS表将被删除。请改用性能架构 data_locks和 data_lock_waits表。

       

      注意

      在MySQL 5.7中，LOCK_TABLE在列INNODB_LOCKS表和locked_table在列 sys模式 innodb_lock_waits和 x$innodb_lock_waits视图包含组合模式/表名的值。在MySQL 8.0中，data_locks表和 sys架构视图包含单独的架构名称和表名称列。请参见 第27.4.3.9节“ innodb_lock_waits和x $ innodb_lock_waits视图”。

       

      InnoDB不再支持压缩的临时表。当 innodb_strict_mode启用（默认值）， CREATE TEMPORARY TABLE如果返回错误 ROW_FORMAT=COMPRESSED或 KEY_BLOCK_SIZE指定的。如果 innodb_strict_mode禁用此选项，则会发出警告，并使用非压缩的行格式创建临时表。

       

      InnoDB 在MySQL数据目录之外创建表空间数据文件时，不再创建 .isl文件（InnoDB符号链接文件）。该 innodb_directories选项现在支持查找在数据目录外部创建的表空间文件。

       

      通过此更改，.isl不再支持在服务器脱机时通过手动修改文件来移动远程表空间 。该innodb_directories选件现在支持移动远程表空间文件 。请参见第15.6.3.6节“在服务器脱机时移动表空间文件”。

       

      以下InnoDB文件格式变量已删除：

       

      innodb_file_format

       

      innodb_file_format_check

       

      innodb_file_format_max

       

      innodb_large_prefix

       

      文件格式变量对于创建与InnoDBMySQL 5.1 早期版本兼容的表是必需的 。既然MySQL 5.1的产品生命周期已经结束，则不再需要这些选项。

       

      该FILE_FORMAT列已从INNODB_TABLES和 INNODB_TABLESPACES信息模式表中删除。

       

      innodb_support_xa删除了支持在XA事务中支持两阶段提交 的系统变量。InnoDB始终启用对XA事务中的两阶段提交的支持。

       

      对DTrace的支持已删除。

       

      该JSON_APPEND()功能已删除。使用JSON_ARRAY_APPEND() 代替。

       

      InnoDB在MySQL 8.0.13中删除了 对将表分区放置在共享 表空间中的支持。共享表空间包括 InnoDB系统表空间和常规表空间。有关在共享表空间中标识分区并将其移至每个表文件表空间的信息，请参见第2.11.5节“为升级准备安装”。

       

      支持SET 在MySQL 8.0.13中弃用的语句中设置用户变量 。此功能可能会在MySQL 9.0中删除。

       

      该--ndb PERROR移除选项。请改用ndb_perror实用程序。

       

      该innodb_undo_logs变量已删除。这些 innodb_rollback_segments 变量执行相同的功能，应改为使用。

       

      在Innodb_available_undo_logs取出状态变量。每个表空间的可用回滚段数可以使用SHOW VARIABLES LIKE 'innodb_rollback_segments';

       

      从MySQL 8.0.14开始，先前弃用的 innodb_undo_tablespaces 变量不再可配置。有关更多信息，请参见第15.6.3.4节“撤消表空间”。

       

      对该ALTER TABLE ... UPGRADE PARTITIONING语句的支持已删除。

       

      从MySQL 8.0.16开始，internal_tmp_disk_storage_engine 已经删除了对系统变量的支持 。现在，磁盘上的内部临时表始终使用 InnoDB存储引擎。有关更多信息，请参阅 磁盘内部临时表的存储引擎。

       

      该CMake的选择是不使用的，并已被删除。 DISABLE_SHARED

• • • innodb_doublewrite_batch_size

      定义要批量写入的双写页面数。

    有关更多信息，请参见 第15.6.4节“ Doublewrite缓冲区”。

  • MySQL 8.0.20中改进了竞争感知事务调度（CATS）算法，该算法优先考虑等待锁的事务。现在，事务调度权重计算完全在单独的线程中执行，从而提高了计算性能和准确性。

    删除了也用于事务调度的先进先出（FIFO）算法。CATS算法的增强使FIFO算法变得多余。以前由FIFO算法执行的事务调度现在由CATS算法执行。

    TRX_SCHEDULE_WEIGHT在INFORMATION_SCHEMA.INNODB_TRX表中添加了 一个列 ，该列允许查询由CATS算法分配的事务调度权重。

    INNODB_METRICS添加了 以下计数器来监视代码级事务调度事件：

    • lock_rec_release_attempts

      尝试释放记录锁定的次数。

    • lock_rec_grant_attempts

      授予记录锁定的尝试次数。

    • lock_schedule_refreshes

      分析等待图表以更新交易计划权重的次数。

    有关更多信息，请参见 第15.7.6节“事务调度”。

  • 从MySQL 8.0.21开始，为了提高需要访问表和行资源的锁队列的操作的并发性，锁系统互斥锁（lock_sys->mutex）被分片闩锁代替，并且锁队列被分组为表和页锁队列分片，每个分片均受专用互斥保护。以前，单锁系统互斥锁可保护所有锁队列，这是高并发系统上的争论点。新的分片实现允许更精细地访问锁定队列。

    锁系统互斥锁（lock_sys->mutex）被以下分片闩锁代替：

    • 全局闩锁（lock_sys->latches.global_latch），由64个读写锁定对象（rw_lock_t）组成。访问单个锁定队列需要共享的全局闩锁和锁定队列分片上的闩锁。需要访问所有锁定队列的操作采用排他的全局闩锁，该闩锁会闩锁所有表和页面锁定队列分片。

    • 表分片锁存器（lock_sys->latches.table_shards.mutexes），由512个互斥锁组成，每个互斥锁专用于512个表锁定队列分片之一。

    • 页面分片锁存器（lock_sys->latches.page_shards.mutexes），由512个互斥锁组成，每个互斥锁专用于512个页面锁定队列分片之一。

    wait/synch/mutex/innodb/lock_mutex 用于监视单锁系统互斥锁 的Performance Schema 工具已由用于监视新的全局，表分片和页面分片闩锁的工具取代：

    • wait/synch/sxlock/innodb/lock_sys_global_rw_lock

    • wait/synch/mutex/innodb/lock_sys_table_mutex

    • wait/synch/mutex/innodb/lock_sys_page_mutex

• 从MySQL 8.0.21开始，使用DATA DIRECTORY子句在数据目录外部创建的表和表分区数据文件 仅限于已知的目录InnoDB。此更改允许数据库管理员控制在何处创建表空间数据文件，并确保可以在恢复期间找到这些数据文件。

  常规和每表文件表空间数据文件（.ibd文件）不能再在undo表空间目录（innodb_undo_directory）中创建，除非直接已知InnoDB。

  已知的目录那些被定义的 datadir， innodb_data_home_dir和 innodb_directories 变量。

  截断InnoDB驻留在每个表文件表空间中的表将删除现有表空间并创建一个新表空间。从MySQL 8.0.21开始， InnoDB如果当前表空间目录未知，则在默认位置创建新表空间，并向错误日志写入警告。要 TRUNCATE TABLE在当前位置创建表空间，请innodb_directories在运行之前将目录添加到 设置中TRUNCATE TABLE。

• 从MySQL 8.0.21开始，可以使用ALTER INSTANCE {ENABLE|DISABLE} INNODB REDO_LOG语法启用和禁用重做日志记录。此功能旨在将数据加载到新的MySQL实例中。禁用重做日志记录可以避免重做日志写入，从而有助于加快数据加载速度。

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

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

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

• 在启动时，InnoDB如果表空间文件已移动到其他位置，则对照数据字典中存储的表空间文件路径来验证已知表空间文件的路径。innodb_validate_tablespace_paths MySQL 8.0.21中引入的新 变量允许禁用表空间路径验证。此功能适用于不移动表空间文件的环境。禁用表空间路径验证可缩短具有大量表空间文件的系统上的启动时间。

  有关更多信息，请参见 第15.6.3.7节“禁用表空间路径验证”。

• 从MySQL 8.0.21开始，在支持原子DDL的存储引擎上，CREATE TABLE ... SELECT当使用基于行的复制时，该 语句作为一个事务记录在二进制日志中。以前，它被记录为两个事务，一个用于创建表，另一个用于插入数据。通过此更改， CREATE TABLE ... SELECT语句现在可以安全地用于基于行的复制，并且可以与基于GTID的复制一起使用。有关更多信息，请参见 第13.1.1节“原子数据定义语句支持”。

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

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

  为了防止因撤消表空间的截断操作数量过多而导致潜在的问题，现在将检查点之间同一撤消表空间的截断操作限制为64。如果超过了限制，则仍可以使撤消表空间为非活动状态，但不会被截断直到下一个检查点之后。

  INNODB_METRICS与无效撤消的截断刷新操作相关的计数器已删除。删除了计数器包括： undo_truncate_sweep_count， undo_truncate_sweep_usec， undo_truncate_flush_count，和 undo_truncate_flush_usec。

  请参见第15.6.3.4节“撤消表空间”。

• 从MySQL 8.0.22开始，新 innodb_extend_and_initialize变量允许InnoDB在Linux上配置如何为每个表文件空间和常规表空间分配空间。默认情况下，当操作需要表空间中的额外空间时，InnoDB将页面分配给表空间，并以物理方式将NULL写入这些页面。如果频繁分配新页面，此行为会影响性能。您可以innodb_extend_and_initialize在Linux系统上禁用 以避免物理上将NULL写入新分配的表空间页面。当 innodb_extend_and_initialize被禁用，空间使用分配 posix_fallocate() 调用，保留空间而无需实际写入NULL。

  甲posix_fallocate()操作不是原子，这使得它可能用于向表文件分配空间和更新文件元数据之间发生了故障。此类故障可能会使新分配的页面处于未初始化状态，从而导致InnoDB尝试访问这些页面时失败 。为避免这种情况，请InnoDB在分配新的表空间页之前写入重做日志记录。如果页面分配操作被中断，则在恢复期间将从重做日志记录中重播该操作。

• 字符集支持。  默认字符集已从更改 latin1为utf8mb4。该utf8mb4字符集有几个新的排序规则，其中包括 utf8mb4_ja_0900_as_cs，提供对Unicode在MySQL中第一个日本语言特定的排序。有关更多信息，请参见 第10.10.1节“ Unicode字符集”。

• JSON增强。  对MySQL的JSON功能进行了以下增强或添加：

  • 添加了 ->> （内联路径）运算符，等效于调用 JSON_UNQUOTE()的结果JSON_EXTRACT()。

    这是-> 对MySQL 5.7中引入的列路径运算符的改进 ； col->>"$.path"等价于 JSON_UNQUOTE(col->"$.path")。内联路径运算符可以用来随时随地可以使用 JSON_UNQUOTE(JSON_EXTRACT())，如 SELECT列清单， WHERE和HAVING 条款，并ORDER BY和 GROUP BY条款。有关更多信息，请参见运算符的描述以及JSON Path Syntax。

  • 添加了两个JSON聚合函数 JSON_ARRAYAGG()和 JSON_OBJECTAGG()。 JSON_ARRAYAGG()将列或表达式作为其参数，并将结果聚合为单个JSON数组。该表达式可以求值为任何MySQL数据类型；这不一定是一个JSON值。 JSON_OBJECTAGG()接受两列或表达式，将其解释为键和值；它以单个JSON 对象的形式返回结果。有关更多信息和示例，请参见 第12.20节“聚合函数”。

  • 添加了JSON实用程序功能JSON_PRETTY()，该功能 JSON 以易于阅读的格式输出现有值；每个JSON对象成员或数组值都打印在单独的一行上，并且子对象或数组相对于其父对象要有2个空格。

    此函数还可以与可解析为JSON值的字符串一起使用。

    有关更多详细信息和示例，请参见 第12.18.8节“ JSON实用程序函数”。

  • 现在，JSON使用来对查询中的值进行 排序时ORDER BY，每个值现在都由sort键的可变长度部分表示，而不是由固定的1K大小的一部分表示。在许多情况下，这可以减少过多的使用。例如，标量INT或什至 BIGINT值实际上需要很少的字节，因此该空间的其余部分（最多90％或更多）被填充占用了。此更改具有以下性能优势：

    • 现在可以更有效地使用排序缓冲区空间，因此文件排序不需要像固定长度排序键那样早或经常刷新到磁盘。这意味着可以在内存中整理更多数据，避免不必要的磁盘访问。

    • 较短的键可以比较长的键更快地进行比较，从而显着提高了性能。对于完全在内存中执行的排序以及需要写入磁盘和从磁盘读取的排序，都是如此。

  • 在MySQL 8.0.2中添加了对JSON列值的部分就地更新的支持，这比完全删除现有JSON值并在其位置写入一个新的JSON效率更高，就像以前在更新任何JSON列时所做的那样 。要应用这种优化，更新，必须使用应用 JSON_SET()， JSON_REPLACE()或 JSON_REMOVE()。无法将新元素添加到要更新的JSON文档中；文档中的值不能占用比更新前更多的空间。请参阅 JSON值的部分更新，以详细讨论要求。

    可以将JSON文档的部分更新写入二进制日志，比记录完整的JSON文档占用更少的空间。使用基于语句的复制时，始终会记录部分更新。为了使其与基于行的复制一起使用，必须首先设置 binlog_row_value_options=PARTIAL_JSON; 有关更多信息，请参见此变量的说明。

  • 添加了JSON实用程序功能 JSON_STORAGE_SIZE()和 JSON_STORAGE_FREE()。 JSON_STORAGE_SIZE()在进行任何部分更新之前，返回用于JSON文档的二进制表示形式的存储空间（以字节为单位）（请参阅上一项）。 JSON_STORAGE_FREE()显示JSON使用JSON_SET()或 部分更新的类型的表列中剩余的空间量 JSON_REPLACE()。如果新值的二进制表示形式小于先前值的二进制表示形式，则该值大于零。

    这些函数中的每一个还接受JSON文档的有效字符串表示形式。对于此值， JSON_STORAGE_SIZE()返回其二进制表示形式在转换为JSON文档后使用的空间。对于包含JSON文档的字符串表示形式的变量， JSON_STORAGE_FREE()返回零。如果无法将其（非null）参数解析为有效的JSON文档，并且NULL参数为，则 任何一个函数都会产生错误 NULL。

    有关更多信息和示例，请参见 第12.18.8节“ JSON实用程序函数”。

    JSON_STORAGE_SIZE()并 JSON_STORAGE_FREE()在MySQL 8.0.2中实现。

  • 在MySQL 8.0.2中添加了对范围（例如 $[1 to 5]XPath表达式）的支持。在此版本中还增加了对 last关键字和相对寻址的支持，因此$[last]始终选择数组中的最后一个（最高编号）元素以及 $[last-1]最后一个相邻元素。 last使用它的表达式也可以包含在范围定义中。例如， $[last-2 to last-1]返回最后两个元素，但返回数组中的一个。有关其他信息和示例，请参见 搜索和修改JSON值。

  • 添加了旨在符合RFC 7396的JSON合并功能 。 JSON_MERGE_PATCH()，当用于2个JSON对象时，将它们合并为一个具有以下集合的并集的单个JSON对象：

    • 第一个对象的每个成员，在第二个对象中不存在具有相同键的成员。

    • 第二个对象的每个成员，在第一个对象中没有成员具有相同的键，并且其值不是JSON null文字。

    • 每个成员都具有在两个对象中都存在的键，并且其在第二个对象中的值不是JSON null文字。

    作为这项工作的一部分，该 JSON_MERGE()功能已重命名 JSON_MERGE_PRESERVE()。 JSON_MERGE()仍然被认为是JSON_MERGE_PRESERVE()MySQL 8.0 的别名 ，但现在已弃用，并且在将来的MySQL版本中会被删除。

    有关更多信息和示例，请参见 第12.18.4节“修改JSON值的函数”。

  • 实现了重复密钥的 “ 最后重复密钥获胜 ” 规范化，与 RFC 7159和大多数JavaScript解析器一致。此行为的示例在此处显示，其中仅x保留具有密钥的最右边的成员：

    mysql> SELECT JSON_OBJECT('x', '32', 'y', '[true, false]',
         >                     'x', '"abc"', 'x', '100') AS Result;
    +------------------------------------+
    | Result                             |
    +------------------------------------+
    | {"x": "100", "y": "[true, false]"} |
    +------------------------------------+
    1 row in set (0.00 sec)

    插入MySQL JSON列中的值 也以这种方式标准化，如以下示例所示：

    mysql> CREATE TABLE t1 (c1 JSON);
    
    mysql> INSERT INTO t1 VALUES ('{"x": 17, "x": "red", "x": [3, 5, 7]}');
    
    mysql> SELECT c1 FROM t1;
    +------------------+
    | c1               |
    +------------------+
    | {"x": [3, 5, 7]} |
    +------------------+

    与以前的MySQL版本相比，这是一个不兼容的更改，以前的版本 在这种情况下使用了“ 首次重复键赢 ”算法。

    有关更多信息和示例，请参见JSON值的规范化，合并和自动包装。

  • JSON_TABLE() 在MySQL 8.0.4中 添加了该功能。此函数接受JSON数据，并将其作为具有指定列的关系表返回。

    此函数的语法为 ，其中 是返回JSON数据的表达式，是应用于源的JSON路径以及 列定义的列表。这里显示一个示例： JSON_TABLE(expr, path COLUMNS column_list) [AS] alias)exprpathcolumn_list

    mysql> SELECT *
        -> FROM
        ->   JSON_TABLE(
        ->     '[{"a":3,"b":"0"},{"a":"3","b":"1"},{"a":2,"b":1},{"a":0},{"b":[1,2]}]',
        ->     "$[*]" COLUMNS(
        ->       rowid FOR ORDINALITY,
        ->
        ->       xa INT EXISTS PATH "$.a",
        ->       xb INT EXISTS PATH "$.b",
        ->
        ->       sa VARCHAR(100) PATH "$.a",
        ->       sb VARCHAR(100) PATH "$.b",
        ->
        ->       ja JSON PATH "$.a",
        ->       jb JSON PATH "$.b"
        ->     )
        ->   ) AS  jt1;
    +-------+------+------+------+------+------+--------+
    | rowid | xa   | xb   | sa   | sb   | ja   | jb     |
    +-------+------+------+------+------+------+--------+
    |     1 |    1 |    1 | 3    | 0    | 3    | "0"    |
    |     2 |    1 |    1 | 3    | 1    | "3"  | "1"    |
    |     3 |    1 |    1 | 2    | 1    | 2    | 1      |
    |     4 |    1 |    0 | 0    | NULL | 0    | NULL   |
    |     5 |    0 |    1 | NULL | NULL | NULL | [1, 2] |
    +-------+------+------+------+------+------+--------+

    JSON源表达式可以是产生有效JSON文档的任何表达式，包括JSON文字，表列或返回JSON的函数调用，例如JSON_EXTRACT(t1, data, '$.post.comments')。有关更多信息，请参见 第12.18.6节“ JSON表函数”。

• 数据类型支持。  MySQL现在支持使用表达式作为数据类型规范中的默认值。这包括使用表达式作为默认值 BLOB， TEXT， GEOMETRY，和 JSON数据类型，这在以前是根本不会被分配缺省值。有关详细信息，请参见第11.6节“数据类型默认值”。

• 优化器。  添加了这些优化器增强功能：

  • MySQL现在支持不可见索引。优化器根本不使用不可见索引，但否则将正常维护它。默认情况下，索引可见。不可见的索引可以测试删除索引对查询性能的影响，而无需进行破坏性的更改，如果需要该索引，则必须撤消该更改。请参见 第8.3.12节“不可见索引”。

  • MySQL现在支持降序索引： DESC索引定义不再被忽略，而是导致键值以降序存储。以前，可以以相反的顺序扫描索引，但是会降低性能。降序索引可以按向前顺序进行扫描，这样效率更高。当最有效的扫描顺序将某些列的升序与其他列的降序混合时，降序索引还使优化程序可以使用多列索引。请参见第8.3.13节“降序索引”。

  • MySQL现在支持创建索引表达式值而不是列值的功能索引键部分。功能性关键部分支持对无法通过其他方式索引的值（例如JSON值）进行索引 。有关详细信息，请参见第13.1.15节“ CREATE INDEX语句”。

  • 在MySQL 8.0.14和更高版本中，WHERE常量常量表达式引起的琐碎 条件在准备过程中被删除，而不是在优化过程中被删除。在过程的早期删除条件可以简化具有琐碎条件的外部联接的查询的联接，例如：

    SELECT * FROM t1 LEFT JOIN t2 ON condition_1 WHERE condition_2 OR 0 = 1

    现在，优化器在准备过程中会看到0 = 1始终为false，从而使其具有OR 0 = 1 冗余，然后将其删除，从而保持以下状态：

    SELECT * FROM t1 LEFT JOIN t2 ON condition_1 where condition_2

    现在，优化器可以将查询重写为内部联接，如下所示：

    SELECT * FROM t1 LEFT JOIN t2 WHERE condition_1 AND condition_2

    有关更多信息，请参见 第8.2.1.9节“外部联接优化”。

  • 在MySQL 8.0.16和更高版本中，MySQL可以在优化时使用常量折叠来处理列与常量值之间的比较，其中常量超出范围或相对于列的类型在范围边界上，而不是执行因此对于执行时的每一行。例如，给定一个t带有TINYINT UNSIGNED列的表 c，优化器可以重写条件，例如WHERE c < 256to WHERE 1（并完全优化该条件）或 WHERE c >= 255to WHERE c = 255。

    有关更多信息，请参见第8.2.1.14节“恒定折叠优化”。

  • 从MySQL 8.0.16开始，与IN子查询一起使用的半联接优化现在也可以应用于EXISTS子查询。另外，优化器现在WHERE在子查询所附加的条件下对琐碎相关的相等谓词进行解相关 ，以便可以将它们与子查询中的表达式进行类似的处理IN。这适用于EXISTS和 IN子查询。

    有关更多信息，请参见第8.2.2.1节“使用半联接转换优化IN和EXISTS子查询谓词”。

  • 从MySQL 8.0.17开始，服务器会在上下文化 阶段内部在内部重写所有不完整的SQL谓词（即，谓词的形式为 ，其中 是列名或常量表达式，并且不使用比较运算符），以便查询解析程序，查询优化程序和查询执行程序仅需要使用完整的谓词。 WHERE valuevalueWHERE value <> 0

    此更改的明显效果是，对于布尔值，EXPLAIN现在输出显示trueand false，而不是 1and 0。

    此更改的另一个效果是，对SQL布尔上下文中的JSON值求值会对JSON整数0进行隐式比较。考虑如下所示创建和填充的表：

    mysql> CREATE TABLE test (id INT, col JSON);
    
    mysql> INSERT INTO test VALUES (1, '{"val":true}'), (2, '{"val":false}');

    以前，服务器 在SQL布尔上下文中进行比较时，尝试将提取的true或false值转换为 SQL布尔，如以下查询所示 IS TRUE：

    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和更高版本中，提取的值与JSON整数0的隐式copmparison导致不同的结果：

    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        |
    +------+----------------+--------------+

    从MySQL 8.0.21开始，您可以 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         |
    +------+---------------+--------------+

    同样从MySQL 8.0.21开始，服务器提供警告。在SQL布尔上下文中评估JSON值会对JSON整数0进行隐式比较。如果这不是您想要的，则以这种方式在SQL布尔上下文中比较提取的值时，请考虑使用JSON_VALUE RETURNING将JSON转换为SQL数字类型。

  • 在MySQL 8.0.17及更高版本中，WHERE 具有或 的条件在内部转换为反连接。（一个反联接返回表中没有与联接条件相匹配的行的表中的所有行，并且符合联接条件。）这将删除子查询，因为该子查询的表现在在顶部处理，因此可以更快地执行查询。水平。 NOT IN (subquery)NOT EXISTS (subquery)

    这类似于并重用现有的IS NULL（Not exists）外连接优化。请参阅 EXPLAIN Extra Information。

  • 从MySQL 8.0.21开始，单表 UPDATE或 DELETE语句现在可以在许多情况下利用半联接转换或子查询实现。这适用于此处所示形式的语句：

    • UPDATE t1 SET t1.a=value WHERE t1.a IN (SELECT t2.a FROM t2)

    • DELETE FROM t1 WHERE t1.a IN (SELECT t2.a FROM t2)

    可以针对单个表 UPDATE或DELETE 满足以下条件进行此操作：

    • 该UPDATE或 DELETE语句使用具有一个子查询[NOT] IN或 [NOT] EXISTS谓语。

    • 该语句没有ORDER BY 子句，也没有LIMIT子句。

      （的多表版本 UPDATE和 DELETE不支持 ORDER BY或 LIMIT）。

    • 目标表不支持写前读删除（仅与NDB表相关 ）。

    • 基于子查询中包含的任何提示以及的值，允许半联接或子查询实现 optimizer_switch。

    当将半联接优化用于合格的单表DELETE或时 UPDATE，这在优化程序跟踪中可见：对于多表语句join_optimization，跟踪中有一个 对象，而对于单表语句则没有。转换在EXPLAIN FORMAT=TREE或 的输出中也可见 EXPLAIN ANALYZE。单表语句显示<not executable by iterator executor>，而多表语句报告完整计划。

    Alo从MySQL 8.0.21开始，UPDATE 使用InnoDB 表的多表语句支持半一致性读取，因为事务隔离级别比弱 REPEATABLE READ。

• 常用表表达式。  MySQL现在支持非递归和递归的通用表表达式。公用表表达式允许使用命名的临时结果集，通过允许在WITH语句之前的子句SELECT和某些其他语句来实现。有关更多信息，请参见 第13.2.15节“ WITH（公用表表达式）”。

  从MySQL 8.0.19开始，SELECT递归公用表表达式（CTE）的递归 部分支持 LIMIT子句。LIMIT 与OFFSET也支持。有关更多信息，请参见 递归公用表表达式。

• 窗口功能。  MySQL现在支持窗口函数，对于查询中的每一行，都使用与该行相关的行来执行计算。这些包括诸如 RANK()， LAG()，和 NTILE()。此外，现在可以将几个现有的聚合函数用作窗口函数（例如 SUM()和 AVG()）。有关更多信息，请参见第12.21节“窗口函数”。

• 横向派生表。  现在，派生表之前可以带有 LATERAL关键字，以指定允许它引用（取决于）同一FROM子句中先前表的列。横向派生表使某些SQL操作可能无法通过非横向派生表完成，或者需要效率较低的解决方法。请参见 第13.2.11.9节“侧面衍生表”。

• 单表DELETE语句中的别名。  在MySQL 8.0.16和更高版本中，单表 DELETE语句支持使用表别名。

• 正则表达式支持。  此前，MySQL的使用的亨利斯宾塞正则表达式库来支持正则表达式运算符（REGEXP， RLIKE）。使用Unicode国际组件（ICU）重新实现了对正则表达式的支持，该组件提供了完整的Unicode支持并且是多字节安全的。该 REGEXP_LIKE()函数以REGEXP和 RLIKE 运算符的方式执行正则表达式匹配 ，它们现在是该函数的同义词。此外， REGEXP_INSTR()， REGEXP_REPLACE()，和 REGEXP_SUBSTR()函数可用于查找匹配位置并分别执行子字符串替换和提取。该 regexp_stack_limit和 regexp_time_limit系统变量提供由发动机匹配了资源消耗的控制。有关更多信息，请参见 第12.8.2节“正则表达式”。有关实现更改可能影响使用正则表达式的应用程序的方式的信息，请参见 正则表达式兼容性注意事项。

• 内部临时表。  的TempTable存储引擎替换MEMORY存储引擎作为默认发动机用于在内存中的内部临时表。该TempTable存储引擎提供了有效的存储 VARCHAR和 VARBINARY列。的 internal_tmp_mem_storage_engine 会话变量定义了用于在存储器内的临时表的存储引擎。允许的值为 TempTable（默认值）和 MEMORY。该 temptable_max_ram 变量定义TempTable在将数据存储到磁盘之前存储引擎可以使用的最大内存量 。

• 正在记录。  错误记录已重写为使用MySQL组件体系结构。传统的错误日志记录是使用内置组件实现的，而使用系统日志的日志记录则是可加载的组件。此外，还提供了可加载的JSON日志编写器。要控制要启用的日志组件，请使用 log_error_services系统变量。有关更多信息，请参见 第5.4.2节“错误日志”。

• 备用锁。  一种新型的备份锁可以在联机备份期间允许DML，同时防止可能导致快照不一致的操作。LOCK INSTANCE FOR BACKUP 和 UNLOCK INSTANCE语法支持新的备份锁 。该 BACKUP_ADMIN权限才能使用这些语句。

• 复制。  对MySQL复制进行了以下增强：

  • MySQL复制现在支持使用紧凑的二进制格式对JSON文档的部分更新进行二进制日志记录，从而在记录完整的JSON文档时节省了日志空间。当使用基于语句的日志记录时，这种紧凑的日志记录会自动完成，并且可以通过将新的binlog_row_value_options系统变量设置为来启用 PARTIAL_JSON。有关更多信息，请参见JSON值的部分更新以及的描述 binlog_row_value_options。

• 连接管理。  MySQL服务器现在允许专门为管理连接配置TCP / IP端口。这提供了用于普通连接的网络接口上允许的单个管理连接的替代方法，即使 max_connections 已经建立连接也是如此。请参见 第5.1.12.1节“连接接口”。

  MySQL现在提供了对压缩使用的更多控制，以最大程度地减少通过与服务器的连接发送的字节数。以前，给定的连接未压缩或已使用zlib压缩算法。现在，也可以使用该 zstd算法，并选择zstd连接的压缩级别。可以在服务器端以及连接原始端配置允许的压缩算法，以通过客户端程序以及参与源/副本复制或组复制的服务器进行连接。有关更多信息，请参见 第4.2.8节“连接压缩控制”。

• 组态。  在整个MySQL中，主机名的最大允许长度已增加到255个ASCII字符，之前的限制是60个字符。例如，这适用于数据字典中与主机名相关的列， mysql系统架构，性能架构INFORMATION_SCHEMA和 sys；陈述的 MASTER_HOST价值 CHANGE MASTER TO；语句输出中的Host列 SHOW PROCESSLIST；帐户名称中的主机名（例如帐户管理对帐单和 DEFINER属性）；以及与主机名相关的命令选项和系统变量。

  注意事项：

  • 允许的主机名长度增加会影响在主机名列上具有索引的表。例如，mysql系统架构中索引主机名的表现在具有显式 ROW_FORMAT属性， DYNAMIC以容纳更长的索引值。

  • 某些基于文件名的配置设置可能是基于服务器主机名构造的。允许的值受基础操作系统的约束，该操作系统可能不允许文件名足够长以包含255个字符的主机名。这会影响到 general_log_file， log_error， pid_file， relay_log，和 slow_query_log_file 系统变量和相应的选项。如果基于主机名的值对于OS而言太长，则必须提供明确的较短值。

  • 尽管服务器现在支持255个字符的主机名，但使用该--ssl-mode=VERIFY_IDENTITY 选项建立的服务器的连接 受到OpenSSL支持的最大主机名长度的限制。主机名匹配与SSL证书的两个字段有关，其最大长度如下：公用名：最大长度为64；最大名称为64。主题备用名称：根据RFC＃1034的最大长度。

• 插件。  以前，MySQL插件可以用C或C ++编写。插件使用的MySQL头文件现在包含C ++代码，这意味着插件必须使用C ++而不是C编写。

• C API。  MySQL C API现在支持异步功能，用于与MySQL服务器的非阻塞通信。每个功能都是现有同步功能的异步对应项。如果从服务器连接读取或写入服务器连接，则必须等待同步功能。异步功能使应用程序可以检查服务器连接上的工作是否准备就绪。如果不是，应用程序可以执行其他工作，然后再进行检查。请参阅 C API异步接口。

• 演员的其他目标类型。  功能CAST()和 CONVERT()现在支持转换到类型 DOUBLE， FLOAT和 REAL。在MySQL 8.0.17中添加。请参见第12.11节“广播函数和运算符”。

• JSON模式验证。  MySQL 8.0.17添加了两个功能 JSON_SCHEMA_VALID()， JSON_SCHEMA_VALIDATION_REPORT() 用于再次验证JSON文档JSON模式。 JSON_SCHEMA_VALID()如果文档根据模式进行验证，则返回TRUE（1），否则通过FALSE（0）返回。 JSON_SCHEMA_VALIDATION_REPORT()返回一个JSON文档，其中包含有关验证结果的详细信息。以下语句适用于这两个功能：

  • 模式必须符合JSON模式规范的草案4。

  • required 支持属性。

  • $ref 不支持 外部资源和关键字。

  • 支持正则表达式模式；无效模式将被静默忽略。

  有关更多信息和示例，请参见第12.18.7节“ JSON模式验证函数”。

• 多值索引。  从MySQL 8.0.17开始， InnoDB支持创建多值索引，该索引是在JSON存储值数组的列上定义的辅助索引，并且单个数据记录可以具有多个索引记录。这样的索引使用诸如的关键部分定义 CAST(data->'$.zipcode' AS UNSIGNED ARRAY)。MySQL优化程序会自动使用多值索引进行合适的查询，如的输出所示 EXPLAIN。

  作为这项工作的一部分，MySQL添加了一个新功能 JSON_OVERLAPS()和一个MEMBER OF()用于处理JSON文档的新 运算符，此外，还CAST()使用一个新ARRAY关键字扩展了该 功能， 如下表所示：

  • JSON_OVERLAPS()比较两个 JSON文档。如果它们包含任何共同的键值对或数组元素，则该函数返回TRUE（1）; 否则返回FALSE（0）。如果两个值都是标量，则该函数将执行一个简单的相等性测试。如果一个参数是JSON数组，另一个参数是标量，则将标量视为数组元素。因此，可 JSON_OVERLAPS()作为的补充JSON_CONTAINS()。

  • MEMBER OF()测试第一个操作数（标量或JSON文档）是否是作为第二个操作数传递的JSON数组的成员，如果是则返回TRUE（1），否则返回FALSE（0）。不执行操作数的类型转换。

  • CAST(expression AS type ARRAY)允许通过将在JSON文档中找到的JSON数组json_path转换为SQL数组来创建功能索引 。类型说明符仅限于由已经支持的那些CAST()，以除外 BINARY（不支持）。CAST()（和 ARRAY关键字）的这种用法 仅受支持 InnoDB，并且仅用于创建多值索引。

  有关多值索引的详细信息（包括示例），请参阅“ 多值索引”。 第12.18.3节“搜索JSON值的函数”，提供了有关JSON_OVERLAPS()和的 信息MEMBER OF()以及使用示例。

• 提示time_zone。  从MySQL 8.0.17开始， time_zone使用可以提示会话变量 SET_VAR。

• 重做日志归档。  从MySQL 8.0.17开始，InnoDB支持重做日志归档。在执行备份操作时，复制重做日志记录的备份实用程序有时可能无法跟上重做日志生成的步伐，由于这些记录被覆盖，导致丢失重做日志记录。重做日志归档功能通过将重做日志记录顺序写入存档文件来解决此问题。备份实用程序可以根据需要从存档文件复制重做日志记录，从而避免潜在的数据丢失。有关更多信息，请参阅重做日志归档。

• 克隆插件。  从MySQL 8.0.17开始，MySQL提供了一个克隆插件，该插件允许InnoDB在本地或从远程MySQL服务器实例克隆数据。本地克隆操作将克隆的数据存储在运行MySQL实例的同一服务器或节点上。远程克隆操作通过网络将克隆的数据从施主MySQL服务器实例传输到发起克隆操作的接收者服务器或节点。

  克隆插件支持复制。除了克隆数据之外，克隆操作还从供体提取并传输复制坐标，并将其应用于接收者，从而可以使用克隆插件来配置组复制成员和副本。与复制大量事务相比，使用克隆插件进行配置要快得多，效率也更高。还可以将组复制成员配置为使用克隆插件作为替代的恢复方法，以便成员自动选择从种子成员中检索组数据的最有效方法。

  有关更多信息，请参见第5.6.7节“克隆插件”和第18.4.3.2节“克隆分布式恢复”。

• 哈希联接优化。  从MySQL 8.0.18开始，只要联接中的每对表都包含至少一个等联接条件，就使用哈希联接。哈希联接不需要索引，并且在大多数情况下比块嵌套循环算法更有效。可以通过这种方式优化如此处所示的联接：

  SELECT *
      FROM t1
      JOIN t2
          ON t1.c1=t2.c1;
  
  SELECT *
      FROM t1
      JOIN t2
          ON (t1.c1 = t2.c1 AND t1.c2 < t2.c2)
      JOIN t3
          ON (t2.c1 = t3.c1)

  哈希联接还可以用于笛卡尔积-即，未指定联接条件时。

  您可以使用EXPLAIN FORMAT=TREE或查看何时将哈希联接优化用于特定查询 EXPLAIN ANALYZE。（在MySQL 8.0.20及更高版本中，您也可以使用EXPLAIN，省略 FORMAT=TREE。）

  哈希联接可用的内存量受的值限制 join_buffer_size。在磁盘上执行需要更多内存的哈希联接；磁盘上的哈希联接可以使用的磁盘文件数受限制 open_files_limit。

  从MySQL 8.0.19开始，hash_join 不再支持MySQL 8.0.18中引入的优化器开关（hash_join = on仍显示为optimizer_switch值的一部分，但设置不再有效）。该HASH_JOIN和 NO_HASH_JOIN优化提示也不再支持。开关和提示现在都已弃用，并将在将来的MySQL版本中删除。在MySQL 8.0.18及更高版本中，可以使用NO_BNL优化器开关禁用哈希联接 。

  在MySQL 8.0.20及更高版本中，MySQL服务器中不再使用块嵌套循环，并且即使查询中不包含等联接条件，只要以前会使用块嵌套循环，就将使用哈希联接。这适用于内部非等联接，半联接，反联接，左外部联接和右外部联接。T 系统变量的 block_nested_loop标志 以及 optimizer_switchBNLNO_BNL仍然支持优化程序提示，但此后仅控制对哈希联接的使用。此外，内部联接和外部联接（包括半联接和反联接）现在都可以使用批处理密钥访问（BKA），该批处理密钥访问会增量分配联接缓冲内存，这样单个查询就不需要消耗解析所需的大量资源。 。从MySQL 8.0.18开始，仅支持内部联接的BKA。

  MySQL 8.0.20还用迭代器执行器替换了以前版本的MySQL中使用的执行器。这项工作包括为那些尚未优化为半联接的查询替换管理该格式查询的旧索引子查询引擎，以及以相同格式实现的查询，这些查询以前依赖于旧执行程序。 WHERE value IN (SELECT column FROM table WHERE ...)IN

  有关更多信息和示例，请参见 第8.2.1.4节“哈希联接优化”。另请参阅 批处理密钥访问联接。

• EXPLAIN ANALYZE语句。 MySQL 8.0.18中实现了 一种新形式的EXPLAIN 语句，它以处理查询所用的每个迭代器的格式EXPLAIN ANALYZE提供了有关SELECT语句 执行的扩展信息 TREE，并使得可以将估计成本与查询的实际成本进行比较。此信息包括启动成本，总成本，此迭代器返回的行数以及执行的循环数。

  在MySQL 8.0.21和更高版本中，该语句还支持 FORMAT=TREE说明符。 TREE是唯一受支持的格式。

  有关更多信息，请参见使用EXPLAIN ANALYZE获取信息。

• 查询演员表注入。  在8.0.18及更高版本中，MySQL将强制转换操作注入表达式和条件内的查询项树中，在该表达式和条件中，参数的数据类型与预期的数据类型不匹配。这对查询结果或执行速度没有影响，但是使查询的执行等同于符合SQL标准的查询，同时保持了与MySQL早期版本的向后兼容性。

  现在这样的隐式转换的时间类型（之间执行DATE， DATETIME， TIMESTAMP， TIME）和数字类型（SMALLINT， TINYINT， MEDIUMINT， INT/ INTEGER， BIGINT; DECIMAL/ NUMERIC; FLOAT， DOUBLE， REAL， BIT），只要他们正在使用任何标准的数字比较运算符（相较=， >=， >， <， <=， <>/ !=，要么 <=>）。在这种情况下，任何尚未为a的值 DOUBLE都将强制转换为1。现在也可以执行强制转换注入，以比较DATE或 TIME值与 DATETIME值，其中在必要时将参数强制转换 为 DATETIME。

  从MySQL 8.0.21开始，在将字符串类型与其他类型进行比较时，也会执行此类转换。被投字符串类型包括CHAR， VARCHAR， BINARY， VARBINARY， BLOB， TEXT， ENUM，和 SET。将字符串类型的值与数值类型或进行比较时 YEAR，字符串强制转换为 DOUBLE; 如果其他参数的类型不是FLOAT，DOUBLE或者REAL，它也投来 DOUBLE。当将字符串类型与a DATETIME或TIMESTAMP value 进行比较时 ，字符串强制转换为DATETIME; 将字符串类型与比较时DATE，字符串被强制转换为DATE。

  因此能够看到通过查看的输出时石膏注入到一个给定的查询EXPLAIN ANALYZE，EXPLAIN FORMAT=JSON或者，如下所示，EXPLAIN FORMAT=TREE：

  mysql> CREATE TABLE d (dt DATETIME, d DATE, t TIME);
  Query OK, 0 rows affected (0.62 sec)
  
  mysql> CREATE TABLE n (i INT, d DECIMAL, f FLOAT, dc DECIMAL);
  Query OK, 0 rows affected (0.51 sec)
  
  mysql> CREATE TABLE s (c CHAR(25), vc VARCHAR(25),
      ->     bn BINARY(50), vb VARBINARY(50), b BLOB, t TEXT,
      ->     e ENUM('a', 'b', 'c'), se SET('x' ,'y', 'z'));
  Query OK, 0 rows affected (0.50 sec)
  
  mysql> EXPLAIN FORMAT=TREE SELECT * from d JOIN n ON d.dt = n.i\G
  *************************** 1. row ***************************
  EXPLAIN: -> Inner hash join (cast(d.dt as double) = cast(n.i as double))
  (cost=0.70 rows=1)
      -> Table scan on n  (cost=0.35 rows=1)
      -> Hash
          -> Table scan on d  (cost=0.35 rows=1)
  
  mysql> EXPLAIN FORMAT=TREE SELECT * from s JOIN d ON d.dt = s.c\G
  *************************** 1. row ***************************
  EXPLAIN: -> Inner hash join (d.dt = cast(s.c as datetime(6)))  (cost=0.72 rows=1)
      -> Table scan on d  (cost=0.37 rows=1)
      -> Hash
          -> Table scan on s  (cost=0.35 rows=1)
  
  1 row in set (0.01 sec)
  
  mysql> EXPLAIN FORMAT=TREE SELECT * from n JOIN s ON n.d = s.c\G
  *************************** 1. row ***************************
  EXPLAIN: -> Inner hash join (cast(n.d as double) = cast(s.c as double))  (cost=0.70 rows=1)
      -> Table scan on s  (cost=0.35 rows=1)
      -> Hash
          -> Table scan on n  (cost=0.35 rows=1)
  
  1 row in set (0.00 sec)

  也可以通过执行看到这种强制类型转换EXPLAIN [FORMAT=TRADITIONAL]，在这种情况下，也有必要SHOW WARNINGS在执行EXPLAIN语句后 发出。

• TIMESTAMP和DATETIME的时区支持。  从MySQL 8.0.19开始，服务器接受带有插入的datetime（TIMESTAMP和 DATETIME）值的时区偏移量。该偏移量使用与设置time_zone系统变量时使用的格式相同的格式，不同之处在于，当偏移量的小时部分小于10且'-00:00'不允许时，前导零是必需的 。日期时间文字，其中包括时区偏移的例子是 '2019-12-11 10:40:30-05:00'， '2003-04-14 03:30:00+10:00'和 '2020-01-01 15:35:45+05:30'。

  选择日期时间值时不显示时区偏移量。

  包含时区偏移量的Datetime文字可用作准备好的语句参数值。

  作为这项工作的一部分，用于设置 time_zone系统变量的值现在也被限制 -14:00为+14:00，包括在内。（它仍然可以分配名称值以 time_zone诸如 'EST'， 'Posix/Australia/Brisbane'和 'Europe/Stockholm'该变量，条件是MySQL的时区表被加载;另见 填充的时区表）。

  有关更多信息和示例，请参见 第5.1.14节“ MySQL服务器时区支持”以及 第11.2.2节“ DATE，DATETIME和TIMESTAMP类型”。

• JSON模式检查约束失败的准确信息。  当 JSON_SCHEMA_VALID()用于指定CHECK约束时，MySQL 8.0.19和更高版本提供有关此类约束失败原因的准确信息。

  有关示例和更多信息，请参见 JSON_SCHEMA_VALID（）和CHECK约束。另请参见第13.1.20.6节“检查约束”。

• 行和列别名带有ON DUPLICATE KEY UPDATE。  从MySQL 8.0.19开始，可以使用别名引用要插入的行，以及（可选）引用其列。考虑在具有列 和INSERT的表t上的以下 语句 ： ab

  INSERT INTO t SET a=9,b=5
      ON DUPLICATE KEY UPDATE a=VALUES(a)+VALUES(b);

  使用new新行的别名，在某些情况下，使用别名m以及 n该行的列，INSERT可以用许多不同的方式重写该 语句，此处显示了一些示例：

  INSERT INTO t SET a=9,b=5 AS new
      ON DUPLICATE KEY UPDATE a=new.a+new.b;
  
  INSERT INTO t VALUES(9,5) AS new
      ON DUPLICATE KEY UPDATE a=new.a+new.b;
  
  INSERT INTO t SET a=9,b=5 AS new(m,n)
      ON DUPLICATE KEY UPDATE a=m+n;
  
  INSERT INTO t VALUES(9,5) AS new(m,n)
      ON DUPLICATE KEY UPDATE a=m+n;

  欲了解更多信息和示例，请参见 第13.2.6.2，“INSERT ... ON DUPLICATE KEY UPDATE语句”。

• SQL标准的显式表子句和表值构造函数。  根据SQL标准添加了表值构造函数和显式表子句。这些分别在MySQL 8.0.19中作为 TABLE语句和 VALUES语句实现。

  该TABLE语句具有格式，并且等效于。它支持 和 子句（后者带有optional ），但不允许选择单个表列。 可以在您使用等效 语句的任何地方使用；这包括连接，联合， ，， 语句和子查询。例如： TABLE table_nameSELECT * FROM table_nameORDER BYLIMITOFFSETTABLESELECTINSERT ... SELECTREPLACECREATE TABLE ... SELECT

  • TABLE t1 UNION TABLE t2 相当于 SELECT * FROM t1 UNION SELECT * FROM t2

  • CREATE TABLE t2 TABLE t1 相当于 CREATE TABLE t2 SELECT * FROM t1

  • SELECT a FROM t1 WHERE b > ANY (TABLE t2)等价于SELECT a FROM t1 WHERE b > ANY (SELECT * FROM t2)。

  VALUES可用于一个表值提供给一个INSERT， REPLACE或 SELECT语句，和由的VALUES关键字随后进行了一系列行构造（的ROW()）由逗号分隔。例如，该语句 INSERT INTO t1 VALUES ROW(1,2,3), ROW(4,5,6), ROW(7,8,9)提供与SQL兼容的等效于MySQL特定的INSERT INTO t1 VALUES (1,2,3), (4,5,6), (7,8,9)。您还可以像选择VALUES表一样从表值构造函数中进行选择 ，请记住，这样做时必须提供表别名，并像使用SELECT其他别名一样使用它 。这包括联接，联合和子查询。

  有关详细信息TABLE，并 VALUES和其使用的示例，请参阅本文档的以下部分：

  • 第13.2.12节“ TABLE语句”

  • 第13.2.14节“ VALUES语句”

  • 第13.1.20.4节“ CREATE TABLE ... SELECT语句”

  • 第13.2.6.1节“ INSERT ... SELECT语句”

  • 第13.2.10.2节“ JOIN子句”

  • 第13.2.11节“子查询”

  • 第13.2.10.3节“ UNION子句”

• FORCE INDEX，IGNORE INDEX的优化程序提示。  MySQL 8.0引入了索引级优化器提示，这些提示与第8.9.4节“索引提示”中所述的传统索引提示类似。新的提示这里列出，与他们一起FORCE INDEX或IGNORE INDEX 等价物：

  • GROUP_INDEX： 相当于 FORCE INDEX FOR GROUP BY

    NO_GROUP_INDEX： 相当于 IGNORE INDEX FOR GROUP BY

  • JOIN_INDEX： 相当于 FORCE INDEX FOR JOIN

    NO_JOIN_INDEX： 相当于 IGNORE INDEX FOR JOIN

  • ORDER_INDEX： 相当于 FORCE INDEX FOR ORDER BY

    NO_ORDER_INDEX： 相当于 IGNORE INDEX FOR ORDER BY

  • INDEX：与GROUP_INDEX加 JOIN_INDEX号 相同 ORDER_INDEX; 等效于FORCE INDEX没有修饰符

    NO_INDEX：与NO_GROUP_INDEX加 NO_JOIN_INDEX号 相同 NO_ORDER_INDEX; 等效于IGNORE INDEX没有修饰符

  例如，以下两个查询是等效的：

  SELECT a FROM t1 FORCE INDEX (i_a) FOR JOIN WHERE a=1 AND b=2;
  
  SELECT /*+ JOIN_INDEX(t1 i_a) */ a FROM t1 WHERE a=1 AND b=2;

  前面列出的优化器提示在语法和用法上与现有索引级优化器提示遵循相同的基本规则。

  这些优化器提示旨在替换FORCE INDEX和IGNORE INDEX，我们计划在将来的MySQL版本中弃用和，然后从MySQL中删除。他们没有实现的一个完全等同的形式USE INDEX；相反，你可以使用一个或多个 NO_INDEX， NO_JOIN_INDEX， NO_GROUP_INDEX，或 NO_ORDER_INDEX达到同样的效果。

  有关更多信息和使用示例，请参见“ 索引级优化器提示”。

• JSON_VALUE（）函数。  MySQL 8.0.21实现了一个JSON_VALUE()旨在简化JSON 列索引的新功能 。在最基本的形式中，它以JSON文档和指向该文档中单个值的JSON路径作为参数，并且（可选）允许您使用RETURNING关键字指定返回类型 。 等效于此： JSON_VALUE(json_doc, path RETURNING type)

  CAST(
      JSON_UNQUOTE( JSON_EXTRACT(json_doc, path) )
      AS type
  );

  您还可以指定ON EMPTY， ON ERROR或两个子句，与一起使用 JSON_TABLE()。

  您可以使用JSON_VALUE()在这样的JSON列上的表达式上创建索引：

  CREATE TABLE t1(
      j JSON,
      INDEX i1 ( (JSON_VALUE(j, '$.id' RETURNING UNSIGNED)) )
  );
  
  INSERT INTO t1 VALUES ROW('{"id": "123", "name": "shoes", "price": "49.95"}');

  使用此表达式的查询（例如此处所示）可以使用索引：

  SELECT name, price FROM t1
      WHERE JSON_VALUE(j, '$.id' RETURNING UNSIGNED) = 123;

  在许多情况下，这比从该JSON列创建一个生成的列然后在生成的列上创建索引要简单得多。

  有关更多信息和示例，请参见的描述 JSON_VALUE()。

• 用户评论和用户属性。  MySQL 8.0.21引入了在创建或更新用户帐户时设置用户注释和用户属性的功能。用户注释包括作为参数传递COMMENT给与CREATE USERor ALTER USER语句一起使用的子句的任意文本。用户属性由JSON对象形式的数据组成，该数据作为参数传递给与ATTRIBUTE这两个语句之一一起使用的 子句。该属性可以包含JSON对象表示法中的任何有效键值对。仅一个 COMMENT或ATTRIBUTE 可以在单一使用CREATE USER或 ALTER USER 声明。

  用户注释和用户属性在内部作为JSON对象存储在一起，注释文本作为元素的值comment作为其键。可以从 表的ATTRIBUTE列中 检索此信息 INFORMATION_SCHEMA.USER_ATTRIBUTES。因为它是JSON格式，所以您可以使用MySQL的JSON函数和运算符来解析其内容（请参见 第12.18节“ JSON函数”）。与使用JSON_MERGE_PATCH() 函数时一样，对用户属性的连续更改将与其当前值合并。

  例：

  mysql> CREATE USER 'mary'@'localhost' COMMENT 'This is Mary Smith\'s account';
  Query OK, 0 rows affected (0.33 sec)
  
  mysql> ALTER USER 'mary'@'localhost'
      -≫     ATTRIBUTE '{"fname":"Mary", "lname":"Smith"}';
  Query OK, 0 rows affected (0.14 sec)
  
  mysql> ALTER USER 'mary'@'localhost'
      -≫     ATTRIBUTE '{"email":"mary.smith@example.com"}';
  Query OK, 0 rows affected (0.12 sec)
  
  mysql> SELECT
      ->    USER,
      ->    HOST,
      ->    ATTRIBUTE->>"$.fname" AS 'First Name',
      ->    ATTRIBUTE->>"$.lname" AS 'Last Name',
      ->    ATTRIBUTE->>"$.email" AS 'Email',
      ->    ATTRIBUTE->>"$.comment" AS 'Comment'
      -> FROM INFORMATION_SCHEMA.USER_ATTRIBUTES
      -> WHERE USER='mary' AND HOST='localhost'\G
  *************************** 1. row ***************************
        USER: mary
        HOST: localhost
  First Name: Mary
   Last Name: Smith
       Email: mary.smith@example.com
     Comment: This is Mary Smith's account
  1 row in set (0.00 sec)

  有关更多信息和示例，请参见 第13.7.1.3节“ CREATE USER语句”，第13.7.1.1节“ ALTER USER语句”和 第25.46节“ INFORMATION_SCHEMA USER_ATTRIBUTES表”。

• 新的optimizer_switch标志。  MySQL 8.0.21为optimizer_switch系统变量添加了两个新标志， 如下表所示：

  • prefer_ordering_index 旗

    默认情况下， 只要优化器确定这将导致更快的执行速度，MySQL就会尝试对具有子句的任何查询ORDER BY或GROUP BY查询使用有序索引LIMIT。由于在某些情况下为此类查询选择其他优化效果实际上可能会更好，因此现在可以通过将prefer_ordering_index标志 设置为来禁用此优化 off。

    此标志的默认值为 on。

  • subquery_to_derived 旗

    当此标志设置on为时，优化程序将合格的标量子查询转换为派生表上的联接。例如，查询 SELECT * FROM t1 WHERE t1.a > (SELECT COUNT(a) FROM t2)被重写为 SELECT t1.a FROM t1 JOIN ( SELECT COUNT(t2.a) AS c FROM t2 ) AS d WHERE t1.a > d.c。

    这种优化可以应用到子查询其是的一部分SELECT， WHERE，JOIN，或 HAVING条款; 包含一个或多个聚合函数，但没有GROUP BY 子句；不相关 并且不使用任何不确定的函数。

    优化也可应用于表子查询这对参数IN， NOT IN，EXISTS，或 NOT EXISTS，并且其不包含GROUP BY。例如，查询SELECT * FROM t1 WHERE t1.b < 0 OR t1.a IN (SELECT t2.a + 1 FROM t2)被重写为SELECT a, b FROM t1 LEFT JOIN (SELECT DISTINCT 1 AS e1, t2.a AS e2 FROM t2) d ON t1.a + 1 = d.e2 WHERE t1.b < 0 OR d.e1 IS NOT NULL。

    通常禁用此优化，因为在大多数情况下它不会产生明显的性能优势，因此off默认情况下将标志设置为。

  有关更多信息，请参见 第8.9.2节“可切换的优化”。另请参见 第8.2.1.19节“ LIMIT查询优化”， 第8.2.2.1节“使用半联接转换优化IN和EXISTS子查询谓词”和 第8.2.2.4节“通过合并优化派生表，视图引用和公用表表达式”或物化”。

• XML增强功能。  从MySQL 8.0.21开始，该LOAD XML语句现在支持 CDATA要导入的XML中的部分。

• 现在支持转换为YEAR类型。  从MySQL 8.0.22开始，服务器允许强制转换为 YEAR。无论是 CAST()与 CONVERT()功能支持单位，两位数字，和四位 YEAR值。对于一位和两位数的值，允许的范围是0-99。四位数的值必须在1901-2155范围内。 YEAR也可以用作JSON_VALUE() 函数的返回类型；此功能仅支持四位数的年份。

  字符串，时间和日期以及浮点值都可以转换为YEAR。不支持将GEOMETRY值 强制转换为 YEAR。

  有关更多信息，包括转换规则，请参见CONVERT() 功能说明。

• 将TIMESTAMP值检索为UTC。  MySQL 8.0.22和更高版本支持在检索时使用，将 TIMESTAMP列值从系统时区转换为UTC ，其中指定符是 或之一 。如果需要，可以将转换类型返回的值的精度 指定为最多6个小数位。此结构不支持该 关键字。 DATETIMECAST(value AT TIME ZONE specifier AS DATETIME)[INTERVAL] '+00:00''UTC'DATETIMEARRAY

  TIMESTAMP还支持使用时区偏移量插入表中的值。使用 AT TIME ZONE不支持 CONVERT()或任何其他MySQL功能或结构。

  有关更多信息和示例，请参见CAST()功能说明。

• 转储文件输出同步。  当通过SELECT INTO DUMPFILE和SELECT INTO OUTFILE语句写入文件时，MySQL 8.0.22和更高版本支持定期同步 。可以通过将select_into_disk_sync 系统变量设置为ON; 来启用 。写缓冲区的大小由为设置的值确定 select_into_buffer_size; 默认值为131072（2 ¹⁷）字节。

  另外，可以使用设置与磁盘同步后的可选延迟 select_into_disk_sync_delay。默认值为无延迟（0毫秒）。

  有关更多信息，请参阅此项目之前引用的变量说明。

• 单一准备报表。  从MySQL 8.0.22开始，一个prepared语句只准备一次，而不是每次执行一次。这是在执行时完成的 PREPARE。对于存储过程中的任何语句也是如此。第一次执行存储过程时，该语句仅准备一次。

  更改的结果是，解决准备好的语句中使用的动态参数的方式也以以下方式更改：

  • 在执行形式的预备语句时 ， 为参数传递整数值不再导致 选择列表中^第th个表达式对结果进行排序 ；结果不再像预期的那样排序。 SELECT expr1, expr2, ... FROM table ORDER BY ?NNORDER BY constant

  • 在准备好的语句中不再接受以下窗口函数：

    • NTILE(NULL)

    • NTH_VALUE(expr, NULL)

    • LEAD(expr, nn)和 ，其中 是负数 LAG(expr, nn)nn

    这有助于更好地符合SQL标准。

  • 现在，在准备好的语句中引用的用户变量具有在准备语句时确定其数据类型的功能。该类型在每次后续执行语句时都会保留。

  • 现在，由存储过程中发生的语句引用的用户变量具有在首次执行该语句时确定的数据类型；对于包含存储过程的任何后续调用，该类型都会保留。

  仅将一次语句用作预备语句或在存储过程中使用，可以提高语句的性能，因为这样可以避免重复准备的额外费用。这样做还避免了准备结构的可能的多个回滚，这是MySQL中众多问题的根源。

  另外，作为这项工作的一部分，已经作了修改如何每个窗口的功能 LAG()， LEAD()以及 NTILE()处理其第一个参数。有关详细信息，请参见功能说明。

• RIGHT JOIN作为LEFT JOIN处理。  从MySQL 8.0.22开始，服务器将RIGHT JOIN内部的所有实例处理 为LEFT JOIN，从而消除了许多特殊情况，在这些特殊情况下，解析时未执行完整的转换。

• 派生条件下推优化。  MySQL 8.0.22（及更高版本）为具有实体化派生表的查询实现派生条件下推。对于诸如之类的查询，现在可以在许多情况下将外部 条件下推到派生表，在这种情况下结果为。 SELECT * FROM (SELECT i, j FROM t1) AS dt WHERE i > constantWHERESELECT * FROM (SELECT i, j FROM t1 WHERE i > constant) AS dt

  以前，如果派生表已实现且未合并，则MySQL实现整个表，然后使用WHERE条件限定行。WHERE使用派生条件下推优化将条件移入子查询通常可以减少必须处理的行数，这可以减少执行查询所需的时间。

  WHERE当派生表不使用任何聚合或窗口函数时，可以将 外部条件直接下推到物化派生表。当派生表具有a GROUP BY并且不使用任何窗口函数时，WHERE可以将外部条件作为HAVING 条件下推到派生表。WHERE当派生表使用窗口函数并且WHERE窗口函数的PARTITION子句中使用外部引用列 时，也可以向下推该条件。

  默认情况下，派生条件下推处于启用状态，如 optimizer_switch系统变量的 derived_condition_pushdown标志所示。MySQL 8.0.22中添加的标志on 默认设置为；要禁用特定查询的优化，可以使用 NO_DERIVED_CONDITION_PUSHDOWN 优化器提示（也在MySQL 8.0.22中添加）。如果优化是禁用的，由于 derived_condition_pushdown设定为 off，您可以启用它使用给定的查询 DERIVED_CONDITION_PUSHDOWN。

  派生条件下推优化不能用于包含UNIONor LIMIT子句的派生表 。此外，本身使用子查询的条件不能被下推，并且 WHERE条件不能被下推到也是外部联接的内部表的派生表。有关更多信息和示例，请参见 第8.2.2.5节“派生条件下推优化”。

• 对MySQL授权表的非锁定读取。  从MySQL 8.0.22开始，为了允许在MySQL授权表上进行并发DML和DDL操作，以前在MySQL授权表上获得行锁的读取操作将作为非锁定读取执行。

  现在，作为对MySQL授权表的非锁定读取而执行的操作包括：

  • SELECT语句和其他只读SELECT ... FOR SHARE语句，它们使用任何事务隔离级别通过联接列表和子查询（包括语句）从授予表中读取数据 。

  • DML操作使用任何事务隔离级别从授权表中读取数据（通过联接列表或子查询），但不修改它们。

MySQL 8.0中不推荐使用的功能

以下功能在MySQL 8.0中已弃用，并且可能在以后的系列中被删除或将被删除。在显示替代方案的地方，应更新应用程序以使用它们。

对于使用在更高版本的MySQL系列中已删除的MySQL 8.0中不推荐使用的功能的应用程序，将语句从MySQL 8.0源复制到更高版本的副本时，语句可能会失败，或者可能对源和副本产生不同的影响。为避免此类问题，应修改使用8.0中不推荐使用的功能的应用程序，以避免出现这种情况，并在可能的情况下使用替代方法。

• 该utf8mb3字符集已被弃用。请utf8mb4改用。

• 因为它caching_sha2_password是MySQL 8.0中的默认身份验证插件，并且提供了该sha256_password身份验证插件的功能的超集 ， sha256_password所以已弃用，并将在以后的MySQL版本中将其删除。使用sha256_password进行身份验证的MySQL帐户应迁移为使用caching_sha2_password 。

• 该validate_password插件已被重新实现以使用服务器组件基础结构。的插件形式validate_password仍然可用，但已过时，并将在MySQL的未来版本中删除。使用插件的MySQL安装应过渡到使用组件。请参见 第6.4.3.3节“过渡到密码验证组件”。

• 和 语句 的ENGINE子句 已弃用。 ALTER TABLESPACEDROP TABLESPACE

• 在 PAD_CHAR_TO_FULL_LENGTH SQL模式已经过时了。

• AUTO_INCREMENT不支持type FLOAT和 DOUBLE（以及任何同义词）的列。考虑AUTO_INCREMENT 从此类列中删除属性，或将其转换为整数类型。

• 的UNSIGNED属性被弃用类型的列FLOAT， DOUBLE和 DECIMAL（和任何同义词）。考虑CHECK对此类列使用简单约束。

• FLOAT(M,D) 和 语法指定的位数类型的列的数目 和 （和任何同义词）是一个非标准MySQL扩展。不建议使用此语法。 DOUBLE(M,D)FLOATDOUBLE

• ZEROFILL对于数字数据类型，不建议使用 该属性，对于整数数据类型，则不建议使用显示宽度属性。考虑使用替代方法来产生这些属性的效果。例如，应用程序可以使用该 LPAD()功能将数字零填充到所需宽度，或者可以将格式化的数字存储在CHAR 列中。

• 对于字符串数据类型，该BINARY 属性是非标准的MySQL扩展，它是用于指定_bin列字符集（或未指定列字符集的表默认字符集）的二进制（）归类的简写形式。在MySQL 8.0中，这种非标准用法 BINARY是不明确的，因为 utf8mb4字符集具有多个 _bin排序规则，因此BINARY不赞成使用该属性，并且在将来的MySQL版本中将删除对该 属性的支持。应将应用程序调整为使用显式 _bin排序规则。

  BINARY用于指定数据类型或字符集 的用法保持不变。

• 非标准C风格 &&， ||和 !运营商认为是标准的SQL同义词 AND， OR和 NOT运营商，分别已被取消。使用非标准运算符的应用程序应调整为使用标准运算符。

  注意

  使用的||，除非被弃用 PIPES_AS_CONCAT启用SQL模式。在这种情况下，||表示SQL标准字符串串联运算符。

• 该JSON_MERGE()功能已弃用。使用 JSON_MERGE_PRESERVE() 代替。

• 不建议使用SQL_CALC_FOUND_ROWS查询修饰符和附带FOUND_ROWS() 功能。有关FOUND_ROWS()替代策略的信息，请参见 说明。

• 从MySQL 8.0.13开始，不 支持TABLESPACE = innodb_file_per_tableand TABLESPACE = innodb_temporary子句 CREATE TEMPORARY TABLE。

• 对于SELECT报表，使用的INTO条款之后， FROM而不是在的结尾 SELECT被弃用的MySQL 8.0.20的。最好将放在 INTO语句的末尾。

  对于UNION语句，INTO自MySQL 8.0.20起已弃用了这两个变体：

  • 在查询表达式的结尾查询块中，使用INTObefore FROM。

  • 在查询表达式的带括号的尾随块中，请使用INTO，而无论其相对于的位置FROM。

  请参见第13.2.10.1节“ SELECT ... INTO语句”和 第13.2.10.3节“ UNION子句”。

• 该mysql_upgrade客户端已被弃用，因为它的功能升级的系统表mysql系统架构和对象在其他模式已移动到MySQL服务器。请参见 第2.11.3节“ MySQL升级过程将升级什么”。

• 该--no-dd-upgrade服务器选项已被弃用。该--upgrade选件取代了该 选件，该选件可以更好地控制数据字典和服务器升级行为。

• 该mysql_upgrade_info文件（已创建数据目录并用于存储MySQL版本号）已被弃用，并将在以后的MySQL版本中删除。

• 不建议使用relay_log_info_file系统变量和--master-info-file选项。以前，这些被用来当指定中继日志信息记录和源信息日志的名称 relay_log_info_repository=FILE ，并 master_info_repository=FILE 分别设置，但这些设置已被弃用。崩溃安全副本表已取代了用于中继日志信息日志和源信息日志的文件，这是MySQL 8.0中的默认设置。

• max_length_for_sort_data 由于优化器的更改， 该变量已过时且无效，现在已弃用该 系统变量。

• 不建议使用这些旧参数来压缩与服务器的连接： --compress客户端命令行选项；C API函数的 MYSQL_OPT_COMPRESS选项 mysql_options()；该 slave_compressed_protocol 系统变量。有关替代使用的参数的信息，请参见 第4.2.8节“连接压缩控制”。

• 不建议使用MYSQL_PWD环境变量来指定MySQL密码。

• 从MySQL 8.0.20开始，不赞成 使用VALUES()来访问中的新行值 INSERT ... ON DUPLICATE KEY UPDATE。请为新的行和列使用别名。

• 因为ON ERROR在ON EMPTY调用时指定before 违反 JSON_TABLE()了SQL标准，所以现在在MySQL中不推荐使用此语法。从MySQL 8.0.20开始，只要您尝试这样做，服务器就会打印警告。在单个JSON_TABLE() 调用中指定这两个子句时，请确保ON EMPTY首先使用该子句。

• 从未将具有索引前缀的列作为表分区键的一部分来支持。以前，在创建，更改或升级分区表时允许使用这些表，但表的分区功能将其排除在外，服务器也不会发出警告，表明已发生这种情况。现在已弃用这种允许的行为，并且会在将来的MySQL版本中删除该行为，在该版本的MySQL中，在分区键中使用任何此类列将导致拒绝CREATE TABLEor ALTER TABLE语句。

  从MySQL 8.0.21开始，只要将使用索引前缀的列指定为分区键的一部分，就会为每个此类列生成警告。每当 CREATE TABLEor ALTER TABLE语句由于提议的分区键中的所有列都具有索引前缀而被拒绝时，所产生的错误现在将提供拒绝的确切原因。在这两种情况下，都包括通过使用空PARTITION BY KEY()子句将分区函数中使用的列隐式定义为表的主键中的列的情况 。

  有关更多信息和示例，请参阅 键分区不支持的列索引前缀。

• 从MySQL 8.0.22开始不推荐使用InnoDB memcached插件，并且在将来的MySQL版本中将不再支持它。

MySQL 8.0中删除的功能

以下各项已过时，并且已在MySQL 8.0中删除。在显示替代方案的地方，应更新应用程序以使用它们。

对于使用MySQL 8.0中已删除功能的MySQL 5.7应用程序，将语句从MySQL 5.7源复制到MySQL 8.0副本时，语句可能会失败，或对源和副本产生不同的影响。为避免此类问题，应修改使用MySQL 8.0中删除的功能的应用程序以避免这些问题，并在可能的情况下使用替代方法。

• 在innodb_locks_unsafe_for_binlog除去系统变量。该READ COMMITTED隔离级别提供了类似的功能。

• information_schema_statsMySQL 8.0.0中引入 的变量已被删除，并information_schema_stats_expiry 在MySQL 8.0.3中被替换 。

  information_schema_stats_expiry定义缓存INFORMATION_SCHEMA表统计信息的到期设置 。有关更多信息，请参见 第8.2.3节“优化INFORMATION_SCHEMA查询”。

• 与已过时的InnoDB系统表相关的代码已在MySQL 8.0.3中删除。 INFORMATION_SCHEMA基于InnoDB系统表的视图被数据字典表上的内部系统视图替换。受影响的 InnoDB INFORMATION_SCHEMA视图已重命名：

  表1.1重命名的InnoDB信息架构视图

  旧名称	新名字
  INNODB_SYS_COLUMNS	INNODB_COLUMNS
  INNODB_SYS_DATAFILES	INNODB_DATAFILES
  INNODB_SYS_FIELDS	INNODB_FIELDS
  INNODB_SYS_FOREIGN	INNODB_FOREIGN
  INNODB_SYS_FOREIGN_COLS	INNODB_FOREIGN_COLS
  INNODB_SYS_INDEXES	INNODB_INDEXES
  INNODB_SYS_TABLES	INNODB_TABLES
  INNODB_SYS_TABLESPACES	INNODB_TABLESPACES
  INNODB_SYS_TABLESTATS	INNODB_TABLESTATS
  INNODB_SYS_VIRTUAL	INNODB_VIRTUAL

   
  

  升级到MySQL 8.0.3或更高版本后，请更新所有引用先前InnoDB INFORMATION_SCHEMA视图名称的脚本。

• 与帐户管理相关的以下功能已删除：

  • 使用GRANT创建用户。而是使用CREATE USER。遵循这种做法会使 NO_AUTO_CREATE_USERSQL模式对GRANT 语句不重要，因此也将其删除，并且当sql_mode选项文件中选项的此值的存在阻止mysqld启动时，现在会将错误写入服务器日志。

  • 使用GRANT修改不是权限指派其他帐户属性。这包括身份验证，SSL和资源限制属性。而是在创建帐户时使用CREATE USER或在之后使用修改这些 属性ALTER USER。

  • IDENTIFIED BY PASSWORD 'auth_string'CREATE USER 和的 语法GRANT。而是使用 for 和 ，其中 值的格式与命名插件兼容。 IDENTIFIED WITH auth_plugin AS 'auth_string'CREATE USERALTER USER'auth_string'

    此外，由于IDENTIFIED BY PASSWORD删除了语法，因此 log_builtin_as_identified_by_password 系统变量是多余的，因此已删除。

  • 该PASSWORD()功能。此外，PASSWORD()删除意味着 语法不再可用。 SET PASSWORD ... = PASSWORD('auth_string')

  • 该old_passwords系统变量。

• 查询缓存已删除。删除包括以下项目：

  • 该FLUSH QUERY CACHE和 RESET QUERY CACHE语句。

  • 这些系统变量： query_cache_limit， query_cache_min_res_unit， query_cache_size， query_cache_type， query_cache_wlock_invalidate。

  • 这些状态变量： Qcache_free_blocks， Qcache_free_memory， Qcache_hits， Qcache_inserts， Qcache_lowmem_prunes， Qcache_not_cached， Qcache_queries_in_cache， Qcache_total_blocks。

  • 这些线程状态：checking privileges on cached query，checking query cache for query，invalidating query cache entries，sending cached result to client，storing result in query cache，Waiting for query cache lock。

  • 该SQL_CACHE SELECT修改。

  这些不建议使用的查询缓存项仍然不建议使用，但没有效果，将在以后的MySQL版本中删除：

  • 该SQL_NO_CACHE SELECT修改。

  • 该ndb_cache_check_time系统变量。

  该have_query_cache系统变量保持过时，总有一个价值 NO，并会在将来的MySQL版本中删除。

• 数据字典提供有关数据库对象的信息，因此服务器不再检查数据目录中的目录名称以查找数据库。因此， --ignore-db-dir选项和 ignore_db_dirs系统变量是多余的并被删除。

• DDL日志（也称为元数据日志）已被删除。从MySQL 8.0.3开始，此功能由数据字典innodb_ddl_log表处理 。请参阅 查看DDL日志。

• 该tx_isolation和 tx_read_only系统变量已被删除。使用transaction_isolation和 transaction_read_only代替。

• 该sync_frm系统变量已被删除，因为.frm文件已经过时。

• 该secure_auth系统变量和 --secure-auth客户端选项已被删除。C API函数的MYSQL_SECURE_AUTH选项mysql_options()已删除。

• 的multi_range_count系统变量被移除。

• 该log_warnings系统变量和 --log-warnings服务器选项已被删除。请改用 log_error_verbosity系统变量。

• sql_log_bin系统变量 的全局范围 已删除。sql_log_bin仅具有会话作用域，@@GLOBAL.sql_log_bin应调整依赖于访问的应用程序 。

• 该metadata_locks_cache_size和 metadata_locks_hash_instances系统变量被删除。

• 未使用date_format， datetime_format， time_format，和 max_tmp_tables系统变量被删除。

• 这些弃用兼容性SQL模式被移除： DB2，MAXDB， MSSQL，MYSQL323， MYSQL40，ORACLE， POSTGRESQL， NO_FIELD_OPTIONS， NO_KEY_OPTIONS， NO_TABLE_OPTIONS。它们不能再分配给sql_mode系统变量或用作mysqldump --compatible选项的允许值 。

  删除MAXDB意味着将或 的 TIMESTAMP数据类型 视为 ，而不再视为。 CREATE TABLEALTER TABLETIMESTAMPDATETIME

• 子句 的不推荐使用ASC或 DESC限定符将GROUP BY被删除。先前依赖于GROUP BY排序的查询所产生的结果可能与以前的MySQL版本不同。要产生给定的排序顺序，请提供一个ORDER BY 子句。

• 该语句的EXTENDED和 PARTITIONS关键字 EXPLAIN已删除。这些关键字是不必要的，因为它们的效果始终处于启用状态。

• 这些与加密有关的项目已删除：

  • 该ENCODE()和 DECODE()功能。

  • 该ENCRYPT()功能。

  • 的DES_ENCRYPT()，和 DES_DECRYPT()功能的 --des-key-file选项， have_crypt系统变量，则 DES_KEY_FILE该选项 FLUSH语句和 HAVE_CRYPT CMake的 选项。

  代替已删除的加密功能：对于 ENCRYPT()，请考虑SHA2()改为使用 单向哈希。对于其他，请考虑使用 AES_ENCRYPT()和 AES_DECRYPT()代替。

• 在MySQL 5.7，在多个名称提供了一些空间函数被弃用使得空间功能的命名空间更一致的方向移动，其目标是使每个空间的功能名称开头ST_，如果执行精确的操作，或者MBR如果它执行基于最小边界矩形的操作。在MySQL 8.0中，不赞成使用的函数被删除，仅留下相应的ST_和 MBR函数：

  • 这些功能有利于去除 MBR名称： Contains()， Disjoint()， Equals()， Intersects()， Overlaps()， Within()。

  • 这些功能有利于去除 ST_名称：Area()， AsBinary()， AsText()，AsWKB()， AsWKT()，Buffer()， Centroid()， ConvexHull()， Crosses()， Dimension()， Distance()， EndPoint()， Envelope()， ExteriorRing()， GeomCollFromText()， GeomCollFromWKB()， GeomFromText()， GeomFromWKB()， GeometryCollectionFromText()， GeometryCollectionFromWKB()， GeometryFromText()， GeometryFromWKB()， GeometryN()， GeometryType()， InteriorRingN()， IsClosed()， IsEmpty()， IsSimple()， LineFromText()， LineFromWKB()， LineStringFromText()， LineStringFromWKB()， MLineFromText()， MLineFromWKB()， MPointFromText()， MPointFromWKB()， MPolyFromText()， MPolyFromWKB()， MultiLineStringFromText()， MultiLineStringFromWKB()， MultiPointFromText()， MultiPointFromWKB()， MultiPolygonFromText()， MultiPolygonFromWKB()， NumGeometries()， NumInteriorRings()， NumPoints()， PointFromText()， PointFromWKB()， PointN()， PolyFromText()， PolyFromWKB()， PolygonFromText()， PolygonFromWKB()， SRID()， StartPoint()， Touches()，X()， Y()。

  • GLength()被取消赞成 ST_Length()。

• 第12.17.4节“从WKB值创建几何值 的函数”中描述的函数 以前接受WKB字符串或几何参数。几何参数不再被允许并产生错误。有关从不使用几何参数迁移查询的准则，请参见该部分。

• 解析器不再视为SQL语句中\N的同义词NULL。使用 NULL代替。

  这种变化不影响文本文件导入和导出操作与执行LOAD DATA或 SELECT ... INTO OUTFILE用于其NULL 继续受到代表\N。请参见 第13.2.7节“ LOAD DATA语句”。

• PROCEDURE ANALYSE() 语法已删除。

• 客户端--ssl和 --ssl-verify-server-cert选项已被删除。使用 --ssl-mode=REQUIRED代替--ssl=1或 --enable-ssl。使用 --ssl-mode=DISABLED替代--ssl=0，--skip-ssl或 --disable-ssl。使用 --ssl-mode=VERIFY_IDENTITY 代替--ssl-verify-server-cert 选项。（服务器端 --ssl选项保持不变。）

  对于C API，MYSQL_OPT_SSL_ENFORCE和的 MYSQL_OPT_SSL_VERIFY_SERVER_CERT选项mysql_options() 对应于客户端--ssl和 --ssl-verify-server-cert选项，并被删除。使用MYSQL_OPT_SSL_MODE选项值SSL_MODE_REQUIRED或 SSL_MODE_VERIFY_IDENTITY代替。

• 该--temp-pool移除服务器选项。

• 的ignore_builtin_innodb系统变量被移除。

• 服务器不再执行将包含特殊字符的MySQL 5.1之前的数据库名称转换为带有附加#mysql50#前缀的5.1格式的操作。由于不再执行这些转换，因此删除了mysqlcheck的 --fix-db-names和 --fix-table-names选项， 语句的UPGRADE DATA DIRECTORY NAME子句 ALTER DATABASE以及Com_alter_db_upgrade状态变量。

  仅支持从一个主要版本升级到另一个主要版本（例如，从5.0升级到5.1，或从5.1升级到5.5），因此将旧的5.0数据库名称转换为当前版本的MySQL几乎不需要。解决方法是，先将MySQL 5.0安装升级到MySQL 5.1，然后再升级到最新版本。

• 该mysql_install_db的计划已经从MySQL分发中删除。数据目录初始化应通过使用 或 选项调用mysqld来执行 。另外，删除了mysql_install_db使用的 mysqld 选项，并删除 了控制mysql_install_db安装位置的 选项。 --initialize--initialize-insecure--bootstrapINSTALL_SCRIPTDIR CMake

• 通用分区处理程序已从MySQL服务器中删除。为了支持给定表的分区，用于该表的存储引擎现在必须提供其自己的（“ 本机 ”）分区处理程序。在 --partition和 --skip-partition选项从MySQL服务器删除，分区相关条目中的输出不再显示SHOW PLUGINS或在 INFORMATION_SCHEMA.PLUGINS 表中。

  当前有两个MySQL存储引擎提供本机分区支持：InnoDB 和NDB。其中，InnoDBMySQL 8.0 仅 支持。使用任何其他存储引擎在MySQL 8.0中创建分区表的任何尝试都会失败。

  升级的后果。 不支持 使用除InnoDB（例如 MyISAM）以外的存储引擎将分区表从MySQL 5.7（或更早版本）直接升级到MySQL 8.0。处理此类表有两种选择：

  • 使用删除表的分区 ALTER TABLE ... REMOVE PARTITIONING。

  • 更改用于表的存储引擎 InnoDB，用 ALTER TABLE ... ENGINE=INNODB。

  在InnoDB 将服务器升级到MySQL 8.0之前，必须对每个分区的非表至少执行上述两个操作之一。否则，升级后将无法使用该表。

  由于事实会导致使用存储引擎使用分区表而没有分区支持的表创建语句现在失败，并显示错误（ER_CHECK_NOT_IMPLEMENTED），因此必须确保转储文件中的所有语句（例如mysqldump编写的语句）从您希望导入到创建分区表的MySQL 8.0服务器的MySQL的旧版本中，也没有指定MyISAM没有本地分区处理程序的存储引擎 。您可以通过执行以下任一操作来执行此操作：

  • 从CREATE TABLE使用STORAGE ENGINE选项以外的值的语句中删除对分区的所有引用 InnoDB。

  • 将存储引擎指定为 InnoDB，或者InnoDB默认情况下允许 用作表的存储引擎。

  有关更多信息，请参见 第23.6.2节“与存储引擎有关的分区限制”。

• 系统和状态变量信息不再保存在中INFORMATION_SCHEMA。这些表被删除： GLOBAL_VARIABLES， SESSION_VARIABLES， GLOBAL_STATUS， SESSION_STATUS。请改用相应的性能架构表。请参见 第26.12.14节“性能模式系统变量表”和 第26.12.15节“性能模式状态变量表”。另外，show_compatibility_56 系统变量也被删除。它用于过渡时期，在此期间，系统和状态变量信息INFORMATION_SCHEMA表已移至Performance Schema表，并且不再需要。这些状态变量被删除： Slave_heartbeat_period， Slave_last_heartbeat， Slave_received_heartbeats， Slave_retried_transactions， Slave_running。性能架构表中提供了它们提供的信息。请参阅 迁移到性能模式系统和状态变量表。

• 性能模式setup_timers表已删除，表中的TICK行 也已删除performance_timers。

• 该libmysqld嵌入式服务器库被删除，连同：

  • 在， ， ，和 选项 mysql_options() MYSQL_OPT_GUESS_CONNECTIONMYSQL_OPT_USE_EMBEDDED_CONNECTIONMYSQL_OPT_USE_REMOTE_CONNECTIONMYSQL_SET_CLIENT_IP

  • 该mysql_config --libmysqld-libs， --embedded-libs和 --embedded选项

  • 该CMake的 WITH_EMBEDDED_SERVER， WITH_EMBEDDED_SHARED_LIBRARY和 INSTALL_SECURE_FILE_PRIV_EMBEDDEDDIR 选项

  • （未记录）mysql --server-arg选项

  • 该mysqltest --embedded-server， --server-arg和 --server-file选项

  • 该mysqltest_embedded和 mysql_client_test_embedded测试程序

• 该mysql_plugin移除工具。替代方法包括在服务器启动时使用--plugin-load或 --plugin-load-add选项或在运行时使用该INSTALL PLUGIN语句加载插件。

• 该的resolveip工具被删除。 可以改用nslookup，host或 dig。

• 该resolve_stack_dump工具被删除。官方MySQL构建中的堆栈跟踪始终是符号化的，因此无需使用 resolve_stack_dump。

• 以下服务器错误代码未使用且已删除。专门测试其中任何一个错误的应用程序都应该更新。

  ER_BINLOG_READ_EVENT_CHECKSUM_FAILURE
  ER_BINLOG_ROW_RBR_TO_SBR
  ER_BINLOG_ROW_WRONG_TABLE_DEF
  ER_CANT_ACTIVATE_LOG
  ER_CANT_CHANGE_GTID_NEXT_IN_TRANSACTION
  ER_CANT_CREATE_FEDERATED_TABLE
  ER_CANT_CREATE_SROUTINE
  ER_CANT_DELETE_FILE
  ER_CANT_GET_WD
  ER_CANT_SET_GTID_PURGED_WHEN_GTID_MODE_IS_OFF
  ER_CANT_SET_WD
  ER_CANT_WRITE_LOCK_LOG_TABLE
  ER_CREATE_DB_WITH_READ_LOCK
  ER_CYCLIC_REFERENCE
  ER_DB_DROP_DELETE
  ER_DELAYED_NOT_SUPPORTED
  ER_DIFF_GROUPS_PROC
  ER_DISK_FULL
  ER_DROP_DB_WITH_READ_LOCK
  ER_DROP_USER
  ER_DUMP_NOT_IMPLEMENTED
  ER_ERROR_DURING_CHECKPOINT
  ER_ERROR_ON_CLOSE
  ER_EVENTS_DB_ERROR
  ER_EVENT_CANNOT_DELETE
  ER_EVENT_CANT_ALTER
  ER_EVENT_COMPILE_ERROR
  ER_EVENT_DATA_TOO_LONG
  ER_EVENT_DROP_FAILED
  ER_EVENT_MODIFY_QUEUE_ERROR
  ER_EVENT_NEITHER_M_EXPR_NOR_M_AT
  ER_EVENT_OPEN_TABLE_FAILED
  ER_EVENT_STORE_FAILED
  ER_EXEC_STMT_WITH_OPEN_CURSOR
  ER_FAILED_ROUTINE_BREAK_BINLOG
  ER_FLUSH_MASTER_BINLOG_CLOSED
  ER_FORM_NOT_FOUND
  ER_FOUND_GTID_EVENT_WHEN_GTID_MODE_IS_OFF__UNUSED
  ER_FRM_UNKNOWN_TYPE
  ER_GOT_SIGNAL
  ER_GRANT_PLUGIN_USER_EXISTS
  ER_GTID_MODE_REQUIRES_BINLOG
  ER_GTID_NEXT_IS_NOT_IN_GTID_NEXT_LIST
  ER_HASHCHK
  ER_INDEX_REBUILD
  ER_INNODB_NO_FT_USES_PARSER
  ER_LIST_OF_FIELDS_ONLY_IN_HASH_ERROR
  ER_LOAD_DATA_INVALID_COLUMN_UNUSED
  ER_LOGGING_PROHIBIT_CHANGING_OF
  ER_MALFORMED_DEFINER
  ER_MASTER_KEY_ROTATION_ERROR_BY_SE
  ER_NDB_CANT_SWITCH_BINLOG_FORMAT
  ER_NEVER_USED
  ER_NISAMCHK
  ER_NO_CONST_EXPR_IN_RANGE_OR_LIST_ERROR
  ER_NO_FILE_MAPPING
  ER_NO_GROUP_FOR_PROC
  ER_NO_RAID_COMPILED
  ER_NO_SUCH_KEY_VALUE
  ER_NO_SUCH_PARTITION__UNUSED
  ER_OBSOLETE_CANNOT_LOAD_FROM_TABLE
  ER_OBSOLETE_COL_COUNT_DOESNT_MATCH_CORRUPTED
  ER_ORDER_WITH_PROC
  ER_PARTITION_SUBPARTITION_ERROR
  ER_PARTITION_SUBPART_MIX_ERROR
  ER_PART_STATE_ERROR
  ER_PASSWD_LENGTH
  ER_QUERY_ON_MASTER
  ER_RBR_NOT_AVAILABLE
  ER_SKIPPING_LOGGED_TRANSACTION
  ER_SLAVE_CHANNEL_DELETE
  ER_SLAVE_MULTIPLE_CHANNELS_HOST_PORT
  ER_SLAVE_MUST_STOP
  ER_SLAVE_WAS_NOT_RUNNING
  ER_SLAVE_WAS_RUNNING
  ER_SP_GOTO_IN_HNDLR
  ER_SP_PROC_TABLE_CORRUPT
  ER_SQL_MODE_NO_EFFECT
  ER_SR_INVALID_CREATION_CTX
  ER_TABLE_NEEDS_UPG_PART
  ER_TOO_MUCH_AUTO_TIMESTAMP_COLS
  ER_UNEXPECTED_EOF
  ER_UNION_TABLES_IN_DIFFERENT_DIR
  ER_UNSUPPORTED_BY_REPLICATION_THREAD
  ER_UNUSED1
  ER_UNUSED2
  ER_UNUSED3
  ER_UNUSED4
  ER_UNUSED5
  ER_UNUSED6
  ER_VIEW_SELECT_DERIVED_UNUSED
  ER_WRONG_MAGIC
  ER_WSAS_FAILED

• 不推荐使用INFORMATION_SCHEMA INNODB_LOCKS，并 INNODB_LOCK_WAITS表将被删除。请改用性能架构 data_locks和 data_lock_waits表。

  注意

  在MySQL 5.7中，LOCK_TABLE在列INNODB_LOCKS表和locked_table在列 sys模式 innodb_lock_waits和 x$innodb_lock_waits视图包含组合模式/表名的值。在MySQL 8.0中，data_locks表和 sys架构视图包含单独的架构名称和表名称列。请参见 第27.4.3.9节“ innodb_lock_waits和x $ innodb_lock_waits视图”。

• InnoDB不再支持压缩的临时表。当 innodb_strict_mode启用（默认值）， CREATE TEMPORARY TABLE如果返回错误 ROW_FORMAT=COMPRESSED或 KEY_BLOCK_SIZE指定的。如果 innodb_strict_mode禁用此选项，则会发出警告，并使用非压缩的行格式创建临时表。

• InnoDB 在MySQL数据目录之外创建表空间数据文件时，不再创建 .isl文件（InnoDB符号链接文件）。该 innodb_directories选项现在支持查找在数据目录外部创建的表空间文件。

  通过此更改，.isl不再支持在服务器脱机时通过手动修改文件来移动远程表空间 。该innodb_directories选件现在支持移动远程表空间文件 。请参见第15.6.3.6节“在服务器脱机时移动表空间文件”。

• 以下InnoDB文件格式变量已删除：

  • innodb_file_format

  • innodb_file_format_check

  • innodb_file_format_max

  • innodb_large_prefix

  文件格式变量对于创建与InnoDBMySQL 5.1 早期版本兼容的表是必需的 。既然MySQL 5.1的产品生命周期已经结束，则不再需要这些选项。

  该FILE_FORMAT列已从INNODB_TABLES和 INNODB_TABLESPACES信息模式表中删除。

• innodb_support_xa删除了支持在XA事务中支持两阶段提交 的系统变量。InnoDB始终启用对XA事务中的两阶段提交的支持。

• 对DTrace的支持已删除。

• 该JSON_APPEND()功能已删除。使用JSON_ARRAY_APPEND() 代替。

• InnoDB在MySQL 8.0.13中删除了 对将表分区放置在共享 表空间中的支持。共享表空间包括 InnoDB系统表空间和常规表空间。有关在共享表空间中标识分区并将其移至每个表文件表空间的信息，请参见第2.11.5节“为升级准备安装”。

• 支持SET 在MySQL 8.0.13中弃用的语句中设置用户变量 。此功能可能会在MySQL 9.0中删除。

• 该--ndb PERROR移除选项。请改用ndb_perror实用程序。

• 该innodb_undo_logs变量已删除。这些 innodb_rollback_segments 变量执行相同的功能，应改为使用。

• 在Innodb_available_undo_logs取出状态变量。每个表空间的可用回滚段数可以使用SHOW VARIABLES LIKE 'innodb_rollback_segments';

• 从MySQL 8.0.14开始，先前弃用的 innodb_undo_tablespaces 变量不再可配置。有关更多信息，请参见第15.6.3.4节“撤消表空间”。

• 对该ALTER TABLE ... UPGRADE PARTITIONING语句的支持已删除。

• 从MySQL 8.0.16开始，internal_tmp_disk_storage_engine 已经删除了对系统变量的支持 。现在，磁盘上的内部临时表始终使用 InnoDB存储引擎。有关更多信息，请参阅 磁盘内部临时表的存储引擎。

• 该CMake的选择是不使用的，并已被删除。 DISABLE_SHARED

标签：语句,8.0,1.3,MySQL,JSON,使用,ER
来源： https://www.cnblogs.com/owlin/p/13729006.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。