ANALYZE TABLE 失败，因为它会更新存储在数据字典中的表统计信息。ANALYZE TABLE fails because it updates table statistics, which are stored in the data dictionary.

ALTER TABLE tbl_name ENGINE=engine_name 失败，因为它会更新存储在数据字典中的存储引擎指定信息。ALTER TABLE tbl_name ENGINE=engine_name fails because it updates the storage engine designation, which is stored in the data dictionary.

以前，INFORMATION_SCHEMA 对 STATISTICS 和 TABLES 表中表统计信息的查询，是直接从存储引擎中获取统计信息的。从 MySQL 8.4 起，默认使用缓存的表统计信息。information_schema_stats_expiry 系统变量定义了缓存表统计信息过期前的时间周期。默认值是 86400 秒（24 小时）。(要随时更新指定表的缓存值，请使用 ANALYZE TABLE。) 如果没有缓存的统计信息或统计信息已过期，在查询表统计信息列时，统计信息会从存储引擎中获取。要始终直接从存储引擎获取最新统计信息，请将 information_schema_stats_expiry 设置为 0。更多信息，请参见 第 10.2.3 节，“优化 INFORMATION_SCHEMA 查询”。Previously, INFORMATION_SCHEMA queries for table statistics in the STATISTICS and TABLES tables retrieved statistics directly from storage engines. As of MySQL 8.4, cached table statistics are used by default. The information_schema_stats_expiry system variable defines the period of time before cached table statistics expire. The default is 86400 seconds (24 hours). (To update the cached values at any time for a given table, use ANALYZE TABLE.) If there are no cached statistics or statistics have expired, statistics are retrieved from storage engines when querying table statistics columns. To always retrieve the latest statistics directly from storage engines, set information_schema_stats_expiry to 0. For more information, see Section 10.2.3, “Optimizing INFORMATION_SCHEMA Queries”.

一些 INFORMATION_SCHEMA 表是数据字典表的视图，这使得优化器能够使用这些基础表上的索引。因此，根据优化器的选择，INFORMATION_SCHEMA 查询结果的行顺序可能与以前的结果不同。如果查询结果必须具有特定的行排序特性，请包含 ORDER BY 子句。Several INFORMATION_SCHEMA tables are views on data dictionary tables, which enables the optimizer to use indexes on those underlying tables. Consequently, depending on optimizer choices, the row order of results for INFORMATION_SCHEMA queries might differ from previous results. If a query result must have specific row ordering characteristics, include an ORDER BY clause.

对 INFORMATION_SCHEMA 表的查询可能返回的列名与早期 MySQL 系列中的字母大小写不同。应用程序应以不区分大小写的方式测试结果集列名。如果这不可行，一种解决方法是在选择列表中使用列别名以返回所需字母大小写的列名。例如：Queries on INFORMATION_SCHEMA tables may return column names in a different lettercase than in earlier MySQL series. Applications should test result set column names in case-insensitive fashion. If that is not feasible, a workaround is to use column aliases in the select list that return column names in the required lettercase. For example:

SELECT TABLE_SCHEMA AS table_schema, TABLE_NAME AS table_name
FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'users';

mysqldump 再也不会导出 INFORMATION_SCHEMA 数据库，即使在命令行中显式指定。mysqldump no longer dumps the INFORMATION_SCHEMA database, even if explicitly named on the command line.

CREATE TABLE dst_tbl LIKE src_tbl 要求 src_tbl 是基表，如果它是 INFORMATION_SCHEMA 表（即基于数据字典表的视图），则会失败。CREATE TABLE dst_tbl LIKE src_tbl requires that src_tbl be a base table and fails if it is an INFORMATION_SCHEMA table that is a view on data dictionary tables.

以前，从 INFORMATION_SCHEMA 表中选择的列的结果集标题会按照查询中指定的大小写显示。此查询生成的结果集标题为 table_name：Previously, result set headers of columns selected from INFORMATION_SCHEMA tables used the capitalization specified in the query. This query produces a result set with a header of table_name:

SELECT table_name FROM INFORMATION_SCHEMA.TABLES;

从 MySQL 8.4 开始，这些标题会使用大写；之前的查询生成的结果集标题为 TABLE_NAME。如有必要，可以使用列别名来实现不同的字母大小写。例如：As of MySQL 8.4, these headers are capitalized; the preceding query produces a result set with a header of TABLE_NAME. If necessary, a column alias can be used to achieve a different lettercase. For example:

SELECT table_name AS 'table_name' FROM INFORMATION_SCHEMA.TABLES;

mysqldump 仅导出该数据库中的非数据字典表，而之前可以导出 mysql 系统数据库中的所有表。mysqldump only dumps non-data dictionary tables in that database, when previously it was possible to dump all tables in the mysql system database.

以前，在使用 --all-databases 选项时，不需要使用 --routines 和 --events 选项来包含存储过程和事件：因为导出会包括 mysql 系统数据库，因此也会包括包含存储过程和事件定义的 proc 和 event 表。从 MySQL 8.4 开始，不再使用 event 和 proc 表。对应对象的定义存储在数据字典表中，但这些表不会被导出。要在使用 --all-databases 所做的导出中包含存储过程和事件，需要显式使用 --routines 和 --events 选项。Previously, the --routines and --events options were not required to include stored routines and events when using the --all-databases option: The dump included the mysql system database, and therefore also the proc and event tables containing stored routine and event definitions. As of MySQL 8.4, the event and proc tables are not used. Definitions for the corresponding objects are stored in data dictionary tables, but those tables are not dumped. To include stored routines and events in a dump made using --all-databases, use the --routines and --events options explicitly.

之前，--routines 选项需要对 proc 表具有 SELECT 权限。从 MySQL 8.4 开始，该表不再使用；--routines 现在需要全局 SELECT 权限。Previously, the --routines option required the SELECT privilege for the proc table. As of MySQL 8.4, that table is not used; --routines requires the global SELECT privilege instead.

之前，可以通过转储 proc 和 event 表来同时转储存储例程和事件定义及其创建和修改时间戳。从 MySQL 8.4 开始，这些表不再使用，因此无法转储时间戳。Previously, it was possible to dump stored routine and event definitions together with their creation and modification timestamps, by dumping the proc and event tables. As of MySQL 8.4, those tables are not used, so it is not possible to dump timestamps.