MySQL8 中文参考（二十）（1）

原文：docs.oracle.com/javase/tutorial/reallybigindex.html

7.1.17 服务器端帮助支持

原文：dev.mysql.com/doc/refman/8.0/en/server-side-help-support.html

MySQL 服务器支持一个HELP语句，该语句从 MySQL 参考手册中返回信息（参见 Section 15.8.3, “HELP Statement”）。这些信息存储在mysql模式的几个表中（参见 Section 7.3, “The mysql System Schema”）。HELP语句的正确操作要求这些帮助表被初始化。

对于在 Unix 上使用二进制或源发行版进行 MySQL 的新安装，帮助表内容初始化发生在初始化数据目录时（参见 Section 2.9.1, “Initializing the Data Directory”）。对于 Linux 上的 RPM 发行版或 Windows 上的二进制发行版，内容初始化作为 MySQL 安装过程的一部分发生。

对于使用二进制发行版进行 MySQL 升级，截至 MySQL 8.0.16，帮助表内容会被服务器自动升级。在 MySQL 8.0.16 之前，内容不会自动升级，但你可以手动升级。在share或share/mysql目录中找到fill_help_tables.sql文件。进入该目录并使用mysql客户端处理文件，如下所示：

mysql -u root -p mysql < fill_help_tables.sql

此处显示的命令假定你使用具有修改mysql模式中表权限的帐户（如root）连接到服务器。根据需要调整连接参数。

在 MySQL 8.0.16 之前，如果你正在使用 Git 和 MySQL 开发源码树，源码树只包含一个“存根”版本的fill_help_tables.sql。要获取非存根版本，请使用源或二进制发行版中的一个。

注意

每个 MySQL 系列都有自己系列特定的参考手册，因此帮助表内容也是系列特定的。这对于复制有影响，因为帮助表内容应该与 MySQL  系列匹配。如果你将 MySQL 8.0 帮助内容加载到 MySQL 8.0 复制服务器中，将这些内容复制到来自不同 MySQL  系列且不适用于该内容的副本服务器是没有意义的。因此，当你在复制场景中升级单个服务器时，应该根据前面给出的说明升级每个服务器的帮助表。（只有低于  8.0.16 版本的复制服务器才需要手动升级帮助内容。如前述说明所述，从 MySQL 8.0.16 开始，内容升级会自动发生。）

7.1.18 服务器跟踪客户端会话状态

译文：dev.mysql.com/doc/refman/8.0/en/session-state-tracking.html

MySQL 服务器实现了几个会话状态跟踪器。客户端可以启用这些跟踪器以接收有关其会话状态更改的通知。

• 会话状态跟踪器的用途
  
• 可用的会话状态跟踪器
  
• C API 会话状态跟踪器支持
  
• 测试套件会话状态跟踪支持
  

会话状态跟踪器的用途

会话状态跟踪器有以下用途：

• 为了促进会话迁移。
  
• 为了促进事务切换。
  

跟踪机制提供了一个方法，使得 MySQL 连接器和客户端应用程序能够确定是否有任何会话上下文可用，以允许会话从一个服务器迁移到另一个服务器。（在负载平衡环境中更改会话时，需要检测是否有会话状态需要考虑，以便在决定是否可以进行切换时考虑。）

跟踪机制允许应用程序知道何时可以将事务从一个会话移动到另一个会话。事务状态跟踪使这成为可能，对于可能希望将事务从繁忙服务器移动到负载较轻的服务器的应用程序很有用。例如，管理客户端连接池的负载平衡连接器可以在池中的可用会话之间移动事务。

然而，会话切换不能在任意时间进行。如果一个会话正在进行读取或写入的事务，切换到另一个会话意味着在原始会话上进行事务回滚。只有在事务尚未在其中执行任何读取或写入时才能进行会话切换。

何时可以合理地切换事务的示例：

• 立即在START TRANSACTION之后
  
• 在COMMIT AND CHAIN之后
  

