Documentation Home
MySQL 5.7 发行说明
MySQL 5.7 发行说明  /  MySQL 5.7.36 的变化（2021-10-19，正式发布）

MySQL 5.7.36 的变化（2021-10-19，正式发布）

安全说明

修正错误

  • 不兼容的更改： 对于视图上的所有SELECT语句，查询摘要基于视图定义。因此，不同的查询具有相同的摘要并在 Performance Schema 表中聚合在一起 events_statements_summary_by_digest，因此该表中的统计信息无法用于区分不同的SELECT语句。

    视图上每个SELECT 语句的查询摘要现在基于 SELECT，而不是视图定义。这使得能够区分 SELECT表中的不同语句 events_statements_summary_by_digest 。但是，使用查询摘要的工具可能需要进行一些调整以适应这种变化。例如，MySQL Enterprise Firewall 和查询重写插件依赖于查询摘要，而与视图关联的现有规则可能需要更新。（错误#27540213、错误#89559、错误#31761802）

  • InnoDB： 启用撤消日志截断（innodb_undo_log_truncate=ON）后，在从 MySQL 5.6 版本升级到 MySQL 5.7.34 或更早版本后启动撤消日志截断操作时，可能会发生死锁和最终失败。MySQL 5.7.35 中引入的补丁（错误号 32800020）解决了从 MySQL 5.6 直接升级到 MySQL 5.7.35 或更高版本的死锁问题，但对于从 MySQL 5.6 升级到 MySQL 5.7.34 或更早版本的实例，该问题仍然存在在升级到 MySQL 5.7.35 或更高版本之前。为了解决这个问题，现在可以识别有问题的 5.7.2 之前的回滚段插槽，并在启动时将其重置，并将类似于以下内容的消息写入错误日志： 

    [Note] InnoDB: Found duplicate reference rseg: 33 space: 1 page: 3
[Note] InnoDB: Reset pre-5.7.2 rseg: 1 after duplicate is found.

    如果 5.7.2 之前的回滚段槽没有要清除的撤消数据，则会发出类似于以下内容的消息： 

    [Note] InnoDB: Successfully reset 32 pre-5.7.2 rseg slots.

    如果在 5.7.2 之前的回滚段槽中发现撤消数据，则会发出类似于以下的消息，建议缓慢关闭并重新启动： 

    [Note] InnoDB: pre-5.7.2 rseg: 2 holds data to be purged.
History length: 1. Recommend slow shutdown with innodb_fast_shutdown=0 and restart

    （缺陷号 33181859）

  • InnoDB： 在活动事务使用期间截断撤消表空间引发断言失败。事务过早地标记为完成，允许截断操作。（缺陷号 33162828）

  • InnoDB： 删除或更新父表中的一行会在子表上启动级联SET NULL操作，将虚拟列值设置为 NULL。虚拟列值应该是从基列值派生的。

    感谢腾讯尹鹏的贡献。（缺陷号 33053297）

  • InnoDB： 恢复InnoDB过程没有识别出页面压缩已经应用于正在恢复的数据，导致表空间数据文件在重做日志应用阶段增加大小，这可能导致系统接近磁盘的恢复失败-满状态。（漏洞#32771259）

  • 复制： 在某些情况下，当自动定位所需的 GTID 已被清除时，MySQL 复制发出的错误消息可能会被错误分配或扰乱。（缺陷号 32965864）

  • 复制：gtid_executed和 gtid_purgedGTID 集 的内容在恢复使用mysqldump获取的转储后未保留。转储文件序列现在已更改，以便在 写入 GTID 集mysql架构（包含 mysql.gtid_executed表）为 mysqldumpgtid_purged添加了一个新选项它允许您选择根本不删除模式。（缺陷号 32843447）--skip-mysql-schemamysql

  • JSON：将值 转换JSON为文本会导致目标字符串线性增长，从而导致不必要的大量重新分配。现在这个过程使用指数增长来减少所需的分配数量。

    此修复程序最初出现在 MySQL 8.0 中，并由 Annirudh Prasad 反向移植到 MySQL 5.7，我们感谢他的贡献。（缺陷 #103790，缺陷 #32919524）

    参考资料：另请参阅：Bug #28949700。

  • 多张全文索引表的并发插入操作导致大量全文索引同步请求，导致内存不足。（错误#32831765，错误#103523）

  • 当查询使用临时表进行聚合时，group by item作为临时表的唯一约束：如果item值已经存在，则更新该行；否则，一个新行被插入到临时表中。如果项目有结果字段或引用项目，它会计算两次，一次是检查结果是否存在于临时表中，如果不存在，则在构造要插入的行时再次计算。当按项目分组不确定时，用于检查是否存在的结果值与尝试插入的结果值不同，如果该值已存在于表中，则会导致插入被拒绝。

    我们通过使用任何非确定性项目的散列作为唯一约束来解决这个问题，这样散列只被评估一次。（缺陷号 32552332）

  • SHOW GRANTS语句 的报价处理得到改进。（缺陷号 31716706）