在升级之前,
CONVERT()
应根据需要检查和更新可能依赖于以前行为的应用程序。特别是,对于使用
CONVERT()
无效值生成的列上的索引,您应该更正这些值,删除索引,然后在升级到此版本之前重新创建它。在某些情况下,使用 重建表可能
比删除并重新创建索引更简单。有关详细信息,请参阅
SQL 更改
。(缺陷号 33199145)
ALTER TABLE
table
FORCE
多值索引的十六进制编码范围的输出
EXPLAIN
FORMAT=TREE
,即使数据类型不是二进制类型也是如此。此外,使用字符串类型的范围在具有二进制排序规则时也会使用十六进制编码值打印。后一个问题也影响了常规索引,但对于多值索引更明显,因为它们总是使用
utf8mb4_0900_bin
排序规则。现在,十六进制编码仅用于具有二进制字符集的字符串类型。具有非二进制字符集的字符串现在
EXPLAIN FORMAT=TREE
作为纯文本打印在输出中,并转义任何特殊字符。(缺陷号 33343948)
对于某些函数,解析的字符集并不总是与第一个参数的字符集相同。(错误#32668730,错误#33238711)
InnoDB:
解决了与以下 MSVC++ 级别 4 编译器警告相关的编译问题:C4201、C4701、C4702、C4703、C4706。以前禁用的编译器警告现在已启用。(缺陷号 33464699)
InnoDB:
已启用 MSVC++ 级别 4 编译器警告。(缺陷号 33437498)
InnoDB:
使用 Visual Studio 2019 版本 16.10 或版本 16.11 构建调试版本的 MySQL 时发生访问冲突。违规是由于 STL 迭代器错误。(缺陷号 33223243)
包含 curl 而不是链接到系统 curl 库的二进制包已升级为使用 curl 7.80.0。(缺陷号 33576431)
DATETIME
或
TIMESTAMP
列中引发了错误的错误。对于
DATE
列,此错误类似于
Data truncation: Incorrect date value: '2012-00-00' for column 'd' at row 1
。这发生在二进制和文本协议中。
使用二进制协议将
带有偏移量的值插入到
DATE
或
列中会产生错误的结果。
TIME
例如,当连接时区设置为 GMT-5 时,插入
'2021-10-10 00:00:00.123+01:00'
到
TIME
列中产生
'18:00:00'
;也就是说,该值已转换为连接时区(这应该只针对
DATETIME
列进行)。
TIMESTAMP
每当将具有时区偏移量的值插入
TIME
或
DATE
列
时,我们都会通过识别和调整时区偏移量来解决这些问题。(错误#33616957,错误#33649009)
参考资料:另请参阅:Bug #33539844。
MySQL 8.0.27 中针对先前问题的修复将布尔表达式的解析类型从有符号
INT
更改为无符号
BIGINT
,以简化类型处理,但随后出现的无害元数据更改结果导致某些 MySQL 连接器出现问题.
我们现在恢复元数据更改并为原始问题提供不同的解决方案,方法是
max_length
将整数的否定调整为至少两个字符。(缺陷号 33516898)
参考资料:此问题是 Bug #33117410 的回归。
某些列类型的排序,包括
JSON
和
TEXT
,如果其大小不是排序中最大行的至少 15 倍,有时会耗尽排序缓冲区。现在排序缓冲区只需要是最大排序键的 15 倍。(错误#103325、错误#105532、错误#32738705、错误#33501541)
参考资料:此问题是 Bug #30400985、Bug #30804356 的回归。
从 MySQL 8.0.28 开始,删除了对 TLSv1 和 TLSv1.1 连接协议的支持。这些协议已从 MySQL 8.0.26 中弃用。有关背景信息,请参阅 IETF 备忘录
Deprecating TLSv1.0 and TLSv1.1。使用更安全的 TLSv1.2 和 TLSv1.3 协议建立连接。TLSv1.3 要求 MySQL 服务器软件和客户端应用程序都是使用 OpenSSL 1.1.1 或更高版本编译的。
从 MySQL 8.0.28 开始,支持
--tls-version
指定用于连接 MySQL 服务器的 TLS 协议的选项的客户端程序(包括 MySQL Shell)无法建立协议设置为 TLSv1 或 TLSv1.1 的 TLS/SSL 连接。如果客户端尝试使用这些协议进行连接,对于 TCP 连接,连接将失败,并向客户端返回一个错误。对于套接字连接,如果
–ssl-mode
设置为 REQUIRED,则连接失败,否则建立连接但禁用 TLS/SSL。
在服务器端,从 MySQL 8.0.28 开始更改了以下设置:
tls_version
服务器和
admin_tls_version
不再包括 TLSv1 和 TLSv1.1。
Group Replication 系统变量的默认值
group_replication_recovery_tls_version
不再包括 TLSv1 和 TLSv1.1。
对于异步复制,副本不能将连接到源服务器的协议设置为 TLSv1 或 TLSv1.1(语句的
SOURCE_TLS_VERSION
选项
CHANGE REPLICATION SOURCE TO
ASCII
for
CHARACTER
SET latin1
和
UNICODE
for
的快捷方式
CHARACTER SET ucs2
现在已弃用,您应该期望在未来版本的 MySQL 中删除它们。现在使用其中任何一个都会发出警告;改用
CHARACTER SET
。
此处列出的字符集及其所有排序规则现已弃用,并可能在后续的 MySQL 版本中删除:
macroman
和
macce
在 SQL 语句或 MySQL 服务器的其他地方使用这些字符集或其排序规则中的任何一个现在都会产生弃用警告。
您应该使用
utf8mb4
而不是刚刚列出的任何字符集。另请参阅
ucs2 字符集(UCS-2 Unicode 编码)
、
西欧字符集
和
中欧字符集
。
作为以前的方便,当
super_read_only
系统变量被禁用时,服务器会根据需要自动重新启动事件调度程序。现在,当
read_only
系统变量被禁用时,同样的便利可以独立应用。在此更新之前,禁用
read_only
也可以
super_read_only
在需要时禁用,但由于代码是分开的,因此没有重新启动 Event Scheduler。(缺陷号 33539082)
全文检索注释
由于在实现时
MATCH()
不作为其参数的函数,而是作为基表基础扫描中当前行的行 ID 的函数,使用汇总列作为参数的查询此功能往往表现不佳,并且结果不可靠。在这种情况下,
MATCH()
只要满足以下条件,就不再允许使用汇总列:
MATCH()
出现在
SELECT
列表、
GROUP
BY
子句、
HAVING
子句或
ORDER BY
子句中。
查询使用
GROUP BY ... WITH ROLLUP
.
分组列用作 的参数
MATCH()
。
现在拒绝任何此类查询
ER_FULLTEXT_WITH_ROLLUP
。(
MATCH()
在子句中使用 with a rollup column
WHERE
不受此更改的影响,并且仍然允许。)
有关详细信息,请参阅
全文搜索功能
。(错误#32565923,错误#32996762)
在 MySQL 8.0.22 中实现预处理语句的单一准备之前,
TIME
在这种情况下会返回值;在此之前,用作参数的值及其类型用于在解析时确定某些时间函数的结果类型,例如
DATE_ADD()
、
DATE_SUB()
和
ADDTIME()
。之后,用户变量引用和动态参数仅在一次执行的生命周期内被视为常量,需要以另一种方式确定返回类型,在本例中为函数类型。例如,如果第一个参数是动态参数,则默认的解析类型
DATE_ADD()
被认为是
,因为
DATETIME
DATETIME
容纳所有时间值,因此可以避免隐式重新准备。
刚刚描述的变化代表了倒退;通过派生更精确的已解析数据类型并仅在与参数的实际值不匹配时才执行重新准备,可以更好地解决该问题。(此类功能已在 MySQL 服务器中用于数字参数。)此解决方案通过此修复程序实现。
我们现在在需要时间值时解析字符串和数值。当找到有效的时间值时,将转换该值。此修复还改进了时间函数的已解析数据类型的确定。
通过此修复,
DATE_ADD()
和
DATE_SUB()
函数(及其同义词函数
ADDDATE()
和
SUBDATE()
)解析类型如下:
如果第一个参数是动态参数,则其解析类型是
DATE
如果第二个参数是仅包含 、 或值的某种组合
YEAR
的
MONTH
区间
DAY
;否则,它的类型是
DATETIME
.
如果第一个参数解析为
DATETIME
,则函数的解析类型也是
DATETIME
。
如果第一个参数是 a
DATE
,则函数的解析类型也是
DATE
,除非区间参数使用
HOUR
,
MINUTE
或
SECOND
,在这种情况下它是
DATETIME
。
如果第一个参数是一个
TIME
值,解析的类型也是
TIME
,除非区间参数使用 、 或 中的任何一个
YEAR
,
MONTH
在
DAY
这种情况下函数的解析类型是
DATETIME
。
如果不满足上述任何条件,则函数解析为
VARCHAR
(与 MySQL 8.0.21 及更早版本中一样)。
和函数
ADDTIME()
现在
SUBTIME()
解析类型如下:
如果第一个参数是动态参数,则解析的类型是
TIME
, 而不是
DATETIME
。
否则,函数的解析类型派生自第一个参数的解析类型。
此外,对于
DATE_ADD()
and
DATE_SUB()
,如果第一个参数的解析类型为
DATE
,并且
DATETIME
提供了一个值,则重新准备语句以使函数具有解析类型
DATETIME
。
TIME
提供值
时,行为不会改变
对于
ADDTIME()
和
SUBTIME()
,没有强制重新准备。(错误#103781、错误#32915973、错误#33477883、错误#33539844)
以前,可加载函数和存储函数共享同一个命名空间,不能重名。随后的实现更改消除了共享相同名称空间的原因,并允许使用与现有可加载函数相同的名称创建存储函数。要调用存储的函数,必须使用模式名称对其进行限定。如果存储的函数名称与现有的可加载函数名称冲突,服务器现在会生成警告。(错误号 33301931)
MBRContains()
函数的查询并未使用所有可用的空间索引。(缺陷号 32975221)
参考资料:此问题是 Bug #29770705 的回归。
FORMAT()
当指定 es_ES 或 es_MX 语言环境时,
该函数返回一个格式化数字,但不显示千位分隔符和分隔符之间的分组。(缺陷号 31374305)
GROUP_CONCAT()
增大的值时,函数
的结果长度
错误
group_concat_max_len
。一个小的
group_concat_max_len
值,结果是正确的。这个问题是由算术溢出引起的。
感谢 Hope Lee 的贡献。(错误#105380,错误#33521497)
对于查询,可以先选择范围扫描,然后优化器决定可以使用相同的范围扫描来跳过排序。在某些情况下,当请求的顺序与索引顺序不相同时,需要进行反向索引扫描。如果请求的排序在范围扫描尚未使用的关键部分上,我们更新范围扫描使用的关键部分的数量以反映变化。出现这个问题是因为关键部件信息也没有更新,并且需要根据使用的关键部件数量访问关键部件信息。
我们现在还注意到反向扫描何时使用扩展的关键部分,并相应地设置正确的评估标志。(缺陷号 33615893)
参考资料:此问题是 Bug #33037007 的回归。
在优化器跟踪和
EXPLAIN
FORMAT=TREE
输出中,日期范围都以二进制形式打印。现在在这种情况下,我们将时间值打印为带引号的字符串。(缺陷号 33335079)
下推条件时,
SELECT
有时会影响子查询列表中用户变量赋值的评估结果。出于这个原因,我们现在防止对分配给用户变量的语句进行条件下推。
感谢 Casa Zhang 和腾讯团队的贡献。(错误#104918,错误#33341080)
当连接缓冲区设置为某些任意大小时,为散列连接创建的块文件数量太少。这意味着每个文件包含的行数超过了连接缓冲区所能容纳的行数,因此需要多次读取探测块。这是由于在计算需要多少块文件时使用整数除法造成的;我们改用浮点除法来解决这个问题。
感谢 Øystein Grøvlen 的贡献。(错误#104186,错误#33073354)
BIT
根据所使用的索引或连接类型,对类型
使用聚合的查询
可能会返回不同的结果。这是因为使用此类聚合的 DML 语句使用
BIT
整数类型缓存值,然后查找并转换为字符串格式以进行输出。出现当前问题是因为此查找将
BIT
值视为整数,从而导致不正确的字符串值。
这是通过为缓存值添加一个新的内部类来解决的,
BIT
它可以正确地将位值转换为字符串格式。
感谢 Hope Lee 的贡献。(缺陷 #100859,缺陷 #31894023)
DISTINCT
当 DML 语句包含子查询内有子查询
查询时
HAVING
,内部子查询尝试对外部查询中的列使用列引用
DISTINCT
,但只有在子查询之外的某处使用子查询时才允许这样做
HAVING
,或者如果外部
SELECT
不使用分组。当前问题的出现是因为即使这些条件都不满足,也允许运行这样的查询。
为解决此问题,扩展了列引用检查以检测此类无效的列引用,并在检测到时返回错误。
感谢宋志白的贡献。(缺陷 #97742,缺陷 #30617496)
用于签署 MySQL 可下载包的 GnuPG 构建密钥已更新。之前的 GnuPG 构建密钥设置为在 2022-02-16 到期。有关使用 GnuPG 签名检查验证 MySQL 可下载包的完整性和真实性的信息,或获取我们的公共 GnuPG 构建密钥的副本,请参阅
使用 GnuPG 进行签名检查
。
由于 GnuPG 密钥更新,配置为使用的系统
repo.mysql.com
在升级到 MySQL 5.7.37 及更高版本或使用
apt
或
升级到 MySQL 8.0.28 及更高版本时可能会报告签名验证错误
yum
。使用以下方法之一解决此问题:
从https://mysql.net.cn/downloads/
手动重新安装 MySQL APT 或 YUM 存储库设置包
下载 MySQL GnuPG 公钥并将其添加到您的系统 GPG 密钥环中。
有关 MySQL APT 存储库说明,请参阅
附录 A:手动添加和配置 MySQL APT 存储库
。
有关 MySQL YUM 存储库说明,请参阅
使用 MySQL Yum 存储库升级 MySQL
。
只支持
ALGORITHM=INSTANT
修改数据字典中元数据的操作。表数据不受影响,使操作即时进行。如果未明确指定,
ALGORITHM=INSTANT
则默认由支持它的 DDL 操作使用。
有关此操作和支持的其他 DDL 操作的更多信息
ALGORITHM=INSTANT
,请参阅
在线 DDL 操作
。
理论上,具有足够权限的用户可以使用 MySQL Enterprise Audit 错误地在审计日志过滤器中创建一个
“
中止
”
项目,以防止他们自己和其他管理员访问系统。从 MySQL 8.0.28 开始,
AUDIT_ABORT_EXEMPT
可以使用特权来允许用户帐户的查询始终执行,即使
“
中止
”
项会阻止它们也是如此。因此,具有此权限的帐户可用于在审计配置错误后重新获得对系统的访问权限。该查询仍记录在审计日志中,但由于特权而被允许,而不是被拒绝。
在 MySQL 8.0.28 或更高版本中创建的具有
SYSTEM_USER
权限的
帐户在创建
AUDIT_ABORT_EXEMPT
时会自动分配权限。
当您使用 MySQL 8.0.28 或更高版本执行升级过程时,如果现有帐户没有
分配该权限,该
AUDIT_ABORT_EXEMPT
权限也会分配给具有该权限的现有帐户。
SYSTEM_USER
该
tmp_table_size
变量现在定义了由 TempTable 存储引擎创建的单个内存内部临时表的最大大小。适当的大小限制可防止单个查询消耗过多的全局 TempTable 资源。请参阅
内部临时表存储引擎
。
该
innodb_open_files
变量定义了
InnoDB
一次可以打开的文件数,现在可以在运行时使用一条
语句进行设置。该语句执行设置新限制的存储过程。
SELECT
innodb_set_open_files_limit(
N
)
为了防止非 LRU 管理文件消耗整个
innodb_open_files
限制,非 LRU 管理文件现在限制为限制的 90%
innodb_open_files
,这为 LRU 管理文件保留了 10% 的
innodb_open_files
限制。
该
innodb_open_files
限制现在包括临时表空间文件,这些文件以前不计入限制。
函数
FROM_UNIXTIME()
、
UNIX_TIMESTAMP()
和
CONVERT_TZ()
现在在支持它们的平台上处理 64 位值,包括 64 位版本的 Linux、MacOS 和 Windows。
在兼容平台上,
FROM_UNIXTIME()
现在接受最大参数 32536771199.999999 秒,对应于
'3001-01-18 23:59:59.999999'
UTC(包括最多 6 位的可选小数)。如果参数大于此值,则函数返回
NULL
。
在兼容平台上,
UNIX_TIMESTAMP()
现在接受 UTC 的最大值
'3001-01-18
23:59:59.999999'
,对应于自 Unix 纪元以来的 32536771199.999999 秒。如果参数大于此值,则函数返回
0
。
此外,在兼容平台上,
CONVERT_TZ()
现在执行超过 2038 的时区转换,最高可达
'3001-01-18
23:59:59.999999'
UTC。如果 datetime 参数超过此值,则返回不变的参数。这种
“
无操作
”
行为与以前使用
'2038-01-19 03:14:07.999999'
UTC 以外的值时的行为相同。
这 3 个函数在 32 位平台上的行为没有改变。
该
TIMESTAMP
类型的行为也不受此更改的影响;
'2038-01-19 03:14:07.999999'
无论平台如何,其最大允许值仍为UTC。对于未来的日期,请改用 MySQL
DATETIME
类型。
此版本在全局和每个用户的基础上引入了内存分配的监控和限制。您现在可以通过检查
Global_connection_memory
状态变量的值来观察所有用户连接消耗的总内存,该变量必须通过设置启用
global_connection_memory_tracking =
总数包括系统进程或 MySQL root 用户使用的内存,尽管这些用户不会因内存使用而断开连接。
缓冲池使用的内存
InnoDB
不包括在总数中。
您可以通过调整间接控制状态变量的更新频率
connection_memory_chunk_size
;
Global_connection_memory
仅当总内存使用量变化超过此数量时才会更新。
您可以通过设置指定每个用户连接的资源消耗限制
connection_memory_limit
;内存使用量超过此数量的任何用户都不能发出额外的查询。您还可以通过设置来施加全局内存限制
global_connection_memory_limit
。每当
Global_connection_memory
超过全局限制时,任何普通用户都不能发出需要内存使用的新查询。MySQL root 等系统用户不受这些限制的约束。
InnoDB:
在索引创建操作期间计算的最小 I/O 缓冲区大小与 I/O 块大小不一致,允许记录超出缓冲区边界。(缺陷号 33570629)
InnoDB:
信号量死锁检查器在调试版本中使用
的
sync_array_detect_deadlock
算法在代码和时间复杂度方面得到了简化,并引入了该算法的实现以用于发布版本。(缺陷号 33538505)
InnoDB:
源中
的
ut::make_unique
库函数
InnoDB
现在允许指定分配的字段类型。(缺陷号 33538461)
InnoDB:
添加了一个 Performance Schema 工具来跟踪重做日志缓冲区内存分配。(缺陷号 33527660)
InnoDB:
打印到错误日志中的长时间信号量等待的警告未提供有关锁存器所有者的信息。(缺陷号 33509386)
InnoDB:
引入了闩锁释放和重新获取机制,以减少线程在受全局锁系统闩锁保护的临界区中花费的时间。(错误#33502610,错误#33563523)
InnoDB:
Windows 上的打孔操作导致失败。该操作作为重叠(异步)操作执行,它需要一个
OVERLAPPED
包含事件对象句柄的结构。
OVERLAPPED
没有提供结构。
(缺陷号 33496778)
InnoDB:
源代码中
的
ut_time()
基础设施
InnoDB
被类型检查的标准库实现所取代。(错误号 33460092)
InnoDB:
许多
尝试访问丢失的表空间
错误在恢复操作后被打印到错误日志中。(缺陷号 33437625)
InnoDB:
性能模式感知
ut::make_unique
和
ut::make_shared
内存管理库函数被添加到
InnoDB
源代码中。为具有扩展对齐的类型添加了类似的函数 (
ut::make_unique_aligned
和
ut::make_shared_aligned
(缺陷号 33420694)
InnoDB:
优化了源代码中
的
buf_validate()
函数
InnoDB
,提高了调试构建的性能。
感谢 Hobert Lu 的贡献。(错误#33417058,错误#104967)
InnoDB:
在启用NUMA的系统上,分配给缓冲池的内存块的页面大小在某些情况下与系统页面大小不一致,导致以下错误:
无法将缓冲池页面帧的NUMA内存策略设置为MPOL_INTERLEAVE
。(缺陷号 33406701)
参考资料:此问题是 Bug #32714144 的回归。
InnoDB:
源中的
std::unique_ptr
with
现在使用包装器,它使用无状态函数对象而不是指向函数的指针。(缺陷号 33405520)
mem_heap
InnoDB
Scoped_heap()
InnoDB:
结构中
的
m_end_range
标志在
prebuilt
填充预取缓存时超出范围末尾时设置为 true,在重置(初始化)预取缓存时未设置为 false。因此,在未超出范围末尾且处理程序被重用的
m_end_range
情况下,下次使用完美缓存时可能会错误地设置标志。(缺陷号 33384537)
InnoDB:
在表导入操作期间丢弃表的表空间后,将新表 ID 分配给表时,数据字典中的列元数据未更新。(缺陷号 33319149)
InnoDB:
将
innodb_interpreter
仅调试系统变量设置为
NULL
导致失败。(缺陷号 33316661)
InnoDB:
改进了全文索引创建文件管理。(缺陷号 33270893)
InnoDB:
将新行插入用于聚合的临时表的更新操作导致将临时表移动到磁盘,并在新的磁盘临时表上重试更新操作。在将临时表移动到磁盘之前准备的记录数据中的 BLOB 指针呈现为陈旧,从而导致失败。(缺陷号 33242407)
InnoDB:
内存分配现在由与 Performance Schema 兼容的新的符合标准的自定义内存分配器执行。(缺陷号 33159210)
InnoDB:
尝试取消初始化和初始化同一个表的统计信息的线程之间的竞争条件引发和断言失败。(缺陷号 33135425)
InnoDB:
innodb_flush_log_at_trx_commit
不是 1 或长时间运行的事务可能导致重做日志刷新率不一致。(缺陷号 33128461)
InnoDB:
大页面的分配现在由专为处理此问题而设计的库处理。在无法使用大页面分配机制的情况下,回退机制会分配常规对齐的页面。当大页面地址空间耗尽时,当底层硬件或操作系统架构禁用大页面支持时,或者当 MySQL 中的大页面支持被显式禁用时,可能会发生回退 (
--large-pages=0
)。用于分配和释放大页面的
ut_allocator
函数已被新的库函数取代。(错误#33119009、错误#33118309、错误#33149501、错误#32135935)
InnoDB:
处理常规 4K 页面对齐分配现在由与性能模式兼容的独立库执行。(缺陷号 33118362)
InnoDB:
属于
InnoDB
负责适当对齐类型的动态存储管理的新库的函数已经取代了以前用于此目的的函数。(缺陷号 33110341)
InnoDB:
适当对齐类型的动态分配现在由与 Performance Schema 兼容的库处理。(缺陷号 33110312)
InnoDB:
当清除线程在清除批处理结束时释放 LOB 页面时,释放了所需的索引数据结构,导致失败。(缺陷号 32918325)
InnoDB:
解决了动态内存管理功能(
ut_*
功能)的性能架构检测逻辑的不一致问题。(漏洞#32715466)
InnoDB:
InnoDB
动态分配例程限制阻止了可构造类型数组的动态分配。限制已得到解决,允许分配默认可构造类型、非默认可构造类型以及默认和非默认可构造类型。(缺陷号 32714047)
InnoDB:
当使用
READ COMMITTED
or
READ UNCOMMITTED
时,在触发器或函数内的表上执行的某些查询会阻止同一表上的并发事务。获得的锁限制太多。(缺陷号 32636792)
InnoDB:
对于加密和压缩的表空间页面、Windows 上的大多数页面以及未实现 Microsoft 卷管理功能的 Windows 卷,打孔功能未按预期工作。(缺陷号 32136255)
InnoDB:
用MySQL 8.0.28 中
ut_time()
的类型检查标准库 (
替换
std
回归是由于
std
时钟使用的时间库,它生成系统调用。现在改用低分辨率时钟。(错误#107763,错误#34352870)
参考资料:此问题是 Bug #33460092 的回归。
在生成的列表达式中创建一个具有不确定函数的表应该是不可能的,但这并不是在所有情况下都强制执行的;可以使用一系列一个或多个
ALTER TABLE
语句来得到一个分区表,其中包含一个或多个此类生成的列。当试图执行
CREATE TABLE
运行而获得的语句
SHOW CREATE TABLE
时,MySQL 拒绝了该语句,并带有一条误导性错误消息,该错误消息指的是分区表达式而不是有问题的列,尽管分区表达式本身是合法的。
这是由于检查为生成的列定义的任何不安全表达式(在内部变量中
thd->safe_to_cache_query
)的结果,后来在解析分区表达式时再次检查而没有被清除,即使分区表达式没有被清除也会导致错误请参考有问题的生成列表达式。
thd->safe_to_cache_query
现在在这种情况下,我们在解析分区函数之前
允许在生成的列中使用某些非确定性函数 (
AES_ENCRYPT()
,
AES_DECRYPT()
,
RANDOM_BYTES()
) 的问题是单独处理的。(缺陷号 29268656)
参考资料:另请参阅:Bug #32592320。
使用索引而非分区表主键的查询有时会导致 CPU 负载过大。(错误#104576,错误#33238010)
在检查性能模式复制组成员统计表时,组复制可能会在自动重新加入过程中意外停止。现在可以正确处理操作的并发性。(缺陷号 33609089)
组复制选择组成员作为分布式恢复的捐赠者的过程涉及使用为操作系统定义的标准随机选择器。如果这个随机设备不可用并抛出异常,则加入成员的加入过程停止。Group Replication 现在考虑了这种可能性,并在操作系统返回错误时使用回退随机选择器。(缺陷号 33596124)
复制:
PURGE BINARY LOGS
当实例被锁定以进行备份时,可以发出
一条当 LOCK INSTANCE FOR BACKUP 语句生效时,现在不能使用该语句。(缺陷号 33437026)
该
STOP GROUP_REPLICATION
语句停止组成员上的异步复制通道,但它不会像以前那样隐式提交正在进行的事务
STOP REPLICA
。这是因为在 Group Replication 组成员上,在关闭操作期间提交的额外事务会使成员与组不一致并导致重新加入问题。操作完成后,服务器处于只读状态。这种情况导致在停止 Group Replication 时正在进行的事务提交失败,因此为了避免这些情况,
STOP
GROUP_REPLICATION
现在不能在 GTID 被分配为
gtid_next
系统变量。(漏洞#33412483)
使用组复制的自动重新加入程序重新加入组的被驱逐的组成员过早地将其状态报告为正在恢复,而它仍在从其他组成员收集信息并且在兼容性检查完成之前。状态更改现在在安装视图时执行,这是重新加入的成员实际被接受为组成员的时间点。(缺陷号 33380840)
如果表或数据库的名称超过 64 个字节,则在读取表映射事件时复制会因错误而停止 - 限制为 64 个字符,因此使用多字节字符可能会导致这种情况。副本现在不再检查表和数据库名称的大小,并支持传输更长的名称。(错误#33305975,错误#104798)
如果在执行
replication_applier_status_by_worker
时查询
STOP REPLICA
。该问题现已解决。(缺陷号 33290947)
从 MySQL 8.0.26 开始,提供了实现半同步复制的新版本插件,将术语“主”和“从”替换为“源”和“副本”。在此之后,该
UNINSTALL
PLUGIN
语句错误地允许旧版本的插件,
rpl_semi_sync_master
并且
rpl_semi_sync_slave
在复制通道当前正在使用它们时被卸载。该问题现已解决。(缺陷号 33270401)
当在
PAD_CHAR_TO_FULL_LENGTH
副本服务器上启用 SQL 模式时,可以将尾随空格添加到复制元数据存储库表中的复制通道名称,从而导致识别使用该数据的通道的复制操作出错。该问题现已在 MySQL 8.0 中通过对字符列使用 VARCHAR 得到解决,在 MySQL 5.7 中通过在从这些表中读取时禁用 SQL 模式得到解决。感谢 Brian Yue 的贡献。(缺陷号 33213841)
如果副本在
SHOW
REPLICAS
发出语句时断开连接,则服务器能够访问已删除的数据。(错误#33206343,错误#104566)
Replication:
在Group Replication中,如果
SET gtid_next
在一个组成员上使用一条语句来为下一个事务设置GTID,那么同一个GTID可能被用于另一个成员上并发启动的事务。如果两个事务都达到提交阶段,则回滚总顺序中的第二个事务,解决这种情况。
group_replication_consistency
但是,当 Group Replication(系统变量)的事务一致性级别
BEFORE
或
BEFORE_AND_AFTER
时,成员可能会遇到死锁,其中一个成员持有 GTID 的所有权
gtid_owned
设置,另一个等待在提交事务之前释放所有权。wait 函数现在只考虑已提交事务的 GTID,而不考虑已拥有但未提交的 GTID,除非会话拥有同时提交的 GTID,在这种情况下,执行会话会出错。(错误#33051454,错误#104096)
如果设置了系统变量的副本服务器
replica_preserve_commit_order = 1
在密集负载下长时间使用,实例可能会用完提交顺序票证。超过最大值后的不正确行为导致应用程序挂起,应用程序工作线程无限期地等待提交顺序队列。提交顺序序列票证生成器现在可以正确环绕。感谢翟伟祥的贡献。(缺陷 #32891221,缺陷 #103636)
Group Replication(XCom,一种 Paxos 变体)的群组通信引擎现在会在现有群组成员难以与加入成员通信的情况下记录更多信息,例如由于网络问题。这可能导致该组记住加入成员的旧化身并且不允许它再次尝试加入。(缺陷号 32873315)
Replication:
Group Replication 的群组通信系统 (GCS) 现在在其被驱逐成员的记录中区分成功加入群组的成员和从未成功加入群组的成员。(缺陷号 32630484)
如果在启动或停止组复制时查询性能模式中的组复制组成员统计信息,则会发生竞争条件。(缺陷号 32392468)
如果复制源服务器发送的心跳事件包含二进制日志文件位置超过 4GB 偏移量,则复制接收器线程因错误而停止,因为二进制日志文件的大小很大。添加了正确处理较大值的新心跳事件(Heartbeat_log_event_v2,日志事件类型 41)以用于这种情况。(漏洞#29913991)
Microsoft Windows:
在 Windows 上,为 MySQL Server(商业)和 MySQL NDB Cluster(商业和社区)添加了缺少的调试和测试套件二进制文件。(缺陷号 32713189)
JSON:
当传递给的第一个参数
JSON_TABLE()
是一行而不是单个 JSON 值时,在尝试评估行表达式时会引发断言。如果第一个参数是行,我们通过在函数解析期间引发错误来解决此问题,以便永远不会评估行表达式本身。(缺陷号 33414235)
在生成列的表达式中使用
LPAD()
或
RPAD()
导致父表上的索引损坏。(缺陷号 33661337)
参考资料:另请参阅:Bug #32668730、Bug #33238711。
在某些发出警告的情况下,使用临时表的聚合结果中缺少行。(缺陷号 33603911)
对于 openSUSE 15,添加了 libtirpc rpcgen 构建要求
mysql.spec
以现在使用 TI-RPC。(缺陷号 33582982)
作用于多个表的
UPDATE
语句有时会在每次执行时向列表中添加元素。元素从未从此列表中删除,这增加了每次执行语句的内存占用。我们通过在执行后清除元素列表来解决这个问题。(缺陷号 33574408)
HOST
Performance Schema 表的列
大小
processlist
从 VARCHAR(255) 增加到 VARCHAR(261)。(缺陷号 33570218)
由于 OpenSSL 错误导致的密钥环迁移失败引发了断言。SSL 错误状态未从线程的 OpenSSL 错误队列中清除。(缺陷号 33546207)
进程列表函数调用导致失败。(漏洞#33511690)
商业 Debian 服务器包包含两个测试插件(component_test_page_track_component.so 和 component_test_global_priv_registration.so);他们被转移到单独的和可选的测试包中。(缺陷号 33504443)
对于 Fedora,将发布包版本号从 1 增加到 10;这有助于消除相同版本的本机 Fedora dnf/yum 包的潜在安装相关问题。(缺陷号 33504443)
将基于 Debian 的软件包的兼容级别提高到 11,因为之前的 9 级别已被弃用;并将对 dh_systemd_enable + dh_systemd_start 的调用替换为 dh_installsystemd 以满足兼容级别 10+ 的要求。(缺陷号 33458752)
涉及全文搜索查询的删除操作导致失败。(缺陷号 33455243)
使用
keyring_okv
插件时处理不当的错误导致启动失败。(缺陷号 33449117)
对于 Debian,向包添加
mysql-community-server
项,
mysql-community-server-debug
以便引入调试构建所需的所有必需包。(缺陷号 33426737)
对于 type 的虚拟生成列
DECIMAL
,我们现在总是存储一些数据,以便在尝试将字段缓冲区转换为十进制值时避免未定义的行为。(缺陷号 33424846)
当来自底层派生表的表达式包含由存储过程设置的变量时,MySQL 现在支持将条件下推到派生表。(缺陷号 33423394)
tls_version
和
admin_tls_version
设置现在验证服务器启动。(缺陷号 33390209)
该
admin_tls_version
变量接受了一个无效值。(缺陷号 33389818)
如果使用一条语句保留两个或更多已弃用的系统变量
SET PERSIST
,则在重新启动服务器时,只会为第一个已弃用的系统变量记录弃用警告。(缺陷号 33388488)
对于键部分相等的索引范围扫描,范围现在显示为相等。例如,
a = 3
现在显示,而不是
3 <= a <=
3
之前的这种变化。(漏洞#33351123)
对于配置文件,
不推荐
使用as用法
替换
/var/run
引用
的符号链接仍然保持当前设置的功能。(错误#33351110,错误#33588618)
/run
/var/run
tmpfiles.d
/var/run
/run
在具有特定配置的服务器上
执行
SHOW PROCESSLIST
或访问
导致失败。
INFORMATION_SCHEMA.PROCESSLIST
(缺陷号 33341623)
添加了从 ICU 错误代码
U_FILE_ACCESS_ERROR
到新 MySQL 错误代码的映射
ER_REGEXP_MISSING_FILE
。(缺陷号 33326003)
密钥环函数参数验证检查失败导致失败。(缺陷号 33319782)
使用 CMake 选项在 MySQL 源代码分发中禁用 Group Replication 插件
DWITH_GROUP_REPLICATION=0
不会禁用与 Group Replication 相关的应用程序和测试,这会导致它们构建错误。(缺陷号 33308513)
索引范围扫描迭代器并不总是按预期增加检查的行数。(缺陷号 33305632)
在命令行上启用
create_admin_listener_thread
系统变量可能会导致在特定错误条件下启动期间服务器退出。(缺陷号 33300587)
该
SUBSTR()
函数并不总是正确处理尝试评估其参数时引发的错误。(缺陷号 33290160)
Unicode 版本 67 的国际组件引入了一个新的实现
\X
(匹配一个字形簇),它需要 MySQL 当前不包含的区域设置数据。
这意味着,当使用与 MySQL 捆绑在一起的 ICU 版本时,使用的查询
\X
会引发错误
ER_REGEXP_MISSING_RESOURCE
;使用系统提供的 ICU 时,我们报告
ER_WARN_REGEXP_USING_DEFAULT
为注释。(缺陷号 33290090)
对存储在存储引擎中的表进行全文搜索查询,
BLACKHOLE
其中所选查询计划使用全文索引扫描导致错误,而不是返回空结果集。(缺陷号 33250020)
性能模式返回的
LOCK_TIME
未被评估,缺少行锁花费的时间,以及锁定多个表时花费的时间。截至本次发布,
LOCK_TIME
占:
一直在等待 SQL 表
一直在等待数据锁
LOCK_TIME
现在在慢速日志和性能模式中一致报告。(缺陷号 33236909)
如果当前会话在事务块内
\T
,则
mysql
客户端提示
的新选项会打印一个星号 ( )。
*
您可以将该选项与
--prompt
命令行选项、MySQL 选项文件或
MYSQL_PS1
环境变量一起使用。感谢 Murakami Kohei 的贡献。(错误#33214862,错误#104598)
表达式中的常量子查询
RANGE INTERVAL
并不总是能正确处理。(缺陷号 33197418)
评估为
NULL
的十进制表达式并不总是被正确处理。(缺陷号 33169048)
被授予具有全局
SELECT
权限的 MySQL 角色的用户帐户被拒绝访问
mysql
数据库。授予角色时未检查用户帐户的全局权限。(错误#33159353,错误#104423)
将 an 设置
Item_ref
为
SELECT
别名时,会复制其缓存的属性(包括它是否是
ROLLUP
表达式的一部分)。但是,这些可能尚未正确计算,因此应先进行计算,否则值可能是错误的。具有错误的值可能会导致某些表达式在不应该的中间步骤中实现(因为它们包含
ROLLUP
尚未准备好计算的表达式,但此时具有错误的值是未知的)。通过在将项目指定为汇总项目时强制重新计算缓存值来解决此问题。(错误#33149402,错误#104394)
将表从 MySQL 5.7 升级到 MySQL 8.0 时检测到无效注释字符串导致升级失败,并出现未提供足够上下文信息的错误。(缺陷号 33148961)
在某些情况下可以创建类型为 的生成列
SERIAL
,这是不允许的。
有关详细信息,请参阅
数字数据类型语法
和
CREATE TABLE 和生成的列
(缺陷号 33141966)
在触发器或存储函数中不允许隐式或显式提交事务的语句。
CREATE TRIGGER
在这种情况下,和
CREATE FUNCTION
应该报错 (
ER_COMMIT_NOT_ALLOWED_IN_SF_OR_TRG
) ,但没有正确处理
DROP TABLESPACE
. (缺陷号 33141958)
操作在用非常大的值定义
的
SHOW TABLE STATUS
表上运行时引发断言失败。
AVG_ROW_LENGTH
(缺陷号 33114368)
在计算可能从扫描中读取的最大行数时,中间结果是一个双精度数,它可能会大于 64 位无符号整数的最大允许值。这在将中间双精度值转换为整数时触发了未定义的行为,这在某些情况下可能会导致断言失败。
我们通过将结果限制在 [1,
UINT64_MAX
] 范围内来解决这个问题。(缺陷号 33066458)
UNION
在调试版本中同时使用和
LIMIT
0
触发断言失败的
查询。(缺陷号 33066455)
参考资料:此问题是 Bug #32302724 的回归。
使用重命名事件
ALTER EVENT ...
RENAME TO
不会删除原始事件的性能模式检测。(缺陷号 33059358)
使用线程池插件时,在调试版本上引发了 SSL 握手断言。(缺陷号 33012398)
一些使用一个
GROUP BY WITH
ROLLUP
或一个或多个窗口函数的准备好的语句只能成功执行一次。(缺陷号 33007266)
形式的语句发生错误
。执行此类语句时,服务器调用内部函数
以准备作为
别名创建的派生表;此函数填充
指向基础表的列的对象。
当插入到视图而不是表中时,未执行预期的转换,需要从
引用视图列映射到
表示基础表中相应列的转换。(缺陷号 32858783)
INSERT INTO
VALUE(
tuple
) AS
row_alias
(
id_list
)
Sql_cmd_insert_base::prepare_values_table()
VALUES
Sql_cmd_insert_base.values_field_list
Item_field
real_item()
Item_view_ref
Item_field
一些多重嵌套子选择没有正确处理,可能导致服务器意外关闭。(错误号 32547812)
在操作期间检查会话线程对象
SHOW
PROCESSLIST
以及对线程安全上下文的并发更改导致竞争条件。(错误#32320541,错误#102052)
在没有对 a 的结果执行任何操作的情况下
UNION
,行将被流式传输而不将它们存储在临时表中,尽管临时表的占位符仍然存在于查询块中。由于此表未实例化,因此在计算访问成本和优化基于范围的访问时,检查从表中读取行的成本估计会产生不可预测的结果。
在未实例化的临时表的情况下,我们通过跳过此类行估计的检索来解决此问题。(缺陷号 32255904)
使用公用表表达式的多表
DELETE
语句并不总是能正确处理。(缺陷号 32238558)
参考:此问题是 Bug #98330、Bug #30796015 的回归。
如果要将 a
CR_UNKNOWN_ERROR
发送给客户端,则可能会发生异常。(缺陷号 31933415)
修改了与 SSL 相关的代码以避免潜在的内存泄漏。(缺陷号 31933295)
在某些情况下,多表
UPDATE
语句可能会阻止并发访问。(缺陷号 31731752)
使用内部插槽进行复杂设置的密钥环系统变量不再接受
DEFAULT
. (缺陷号 30879700)
的
Timestamp
列
操作设置为零时间戳值 ( ) ,从而防止授权表的逻辑恢复。从 MySQL 8.0.28 开始,一个有效的开始时间值被写入时间戳列。
mysql.tables_priv
myql.columns_priv
"0000-00-00 00:00:00"
GRANT
REVOKE
如果现有授权表记录的时间戳值为零,这会阻止授权表的逻辑恢复,则解决方法是更新授权表或转储文件中的记录,将零时间戳值替换为
CURRENT_TIMESTAMP
.
感谢 Venkatesh Prasad Venugopal 的贡献。(错误#30863899,错误#98495)
与 MySQL 5.6 相比,在 MySQL 5.7 和 8.0 中使用
mysqldump
生成每表转储需要更长的执行时间。这是因为
mysqldump
information_schema.files
查询日志文件组信息的表
包含有关 InnoDB 数据文件以及来自 MySQL 5.7 的 NDB 数据文件的信息。在 MySQL 8.0 中,通过重写查询以仅选择适当的数据文件来解决此问题。在 MySQL 5.7 中,Information Schema 表没有索引,所以仍然需要进行全表扫描。(缺陷 #29210990,缺陷 #93875)
密钥环内存管理得到改进。(漏洞 #25042167)
FORCE INDEX FOR GROUP BY
在保存和恢复
FORCE INDEX
表格中提示的存在时,可能会设置
不正确的值。(错误#105694,错误#33604416)
sql_buffer_result
启用了系统变量的查询仅返回一行,并且尝试将结果插入表中,则设置临时表输出的错误可能会产生数据异常。(错误#105351,错误#33515752)
参考:这个问题是 Bug #33152269 的回归。
WindowIterator::Read()
在窗口输入结果集的末尾
未执行活动切片的重置
。这导致在到达
ORDER BY
排序时读取错误的值,因为活动切片的数量仍设置为 1,即从输入表中读取的项目,而
ORDER BY
排序阶段需要在计算任何值后读取值窗口函数。为此,它需要活动切片是最后一个窗口的输出表的切片。
我们通过在读取后立即将切片的重置移动到输出切片来解决此问题,以便在输入集末尾返回并继续进行排序时它已经正确设置。
感谢 Casa Zhang 和腾讯团队的贡献。(错误#105045,错误#33399696)
代码检查显示
strncpy()
在内部函数中
使用了 ,但
set_parse_error_message()
没有确保复制到的缓冲区的最后一个字节是空字节。我们通过使用
snprintf()
而不是来解决这个问题
strncpy()
; 这确保结果即使被截断也是有效的。(错误#104856,错误#33321787)
在执行激活使用
DEFINER
子句(或存储函数)创建的触发器的准备好的语句时,调用者权限用于检查表访问而不是定义者权限。反过来,这可能会导致对触发器或存储函数使用的表进行权限检查失败。(错误#104168,错误#33064461)
构造单例直方图时,其累积频率是通过将先前桶的频率与当前桶的频率相加来计算的;因为累加器使用了浮点值,所以有时会导致累积浮点数错误,最终累积频率略大于 1.0。
此修复程序改为使用整数类型累积频率,以避免出现中间浮点错误。
感谢 Casa Zhang 和腾讯团队的贡献。(错误#104108,错误#33045336)
index_condition_pushdown=ON
transaction_isolation='READ-COMMITTED'
时,在提交或回滚事务之前不会释放对二级索引的锁定,即使二级索引不匹配也是如此。(缺陷 #102722,缺陷 #32554667)
多值索引不用于从存储函数中执行的查询。(缺陷 #102359,缺陷 #32427727)
参考资料:另请参阅:Bug #104700、Bug #33268466。
具有此处所示形式的 SQL 语句发生错误:
INSERT INTO target_table
SELECT aggregate_expression, non_aggregate_expression
FROM empty_table;
当查询计划使用来自临时表的聚合时会发生这种情况,并且
non_aggregate_expression
在一次查询执行期间 when 是常量,但在执行之间可能会有所不同。例如,这样的表达式可能包括诸如
NOW()
or
之类的函数
USER()
。这导致临时表获得一列
non_aggregate_expression
,这是不必要的,因为所有行都具有相同的值。此外,如果没有行,则没有合法值可以插入到
target_table
中,这才是实际触发错误的原因。
我们通过在当前执行时
non_aggregate_expression
不
使用临时表列来解决此问题
。
const
(错误#102252、错误#32384355、错误#33546083)
当执行包含作为字符串传入的值的准备好的语句时,MySQL 会尝试将它们解析为整数,并可能返回与输入值无关的错误。
在最近的更改之后,动态参数处理被重构,以便根据上下文确定参数的派生数据类型。例如,在诸如
int_col
= ?
之类的比较中,参数的类型与其所比较的(整数)列相同。为了保持与现有 MySQL 应用程序的兼容性,如果提供了十进制或浮点值作为参数,则语句会自动重新准备,并根据实际值分配给参数的新类型。这种处理保留了数字参数的兼容性。
但是,如果提供了一个字符串参数,它仍然被解释为一个整数(已解析的数据类型),并且这种行为与检测到该值的实际类型的旧 MySQL 版本不兼容。结果是如果
int_col
=
?
用参数值执行
'1.7'
,只使用字符串的整数部分,进行有效比较
int_col
= 1
。
为解决此问题,现在在提供字符串参数时,系统会分析该参数以确定它是整数、小数还是浮点值,并相应地更新参数的实际数据类型。稍后,将实际类型与已解析类型进行比较,如果不兼容,则使用新的实际类型重新准备语句。因此,先前的语句现在评估为
int_col
= 1.7
并且比较使用十进制数进行评估。(错误#101806、错误#32213576、错误#103364、错误#32787037)