除了了解事务状态外，了解事务特性也很有用，以便在将事务移动到不同会话时使用相同的特性。以下特性对此很重要：

READ ONLY
READ WRITE
ISOLATION LEVEL
WITH CONSISTENT SNAPSHOT

可用的会话状态跟踪器

为了支持会话跟踪活动，可用于这些类型的客户端会话状态信息的通知：

• 客户端会话状态的这些属性的更改：

• 默认模式（数据库）。
  
• 系统变量的会话特定值。
  
• 用户定义变量。
  
• 临时表。
  
• 预处理语句。
  

• session_track_state_change 系统变量控制此跟踪。
  
• 默认模式名称更改。session_track_schema 系统变量控制此跟踪。
  
• 系统变量的会话值更改。session_track_system_variables 系统变量控制此跟踪。需要 SENSITIVE_VARIABLES_OBSERVER 权限来跟踪对敏感系统变量值的更改。
  
• 可用的 GTID。session_track_gtids 系统变量控制此跟踪。
  
• 有关事务状态和特性的信息。session_track_transaction_info 系统变量控制此跟踪。
  

有关与跟踪相关的系统变量的描述，请参阅 第 7.1.8 节，“服务器系统变量”。这些系统变量允许控制哪些更改通知发生，但不提供访问通知信息的方法。通知发生在 MySQL 客户端/服务器协议中，该协议在 OK 数据包中包含跟踪信息，以便检测会话状态更改。

C API 会话状态跟踪支持

为了使客户端应用程序能够从服务器返回的 OK 数据包中提取状态更改信息，MySQL C API 提供了一对函数：

• mysql_session_track_get_first() 获取从服务器接收的状态更改信息的第一部分。请参阅 mysql_session_track_get_first()。
  
• mysql_session_track_get_next() 从服务器接收的任何剩余状态更改信息。在成功调用 mysql_session_track_get_first() 后，只要它返回成功，就重复调用此函数。请参阅 mysql_session_track_get_next()。
  

测试套件会话状态跟踪支持

mysqltest 程序具有 disable_session_track_info 和 enable_session_track_info 命令，用于控制会话跟踪通知的发生。您可以使用这些命令从命令行查看 SQL 语句产生的通知。假设一个文件 testscript 包含以下 mysqltest 脚本：

DROP TABLE IF EXISTS test.t1;
CREATE TABLE test.t1 (i INT, f FLOAT);
--enable_session_track_info
SET @@SESSION.session_track_schema=ON;
SET @@SESSION.session_track_system_variables='*';
SET @@SESSION.session_track_state_change=ON;
USE information_schema;
SET NAMES 'utf8mb4';
SET @@SESSION.session_track_transaction_info='CHARACTERISTICS';
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SET TRANSACTION READ WRITE;
START TRANSACTION;
SELECT 1;
INSERT INTO test.t1 () VALUES();
INSERT INTO test.t1 () VALUES(1, RAND());
COMMIT;

运行以下脚本以查看已启用跟踪器提供的信息。有关mysqltest为各种跟踪器显示的Tracker:信息的描述，请参阅 mysql_session_track_get_first()。

