MySQL 8.0中新增的功能（九）

FROM_UNIXTIME()、UNIX_TIMESTAMP()和CONVERT_TZ()的64位支持

根据MySQL 8.0.28版本的更新，FROM_UNIXTIME()、UNIX_TIMESTAMP() 和 CONVERT_TZ() 函数现在在支持64位的平台上处理64位值。这包括64位版本的Linux、MacOS和Windows。在兼容的平台上，UNIX_TIMESTAMP()函数现在可以处理的值范围扩大到了'3001-01-18 23:59:59.999999' UTC，FROM_UNIXTIME()函数可以将值转换为1970年以来的秒数，范围扩大到了32536771199.999999秒；CONVERT_TZ()函数在转换后接受不超过'3001-01-18 23:59:59.999999' UTC的值。

这些更改对32位平台上的这些函数行为没有影响。TIMESTAMP类型的行为也不受影响（在任何平台上）；要处理2038年1月19日03:14:07.999999以后的日期时间，请使用DATETIME类型。

资源分配控制?

从MySQL 8.0.28开始，你可以通过检查Global_connection_memory状态变量来查看所有普通用户发出的查询所使用的内存量。（这个总数不包括系统用户如MySQL root使用的资源。它也不包括InnoDB缓冲池占用的任何内存。）

要启用对Global_connection_memory的更新，需要设置global_connection_memory_tracking = 1；默认情况下，它为0（关闭）。你可以通过设置connection_memory_chunk_size来控制Global_connection_memory的更新频率。

还可以通过设置以下列出的系统变量之一或两者，为普通用户在会话或全局级别上设置内存使用限制，或两者都设置：

? connection_memory_limit：为每个连接分配的内存量。当任何用户的内存超过此限制时，该用户的新查询将被拒绝。

? global_connection_memory_limit：为所有连接分配的内存量。当超过此限制时，任何普通用户的新查询都将被拒绝。

这些限制不适用于系统进程或管理账户。?

分离的XA事务

MySQL 8.0.29 引入了对XA事务的支持。一旦准备就绪，这些事务不再与原始连接关联。这意味着它们可以由另一个连接提交或回滚，并且当前会话可以立即开始另一个事务。

系统变量xa_detach_on_prepare控制XA事务是否分离，默认值为ON，这会导致所有的XA事务都是分离的。当此选项生效时，不允许在XA事务中使用临时表。

二进制日志自动清理控制

MySQL 8.0.29 版本新增了binlog_expire_logs_auto_purge系统变量，它提供了一个统一的界面用于启用和禁用二进制日志的自动清理。默认情况下，该选项已启用（ON）；要禁用二进制日志文件的自动清理，请将该变量设置为OFF。

在二进制日志文件自动清理进行时，binlog_expire_logs_auto_purge必须设置为ON；该变量的值优先于任何其他服务器选项或变量的值，包括（但不仅限于）binlog_expire_logs_seconds。

binlog_expire_logs_auto_purge的设置不影响PURGE BINARY LOGS命令的执行。

条件性存储过程和触发器创建语句

从MySQL 8.0.29开始，以下语句支持IF NOT EXISTS选项：
? CREATE FUNCTION
? CREATE PROCEDURE
? CREATE TRIGGER
对于CREATE FUNCTION用于创建存储函数和CREATE PROCEDURE，在存在同名的例程时，此选项可以防止出现错误。对于用于创建可加载函数的CREATE FUNCTION，如果已经存在具有该名称的可加载函数，该选项可以防止出现错误。对于CREATE TRIGGER，在同一模式和同一表中已经存在同名触发器时，该选项可以防止出现错误。

此增强功能使这些语句的语法更接近CREATE DATABASE、CREATE TABLE、CREATE USER和CREATE EVENT（它们已经支持IF NOT EXISTS），并且与DROP PROCEDURE、DROP FUNCTION和DROP TRIGGER语句支持的IF EXISTS选项相辅相成。

包括FIDO库的升级

MySQL 8.0.30将所包含的fido2库（与authentication_fido插件一起使用）从版本1.5.0升级到版本1.8.0。

字符集：语言特定的排序规则

在以前，当有多种语言具有完全相同的排序规则定义时，MySQL只为其中一种语言实现了排序规则，这意味着一些语言只能通过适用于其他语言的utf8mb4 Unicode 9.0排序规则来覆盖。MySQL 8.0.30（及更高版本）通过为以前仅由其他语言的特定排序规则覆盖的语言提供特定于语言的排序规则来解决此类问题。以下是新排序规则所涵盖的语言:
? 挪威语（尼诺斯克）
和
挪威语（博克马尔）
? 塞尔维亚语（拉丁字符）
? 波斯尼亚语（拉丁字符）
? 保加利亚语
? 加利西亚语
? 蒙古语（西里尔字符）
MySQL为上述每种语言提供了*_as_cs和*_ai_ci两种排序规则。

对于REVOKE新增了IF EXISTS和IGNORE UNKNOWN USER选项

MySQL 8.0.30实现了REVOKE的两个新选项，用于确定当语句中指定的用户、角色或权限无法找到或无法分配时，是否产生错误或警告。以下是提供了放置这些新选项的非常基本的语法示例：

REVOKE [IF EXISTS] privilege_or_role
 ON object
 FROM user_or_role [IGNORE UNKNOWN USER]

