MySQL 8.0 现在已经超过四年了，Oracle 今天发布了最新的季度产品 MySQL 8.0.30，其中包含许多错误修复和一些有趣的附加功能。这是我对那些没有时间阅读它们的发行说明的看法，斜体评论是我的评论，仅反映我的观点。
这是一个有趣的版本，修复了很多错误，我敦促那些需要修复的人尽快升级。对于其他所有人来说，TL;DR 是，除非您使用 Oracle 云基础设施或某个已修复的错误导致您出现问题，否则请在闲暇时升级。
弃用和删除
现在不推荐将replica_parallel_workers 系统变量设置为0，而是使用单线程设置replica_parallel_workers=1 。 所以 1 是这个命令的新零？！
–skip_host_cache服务器选项已弃用，将在未来版本中删除。使用 SET GLOBAL host_cache_size = 0或设置 host_cache_size = 0 。
新的东西
没有主键的表对于 Oracle 的 MySQL 数据库服务来说是一个大问题，他们的云需要它们。以前版本的服务器添加了对不可见主键的支持以帮助解决该问题。现在我们得到 Generated Invisible Primary Keys (GIPK) 来自动向任何没有主键的 InnoDB 表添加一个不可见的主键。
GIPK 列定义为：
my_row_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT INVISIBLE PRIMARY KEY生成的主键总是命名为 my_row_id；当 GIPK 模式打开时，您无法更改此设置。您也不能在创建新 InnoDB 表的 CREATE TABLE 语句中将其用作列名，除非它包含显式主键。默认情况下不启用这些 GIPK。通过将 sql_generate_invisible_primary_key 服务器系统变量设置为ON来启用此新功能。复制不受影响，因为此设置对复制应用程序线程没有影响，因为副本永远不会为未在具有主键的源上创建的复制表生成主键。
只能使用ALTER TABLE tbl CHANGE COLUMN my_row_id SET VISIBLE和ALTER TABLE tbl CHANGE COLUMN my_row_id SET INVISIBLE 更改 GIPK以切换 GIPK 的可见性。GIPK 对 SHOW CREATE TABLE 和 SHOW INDEX 以及 information_schema 可见，但可以通过将 show_gipk_in_create_table_and_information_schema 设置为OFF来隐藏。我将不得不根据一般原则尝试基于生成的列jsut生成的不可见主键。
并且mysqldump和mysqlpump将通过设置 –skip-generated-invisible-primary-key选项跳过 GIPK。恢复时是否跳过了这些 GIPK，如果没有，这会产生多少额外的负载？
AWS 密钥环
更新后的keyring_aws插件现在可用于使用最新的 AWS Encryption SDK for C 版本 1.9.186。
SQL 语法说明
REVOKE 有两个新选项，可让您确定带有问题的 REVOKE 语句是引发错误还是警告。只要目标用户或角色不存在，IF EXISTS会导致REVOKE发出警告而不是错误，而如果目标用户或角色未知，则IGNORE UNKNOWN USER会导致REVOKE发出警告而不是错误。有很多区域可以设置错误或警告问题。
XA 事务修复
以前， 当复制拓扑中的服务器节点在执行 XA_PREPARE 、XA COMMIT或XA ROLLBACK时意外停止时，无法保证复制恢复。当服务器节点从拓扑中丢失然后重新加入时，MySQL 现在使用 MySQL“经典”复制或 MySQL 组复制在拓扑中保持一致的 XA 事务状态。这也意味着现在传播 XA 事务状态，以便在服务器节点停止、恢复和重新加入拓扑的情况下，节点在给定事务中工作时不会发生分歧。谁不喜欢更好的交易！
InnoDB 更改
innodb_doublewrite 系统变量获得了一对两个新设置，DETECT_ONLY和DETECT_AND_RECOVER 。使用DETECT_ONLY设置，数据库页面内容不会写入双写缓冲区，并且恢复不会使用双写缓冲区来修复不完整的页面写入。此轻量级设置仅用于检测不完整的页面写入。DETECT_AND_RECOVER设置等效于现有的ON设置。
重做日志现在具有动态配置容量的能力，使用 innodb_redo_log_capacity 系统变量在运行时设置以增加或减少重做日志文件占用的磁盘空间总量。重做日志有了新家！ InnoDB在数据目录的#innodb_redo目录中维护 32 个重做日志文件，而不是数据目录中的两个文件。我想知道将这 32 个文件移动到另一个驱动器会如何影响性能。我们真的可以恢复磁盘空间吗？
22.04 支持
现在支持 Ubuntu 22.04。
MySQL 模式
主机名和用户名列现在一起在主键的开头以避免全表扫描，表是mysql.db ，mysql.tables_priv ，mysql.columns_priv和mysql.procs_priv 正在重新排列，并且，当你升级时，这些表是在 MySQL 升级过程的第二步中修改的。
MyISAM
删除了 myisqm_repair_threads系统变量和myisamchk –parallel-recover选项。未来是 InnoDB，但我仍然对 MyISAM 有一些美好的回忆，并且讨厌看到工具被剥夺了功能。
谁先上
我写这些快速浏览的原因之一是让您不必阅读发行说明中的奇怪措辞，在这些措辞中，技术写作与工作日志注释相冲突，以创建诸如以下我直接引用的项目。
- 当 MySQL 服务器设置为离线模式时，用户具有CONNECTION_ADMIN权限的连接不会终止，这是通过将offline_mode系统变量的值更改为ON来完成的。以前，检查具有CONNECTION_ADMIN权限的连接可能会导致竞争条件，因为它涉及访问其他线程。现在，每个线程的标志缓存线程的用户是否具有CONNECTION_ADMIN权限。如果用户权限更改，则更新该标志。当为服务器激活离线模式时，会为每个线程检查此标志，而不是检查另一个线程的安全上下文。此更改使操作线程安全。此外，当离线模式被激活时，只有当运行该操作的用户也具有SYSTEM_USER权限时，其用户具有SYSTEM_USER权限的连接才会被终止。只有SYSTEM_VARIABLES_ADMIN权限且没有SYSTEM_USER权限的用户可以将offline_mode系统变量设置为ON以激活离线模式。但是，当他们运行该操作时，除了用户具有CONNECTION_ADMIN的任何会话之外，其用户具有SYSTEM_USER权限的任何会话仍保持连接状态特权。这仅适用于操作时的现有连接；具有SYSTEM_USER权限但没有CONNECTION_ADMIN权限的用户无法在离线模式下与系统建立新连接。
以上是我在商业法、符号逻辑和遥远过去的英语课堂作业后做的噩梦的混合体。阅读时我不得不拒绝制作流程图。
性能模式
Performance Schema为 Group Replication 内存使用的性能监控提供了工具。要偷看，请使用：
SELECT NAME, ENABLED FROM performance_schema.setup_instruments WHERE NAME LIKE'memory/group_rpl/%';大型机新闻
为 s390x 架构添加了循环定时器。
MySQL 8.0.31 应该会在 10 月下旬发布。
作者：David Stokes
文章来源：https://www.percona.com/blog/a-quick-peek-at-mysql-8-0-30/