$> mysqltest < testscript
DROP TABLE IF EXISTS test.t1;
CREATE TABLE test.t1 (i INT, f FLOAT);
SET @@SESSION.session_track_schema=ON;
SET @@SESSION.session_track_system_variables='*';
-- Tracker : SESSION_TRACK_SYSTEM_VARIABLES
-- session_track_system_variables
-- *
SET @@SESSION.session_track_state_change=ON;
-- Tracker : SESSION_TRACK_SYSTEM_VARIABLES
-- session_track_state_change
-- ON
USE information_schema;
-- Tracker : SESSION_TRACK_SCHEMA
-- information_schema
-- Tracker : SESSION_TRACK_STATE_CHANGE
-- 1
SET NAMES 'utf8mb4';
-- Tracker : SESSION_TRACK_SYSTEM_VARIABLES
-- character_set_client
-- utf8mb4
-- character_set_connection
-- utf8mb4
-- character_set_results
-- utf8mb4
-- Tracker : SESSION_TRACK_STATE_CHANGE
-- 1
SET @@SESSION.session_track_transaction_info='CHARACTERISTICS';
-- Tracker : SESSION_TRACK_SYSTEM_VARIABLES
-- session_track_transaction_info
-- CHARACTERISTICS
-- Tracker : SESSION_TRACK_STATE_CHANGE
-- 1
-- Tracker : SESSION_TRACK_TRANSACTION_CHARACTERISTICS
--
-- Tracker : SESSION_TRACK_TRANSACTION_STATE
-- ________
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- Tracker : SESSION_TRACK_TRANSACTION_CHARACTERISTICS
-- SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SET TRANSACTION READ WRITE;
-- Tracker : SESSION_TRACK_TRANSACTION_CHARACTERISTICS
-- SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; SET TRANSACTION READ WRITE;
START TRANSACTION;
-- Tracker : SESSION_TRACK_TRANSACTION_CHARACTERISTICS
-- SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; START TRANSACTION READ WRITE;
-- Tracker : SESSION_TRACK_TRANSACTION_STATE
-- T_______
SELECT 1;
1
1
-- Tracker : SESSION_TRACK_TRANSACTION_STATE
-- T_____S_
INSERT INTO test.t1 () VALUES();
-- Tracker : SESSION_TRACK_TRANSACTION_STATE
-- T___W_S_
INSERT INTO test.t1 () VALUES(1, RAND());
-- Tracker : SESSION_TRACK_TRANSACTION_STATE
-- T___WsS_
COMMIT;
-- Tracker : SESSION_TRACK_TRANSACTION_CHARACTERISTICS
--
-- Tracker : SESSION_TRACK_TRANSACTION_STATE
-- ________
ok

在START TRANSACTION语句之前，执行两个SET TRANSACTION语句，设置下一个事务的隔离级别和访问模式特性。SESSION_TRACK_TRANSACTION_CHARACTERISTICS值指示已设置的下一个事务值。

在结束事务的COMMIT语句之后，SESSION_TRACK_TRANSACTION_CHARACTERISTICS值报告为空。这表明在事务开始之前设置的下一个事务特性已被重置，并且会应用会话默认值。要跟踪这些会话默认值的更改，请跟踪transaction_isolation和transaction_read_only系统变量的会话值。

要查看有关 GTID 的信息，请使用session_track_gtids系统变量启用SESSION_TRACK_GTIDS跟踪器。

7.1.19 服务器关闭过程

原文：dev.mysql.com/doc/refman/8.0/en/server-shutdown.html

服务器关闭过程如下进行：

1. 关闭过程被启动。
   这可以通过多种方式来启动。例如，具有SHUTDOWN权限的用户可以执行mysqladmin shutdown命令。mysqladmin可以在 MySQL 支持的任何平台上使用。还有其他特定于操作系统的关闭启动方法：Unix 上的服务器在接收到SIGTERM信号时关闭。在 Windows 上作为服务运行的服务器在服务管理器告知时关闭。
   
2. 如果需要，服务器会创建一个关闭线程。
   根据关闭是如何启动的，服务器可能会创建一个线程来处理关闭过程。如果关闭是由客户端请求的，将创建一个关闭线程。如果关闭是由接收到SIGTERM信号导致的，信号线程可能会自行处理关闭，或者可能会创建一个单独的线程来处理。如果服务器尝试创建关闭线程但无法（例如，内存耗尽），它会发出出现在错误日志中的诊断消息：

Error: Can't create thread to kill server

1. 服务器停止接受新连接。
   为了在关闭过程中防止启动新活动，服务器通过关闭通常用于接受连接的网络接口的处理程序来停止接受新的客户端连接：TCP/IP 端口，Unix 套接字文件，Windows 命名管道以及 Windows 上的共享内存。
   