IF EXISTS选项使得一个未成功的REVOKE语句在目标用户或角色实际存在的情况下引发警告，而不管语句中是否有任何找不到的角色或权限的引用。

IGNORE UNKNOWN USER选项使得在语句中指定的目标用户或角色未找到时，一个未成功的REVOKE语句引发警告而不是错误。

?生成的不可见主键

从MySQL 8.0.30开始，可以运行一个复制源服务器，以便在创建没有显式主键的InnoDB表时添加一个生成的隐式主键(GIPK)。添加到这样一个表中的生成的键列定义等效于以下内容：

my_row_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT INVISIBLE PRIMARY KEY

默认情况下，GIPK模式是禁用的。要启用它，将sql_generate_invisible_primary_key服务器系统变量设置为ON。生成的隐式主键通常在诸如SHOW CREATE TABLE和SHOW INDEX的语句的输出中可见，以及MySQL信息模式表（如COLUMNS和STATISTICS表）中。您可以通过将show_gipk_in_create_table_and_information_schema设置为OFF来隐藏它们。

作为这项工作的一部分，mysqldump和mysqlpump添加了一个新的--skip-generated-invisible-primary-key选项，用于在输出中排除生成的隐式主键、列和列值。

GIPK和具有或不具有主键的表之间的复制

在MySQL复制中，复制服务器实际上会忽略源服务器上sql_generate_invisible_primary_key的任何设置，因此对复制的表没有影响。从MySQL 8.0.32开始，复制服务器可以向任何在复制时没有主键的InnoDB表中添加一个生成的隐式主键。您可以通过在复制服务器上调用CHANGE REPLICATION SOURCE TO ... REQUIRE_TABLE_PRIMARY_KEY_CHECK = GENERATE来实现此操作。

REQUIRE_TABLE_PRIMARY_KEY_CHECK = GENERATE与MySQL Group Replication不兼容。

崩溃安全的XA事务

以前，对于二进制日志来说，XA事务在意外停机方面不完全具备弹性，如果在服务器执行XA PREPARE、XA COMMIT或XA ROLLBACK过程中发生意外停机，则无法保证服务器能够恢复到正确的状态。可能会导致二进制日志中存在未应用的额外XA事务，或者丢失已应用的一个或多个XA事务。从MySQL 8.0.30开始，这个问题不再存在，无论由于什么原因一个服务器掉出了复制拓扑，都可以在重新加入时将其带回到一致的XA事务状态。

已知问题：当使用相同的事务XID依次执行XA事务，并在执行XA COMMIT ... ONE PHASE时发生中断时，如果在存储引擎中准备了此事务之后再次使用相同的XID，可能无法再将二进制日志和存储引擎之间的状态同步。

使用UNION进行嵌套?

从MySQL 8.0.31开始，与UNION结合使用时，可以在查询表达式的括号体内进行最多63个级别的嵌套。以前，此类查询将被拒绝并显示错误信息 ER_NOT_SUPPORTED_YET，但现在允许执行此类查询。以下是这样一个查询的EXPLAIN输出示例：

mysql> EXPLAIN FORMAT=TREE (
 -> (SELECT a, b, c FROM t ORDER BY a LIMIT 3) ORDER BY b LIMIT 2
 -> ) ORDER BY c LIMIT 1\G
*************************** 1. row ***************************
EXPLAIN: -> Limit: 1 row(s) (cost=5.55..5.55 rows=1)
 -> Sort: c, limit input to 1 row(s) per chunk (cost=2.50 rows=0)
 -> Table scan on <result temporary> (cost=2.50 rows=0)
 -> Temporary table (cost=5.55..5.55 rows=1)
 -> Limit: 2 row(s) (cost=2.95..2.95 rows=1)
 -> Sort: b, limit input to 2 row(s) per chunk (cost=2.50 rows=0)
 -> Table scan on <result temporary> (cost=2.50 rows=0)
 -> Temporary table (cost=2.95..2.95 rows=1)
 -> Limit: 3 row(s) (cost=0.35 rows=1)
 -> Sort: t.a, limit input to 3 row(s) per chunk (cost=0.35 rows=1)
 -> Table scan on t (cost=0.35 rows=1)
1 row in set (0.00 sec)

MySQL在折叠括号内查询表达式的体时遵循SQL标准的语义，因此外部更高的限制值不能覆盖内部更低的限制值。例如，(SELECT ... LIMIT 5) LIMIT 10 最多只会返回五行结果。

63级别的限制仅在MySQL优化器的解析器执行任何简化或合并操作之后才会生效。

禁用查询重写?

以前，使用Rewriter插件时，无论用户是谁，所有查询都可能被重写。这在某些情况下可能会引起问题，例如在管理系统时或应用来自复制源或由mysqldump或其他MySQL程序创建的转储文件中的语句时。MySQL 8.0.31通过引入一个新的用户特权SKIP_QUERY_REWRITE来解决这些问题；拥有此特权的用户发出的语句将被Rewriter忽略且不会进行重写处理。

MySQL 8.0.31还增加了一个新的服务器系统变量 rewriter_enabled_for_threads_without_privilege_checks。当设置为OFF时，由 PRIVILEGE_CHECKS_USER 为NULL的线程（如复制应用程序线程）发出的可重写语句不会被Rewriter插件进行重写处理。默认值是ON，这意味着这类语句会被重写处理。?

?