怎样建设个人影视网站,wordpress会员提成插件,一个服务器上有两个网站 要备案两次吗,建设行政主管部门网站用户评论和用户属性
MySQL 8.0.21引入了在创建或更新用户账户时设置用户评论和用户属性的功能。用户评论由作为COMMENT子句参数传递的任意文本组成#xff0c;通过CREATE USER或ALTER USER语句使用。用户属性由以JSON对象形式传递的数据组成#xff0c;作为ATTRIBUTE子句参数…用户评论和用户属性
MySQL 8.0.21引入了在创建或更新用户账户时设置用户评论和用户属性的功能。用户评论由作为COMMENT子句参数传递的任意文本组成通过CREATE USER或ALTER USER语句使用。用户属性由以JSON对象形式传递的数据组成作为ATTRIBUTE子句参数传递给这两个语句之一。属性可以包含JSON对象表示法中的任何有效的键值对。在单个CREATE USER或ALTER USER语句中只能使用COMMENT或ATTRIBUTE中的一个。
用户评论和用户属性在内部作为一个JSON对象存储在一起其中评论文本作为键为comment的元素的值。这些信息可以从Information Schema USER_ATTRIBUTES表的ATTRIBUTE列中检索由于它以JSON格式存储您可以使用MySQL的JSON函数和运算符来解析其内容。对用户属性的连续更改将与当前值合并就像使用JSON_MERGE_PATCH()函数一样。
例如
mysql CREATE USER marylocalhost COMMENT This is Mary Smith\s account;
Query OK, 0 rows affected (0.33 sec)
mysql ALTER USER marylocalhost-≫ ATTRIBUTE {fname:Mary, lname:Smith};
Query OK, 0 rows affected (0.14 sec)
mysql ALTER USER marylocalhost-≫ ATTRIBUTE {email:mary.smithexample.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 USERmary AND HOSTlocalhost\G
*************************** 1. row ***************************USER: maryHOST: localhost
First Name: MaryLast Name: SmithEmail: mary.smithexample.comComment: This is Mary Smiths account
1 row in set (0.00 sec)新的optimizer_switch标志
MySQL 8.0.21在optimizer_switch系统变量中添加了两个新的标志如下所述
• prefer_ordering_index标志 默认情况下当优化器确定使用有序索引可以更快执行带有LIMIT子句的ORDER BY或GROUP BY查询时MySQL会尝试使用有序索引。然而在某些情况下选择不同的优化方式可能会实际表现更好。现在可以通过将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。 从MySQL 8.0.24开始该优化还可以应用于相关标量子查询通过对其应用额外的分组然后在提升的谓词上进行外连接。例如查询SELECT * FROM t1 WHERE (SELECT a FROM t2 WHERE t2.at1.a) 0可以重写为SELECT t1.* FROM t1 LEFT OUTER JOIN (SELECT a, COUNT(*) AS ct FROM t2 GROUP BY a) AS derived ON t1.a derived.a WHERE derived.a 0。MySQL执行基数检查以确保子查询不返回多行ER_SUBQUERY_NO_1_ROW。
通常情况下该优化被禁用因为在大多数情况下它并不会带来明显的性能优势。该标志默认为off。
XML增强功能
从MySQL 8.0.21开始LOAD XML语句现在支持导入XML中的CDATA节。
现在支持将数据转换为YEAR类型
从MySQL 8.0.22开始服务器允许将数据转换为YEAR类型。CAST()和CONVERT()函数都支持单个数字、两位数字和四位数字的YEAR值。对于一位数字和两位数字的值允许的范围是0-99。四位数字的值必须在1901-2155的范围内。YEAR还可以作为JSON_VALUE()函数的返回类型使用该函数只支持四位数的年份。
字符串、日期时间和浮点数值都可以转换为YEAR类型。不支持将GEOMETRY值转换为YEAR类型。
将TIMESTAMP值作为UTC检索
从MySQL 8.0.22开始支持将系统时区的TIMESTAMP列值在检索时转换为UTC DATETIME。使用CAST(value AT TIME ZONE specifier AS DATETIME)语法其中specifier是[INTERVAL] 00:00或UTC之一。如果需要可以通过指定精度高达6位小数的DATETIME值返回的参数来确定精度。在这种构造中不支持ARRAY关键字。 还支持使用时区偏移插入到表中的TIMESTAMP值。不支持在CONVERT()或任何其他MySQL函数或构造中使用AT TIME ZONE。
Dump文件输出同步化
从MySQL 8.0.22开始通过SELECT INTO DUMPFILE和SELECT INTO OUTFILE语句在写入文件时支持定期同步化。可以通过将select_into_disk_sync系统变量设置为ON来启用此功能写入缓冲区的大小由select_into_buffer_size设置的值确定默认为131072217字节。 此外可以使用select_into_disk_sync_delay来设置同步到磁盘后的可选延迟时间默认为无延迟0毫秒。
单次准备语句
从MySQL 8.0.22开始准备语句只需准备一次而不是在每次执行时都要准备。这是在执行PREPARE时完成的。对于存储过程内部的任何语句也是如此当首次执行存储过程时语句将被准备一次。
这个改变的一个结果是准备语句中使用的动态参数的解析方式也按照以下方式进行了更改
准备语句的参数在准备语句时被分配一个数据类型该类型会保留在每次后续执行该语句时除非重新准备该语句见下文。对于在准备语句后续执行中使用的给定参数或用户变量如果使用了不同的数据类型可能会导致语句被重新准备因此建议在重新执行准备语句时使用相同的数据类型。不再接受使用窗口函数的以下结构以与SQL标准保持一致 NTILE(NULL)NTH_VALUE(expr, NULL)LEAD(expr, nn) 和 LAG(expr, nn)其中nn是负数 这有助于更好地符合SQL标准。请参阅各个函数的描述以获取更多详细信息。在准备语句中引用的用户变量现在在准备语句时具有确定的数据类型该类型会保留在每次后续执行该语句时。在存储过程中出现的语句中引用的用户变量现在在第一次执行该语句时确定其数据类型并且该类型会保留在任何后续调用该存储过程时。当执行形如SELECT expr1, expr2, ... FROM table ORDER BY ? 的准备语句时为参数传递一个整数值N不再导致结果按照选择列表中的第N条表达式排序结果不再排序而与使用ORDER BY常量时的预期一致。仅在作为准备语句或存储过程中出现的语句中进行一次准备可以提高性能因为它消除了重复准备的额外成本。这样做还可以避免可能的多个准备结构回滚这是MySQL中许多问题的根源。
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 constant的查询现在可以在许多情况下将外部WHERE条件下推至派生表从而得到SELECT * FROM (SELECT i, j FROM t1 WHERE i constant) AS dt的结果。
在以前如果派生表被物化但没有合并MySQL会将整个表进行物化然后使用WHERE条件对行进行筛选。通过使用派生条件下推优化将WHERE条件移到子查询中通常可以减少需要处理的行数从而减少执行查询所需的时间。
当派生表不使用任何聚合或窗口函数时外部WHERE条件可以直接下推到物化的派生表。当派生表使用GROUP BY但不使用任何窗口函数时外部WHERE条件可以作为HAVING条件下推到派生表中。当派生表使用窗口函数且外部WHERE条件引用了窗口函数的PARTITION子句中使用的列时WHERE条件也可以下推到派生表中。
派生条件下推默认情况下是启用的可以通过optimizer_switch系统变量中的derived_condition_pushdown标志进行确认。这个标志在MySQL 8.0.22中添加它默认设置为开启。要禁用特定查询的优化可以使用NO_DERIVED_CONDITION_PUSHDOWN优化器提示也是在MySQL 8.0.22中添加的。如果由于设置derived_condition_pushdown为off而禁用了优化可以使用DERIVED_CONDITION_PUSHDOWN来为特定查询启用优化。
派生条件下推优化不能应用于包含LIMIT子句的派生表。在MySQL 8.0.29之前当查询包含UNION时也无法使用该优化。从MySQL 8.0.29开始条件在大多数情况下可以下推到联合查询的两个查询块中。
此外一个使用子查询的条件无法进行下推而一个包含在外连接中的派生表作为内部表时其WHERE条件也无法进行下推。
MySQL授权表上的非锁定(Non-locking)读取
从MySQL 8.0.22开始为了允许对MySQL授权表进行并发的DML和DDL操作之前在MySQL授权表上获取行锁的读操作被执行为非锁定读取。
现在在MySQL授权表上执行的非锁定读取操作包括 • 通过连接列表和子查询从授权表读取数据的SELECT语句和其他只读语句包括使用任何事务隔离级别的SELECT ... FOR SHARE语句。 • 使用任何事务隔离级别从授权表中读取数据通过连接列表或子查询但不修改它们的DML操作。