2. 服务器终止当前活动。
   对于与客户端连接相关的每个线程，服务器会断开与客户端的连接并将线程标记为已终止。线程在注意到自己被标记后会终止。空闲连接的线程会迅速终止。当前正在处理语句的线程会定期检查其状态并需要更长时间才能终止。有关线程终止的更多信息，请参见  Section 15.7.8.4, “KILL Statement”，特别是关于在MyISAM表上执行被终止的REPAIR TABLE或OPTIMIZE TABLE操作的说明。
   对于具有未完成事务的线程，事务将被回滚。如果一个线程正在更新一个非事务表，例如多行UPDATE或INSERT操作可能会导致表部分更新，因为操作可能在完成之前终止。
   如果服务器是一个复制源服务器，它会像对待其他客户端线程一样对待与当前连接的复制品相关的线程。也就是说，每个线程都被标记为已杀死，并在下次检查其状态时退出。
   如果服务器是一个复制服务器，在标记客户端线程为已杀死之前，它会停止复制  I/O 和 SQL 线程（如果它们是活动的）。SQL 线程被允许完成当前的语句（以避免引起复制问题），然后停止。如果此时 SQL  线程正在事务中，服务器会等到当前的复制事件组（如果有的话）执行完毕，或者直到用户发出KILL QUERY或KILL CONNECTION语句。另请参阅第 15.4.2.9 节，“STOP SLAVE Statement”。由于非事务性语句无法回滚，为了保证崩溃安全的复制，只能使用事务性表。
   注意
   为了保证复制品的崩溃安全性，必须使用--relay-log-recovery参数运行复制品。
   另请参阅第 19.2.4 节，“中继日志和复制元数据存储库”。
   
3. 服务器关闭或关闭存储引擎。
   在此阶段，服务器刷新表缓存并关闭所有打开的表。
   每个存储引擎执行其管理的表所需的任何操作。InnoDB将其缓冲池刷新到磁盘（除非innodb_fast_shutdown为 2），将当前 LSN 写入表空间，并终止其自己的内部线程。MyISAM刷新任何待处理的表的索引写入。
   
4. 服务器退出。
   

为了向管理进程提供信息，服务器返回以下列表中描述的退出代码之一。括号中的短语指示 systemd 对代码的响应动作，对于使用 systemd 管理服务器的平台。

• 0 = 成功的终止（未重启）
  
• 1 = 不成功的终止（未重启）
  
• 2 = 不成功的终止（已重启）
  

7.2 MySQL 数据目录

原文：dev.mysql.com/doc/refman/8.0/en/data-directory.html

MySQL 服务器管理的信息存储在一个称为数据目录的目录下。以下列表简要描述了通常在数据目录中找到的项目，并提供了额外信息的交叉引用：

• 数据目录子目录。数据目录的每个子目录都是一个数据库目录，对应于服务器管理的数据库。所有 MySQL 安装都有一些标准数据库：

• mysql 目录对应于 mysql 系统模式，其中包含 MySQL 服务器运行所需的信息。该数据库包含数据字典表和系统表。参见 第 7.3 节，“mysql 系统模式”。
  
• performance_schema 目录对应于性能模式，提供用于在运行时检查服务器内部执行的信息。参见 第二十九章，“MySQL 性能模式”。
  
• sys 目录对应于 sys 模式，提供了一组对象，以帮助更轻松地解释性能模式信息。参见 第三十章，“MySQL sys 模式”。
  
• ndbinfo 目录对应于存储特定于 NDB Cluster 的信息的 ndbinfo 数据库（仅适用于构建时包含 NDB Cluster 的安装）。参见 第 25.6.16 节，“ndbinfo: NDB Cluster 信息数据库”。
  

• 其他子目录对应于用户或应用程序创建的数据库。
  注意
  INFORMATION_SCHEMA 是一个标准数据库，但其实现不使用相应的数据库目录。
  
• 服务器写入的日志文件。参见 第 7.4 节，“MySQL 服务器日志”。
  
• InnoDB 表空间和日志文件。参见 第十七章，“InnoDB 存储引擎”。
  
• 默认/自动生成的 SSL 和 RSA 证书和密钥文件。参见 第 8.3.3 节，“创建 SSL 和 RSA 证书和密钥”。
  
• 服务器进程 ID 文件（服务器运行时）。
  
• 存储持久化全局系统变量设置的 mysqld-auto.cnf 文件。参见 第 15.7.6.1 节，“变量赋值的 SET 语法”。
  

先前列表中的某些项目可以通过重新配置服务器来重新定位。此外，--datadir 选项允许更改数据目录本身的位置。对于给定的 MySQL 安装，请检查服务器配置以确定是否已移动项目。

7.3 mysql 系统模式

原文：dev.mysql.com/doc/refman/8.0/en/system-schema.html

mysql模式是系统模式。它包含存储 MySQL 服务器运行所需信息的表。一个广泛的分类是，mysql模式包含存储数据库对象元数据的数据字典表，以及用于其他操作目的的系统表。以下讨论将系统表集进一步细分为更小的类别。

• 数据字典表
  
• 授权系统表
  
• 对象信息系统表
  
• 日志系统表
  
• 服务器端帮助系统表
  
• 时区系统表
  
• 复制系统表
  
• 优化器系统表
  
• 杂项系统表
  

本节的其余部分列举了每个类别中的表，附带了额外信息的交叉引用。数据字典表和系统表使用InnoDB存储引擎，除非另有说明。

mysql系统表和数据字典表存储在 MySQL 数据目录中名为mysql.ibd的单个InnoDB表空间文件中。以前，这些表是在mysql数据库目录中的单独表空间文件中创建的。

可以为mysql系统模式表空间启用数据静态加密。有关更多信息，请参见第 17.13 节，“InnoDB 数据静态加密”。

数据字典表

这些表包括数据字典，其中包含有关数据库对象的元数据。有关更多信息，请参见第十六章，MySQL 数据字典。

重要

数据字典是 MySQL 8.0 中的新功能。启用数据字典的服务器与之前的 MySQL  版本相比存在一些一般操作上的差异。有关详细信息，请参阅第 16.7 节，“数据字典使用差异”。此外，从 MySQL 5.7 升级到 MySQL  8.0，升级过程与之前的 MySQL 版本有所不同，并且需要您通过检查特定先决条件来验证安装的升级准备情况。有关更多信息，请参阅第三章，“升级  MySQL”，特别是第 3.6 节，“准备安装以进行升级”。

• catalogs: 目录信息。
  
• character_sets: 可用字符集的信息。
  
• check_constraints: 在表上定义的CHECK约束的信息。请参阅第 15.1.20.6 节，“CHECK 约束”。
  
• collations: 每个字符集的排序规则信息。
  
• column_statistics: 列值的直方图统计信息。请参阅第 10.9.6 节，“优化器统计信息”。
  
• column_type_elements: 列使用的类型信息。
  
• columns: 表中列的信息。
  
• dd_properties: 用于标识数据字典属性的表，例如其版本。服务器使用此信息来确定数据字典是否必须升级到更新版本。
  
• events: 事件调度器事件的信息。请参阅第 27.4 节，“使用事件调度器”。如果服务器使用--skip-grant-tables选项启动，则事件调度器将被禁用，并且在表中注册的事件不会运行。请参阅第 27.4.2 节，“事件调度器配置”。
  
• foreign_keys, foreign_key_column_usage: 外键信息。
  
• index_column_usage: 索引使用的列的信息。
  
• index_partitions: 索引使用的分区信息。
  
• index_stats: 用于存储执行ANALYZE TABLE时生成的动态索引统计信息。
  
• indexes: 表索引的信息。
  
• innodb_ddl_log: 存储崩溃安全的 DDL 操作的 DDL 日志。
  
• parameter_type_elements: 存储过程和函数参数以及存储函数返回值的信息。
  
• parameters: 存储过程和函数的信息。请参阅第 27.2 节，“使用存储过程”。
  
• resource_groups: 资源组的信息。请参阅第 7.1.16 节，“资源组”。
  
• routines: 关于存储过程和函数的信息。参见 Section 27.2, “Using Stored Routines”。
  
• schemata: 关于模式的信息。在 MySQL 中，模式是数据库，因此该表提供有关数据库的信息。
  
• st_spatial_reference_systems: 空间数据可用的空间参考系统信息。
  
• table_partition_values: 关于表分区使用的数值信息。
  
• table_partitions: 表使用的分区信息。
  
• table_stats: 当执行ANALYZE TABLE时生成的动态表统计信息。
  
• tables: 数据库中表的信息。
  
• tablespace_files: 表空间使用的文件信息。
  
• tablespaces: 活动表空间的信息。
  
• triggers: 触发器的信息。
  
• view_routine_usage: 视图和使用它们的存储函数之间的依赖关系信息。
  
• view_table_usage: 用于跟踪视图和其基础表之间的依赖关系。
  

数据字典表是不可见的。它们不能通过SELECT读取，不会出现在SHOW TABLES的输出中，不会在INFORMATION_SCHEMA.TABLES表中列出等等。然而，在大多数情况下，可以查询相应的INFORMATION_SCHEMA表。从概念上讲，INFORMATION_SCHEMA提供了 MySQL 公开数据字典元数据的视图。例如，您不能直接从mysql.schemata表中选择：

mysql> SELECT * FROM mysql.schemata;
ERROR 3554 (HY000): Access to data dictionary table 'mysql.schemata' is rejected.

相反，从相应的INFORMATION_SCHEMA表中选择该信息：

mysql> SELECT * FROM INFORMATION_SCHEMA.SCHEMATA\G
*************************** 1\. row ***************************
              CATALOG_NAME: def
               SCHEMA_NAME: mysql
DEFAULT_CHARACTER_SET_NAME: utf8mb4
    DEFAULT_COLLATION_NAME: utf8mb4_0900_ai_ci
                  SQL_PATH: NULL
        DEFAULT_ENCRYPTION: NO
*************************** 2\. row ***************************
              CATALOG_NAME: def
               SCHEMA_NAME: information_schema
DEFAULT_CHARACTER_SET_NAME: utf8mb3
    DEFAULT_COLLATION_NAME: utf8mb3_general_ci
                  SQL_PATH: NULL
        DEFAULT_ENCRYPTION: NO
*************************** 3\. row ***************************
              CATALOG_NAME: def
               SCHEMA_NAME: performance_schema
DEFAULT_CHARACTER_SET_NAME: utf8mb4
    DEFAULT_COLLATION_NAME: utf8mb4_0900_ai_ci
                  SQL_PATH: NULL
        DEFAULT_ENCRYPTION: NO
...

没有与mysql.indexes完全对应的信息模式表，但INFORMATION_SCHEMA.STATISTICS包含了大部分相同的信息。

到目前为止，还没有与mysql.foreign_keys、mysql.foreign_key_column_usage完全对应的INFORMATION_SCHEMA表。获取外键信息的标准 SQL 方法是使用INFORMATION_SCHEMA的REFERENTIAL_CONSTRAINTS和KEY_COLUMN_USAGE表；这些表现在作为foreign_keys、foreign_key_column_usage和其他数据字典表的视图实现。

MySQL 8.0 之前的一些系统表已被数据字典表取代，不再存在于mysql系统模式中：

• events数据字典表取代了 MySQL 8.0 之前的event表。
  
• parameters和routines数据字典表共同取代了 MySQL 8.0 之前的proc表。
  

MySQL8 中文参考（二十）（2）https://developer.aliyun.com/article/1566108