MySQL8-中文参考-四十六-

MySQL8 中文参考（四十六）

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

27.5.5 视图元数据

原文：dev.mysql.com/doc/refman/8.0/en/view-metadata.html

要获取有关视图的元数据：

• 查询INFORMATION_SCHEMA数据库的VIEWS表。参见第 28.3.48 节，“INFORMATION_SCHEMA VIEWS 表”。

• 使用SHOW CREATE VIEW语句。参见第 15.7.7.13 节，“SHOW CREATE VIEW 语句”。

27.6 存储对象访问控制

原文：dev.mysql.com/doc/refman/8.0/en/stored-objects-security.html

存储程序（过程、函数、触发器和事件）和视图在使用之前被定义，并且在引用时，在确定其权限的安全上下文中执行。适用于执行存储对象的权限由其DEFINER属性和SQL SECURITY特性控制。

• DEFINER 属性

• SQL 安全特性

• 示例

• 孤立存储对象

• 风险最小化指南

DEFINER 属性

存储对象定义可以包括一个DEFINER属性，用于指定一个 MySQL 账户。如果定义省略了DEFINER属性，那么默认的对象定义者是创建它的用户。

下列规则确定了你可以指定为存储对象DEFINER属性的账户：

• 如果你拥有SET_USER_ID权限（或已弃用的SUPER权限），你可以指定任何账户作为DEFINER属性。如果该账户不存在，将生成一个警告。此外，要将存储对象的DEFINER属性设置为具有SYSTEM_USER权限的账户，你必须拥有SYSTEM_USER权限。

• 否则，唯一允许的账户是你自己，可以明确指定为CURRENT_USER或CURRENT_USER()。你不能将定义者设置为其他账户。

使用不存在的DEFINER账户创建存储对象会创建一个孤立对象，可能会产生负面后果；参见孤立存储对象。

SQL 安全特性

对于存储例程（过程和函数）和视图，对象定义可以包括一个SQL SECURITY特性，其值为DEFINER或INVOKER，以指定对象是在定义者还是调用者上下文中执行。如果定义省略了SQL SECURITY特性，则默认为定义者上下文。

触发器和事件没有SQL SECURITY特性，始终在定义者上下文中执行。服务器根据需要自动调用这些对象，因此没有调用用户。

定义者和调用者安全上下文的区别如下：

• 在定义者安全上下文中执行的存储对象将以其DEFINER属性命名的帐户的特权执行。这些特权可能与调用用户的特权完全不同。调用者必须具有适当的特权来引用对象（例如，EXECUTE来调用存储过程或SELECT来从视图中选择），但在对象执行期间，调用者的特权将被忽略，只有DEFINER帐户的特权才重要。如果DEFINER帐户特权较少，则对象可以执行的操作也相应受限。如果DEFINER帐户具有高特权（例如管理帐户），则对象可以执行强大的操作无论谁调用它。

• 在调用者安全上下文中执行的存储过程或视图只能执行调用者具有特权的操作。DEFINER属性对对象执行没有影响。

例子

考虑以下存储过程，它声明为使用SQL SECURITY DEFINER在定义者安全上下文中执行：

CREATE DEFINER = 'admin'@'localhost' PROCEDURE p1()
SQL SECURITY DEFINER
BEGIN
  UPDATE t1 SET counter = counter + 1;
END;

任何具有p1的EXECUTE特权的用户都可以使用CALL语句调用它。但是，当p1执行时，它将在定义者安全上下文中执行，因此以其DEFINER属性命名的帐户'admin'@'localhost'的特权执行。此帐户必须对p1具有EXECUTE特权以及对对象体内引用的表t1具有UPDATE特权。否则，该过程将失败。

现在考虑这个存储过程，它与p1完全相同，只是其SQL SECURITY特性为INVOKER：

CREATE DEFINER = 'admin'@'localhost' PROCEDURE p2()
SQL SECURITY INVOKER
BEGIN
  UPDATE t1 SET counter = counter + 1;
END;

与p1不同，p2在调用者安全上下文中执行，因此以调用者的特权执行，而不管DEFINER属性值如何。如果调用者缺少p2的EXECUTE特权或表t1的UPDATE特权，则p2将失败。

孤立的存储对象

孤立的存储对象是指其DEFINER属性命名了一个不存在的帐户：

• 可以通过在创建对象时指定一个不存在的DEFINER帐户来创建孤立的存储对象。

• 通过执行DROP USER语句删除对象DEFINER帐户，或通过执行RENAME USER语句重命名对象DEFINER帐户，现有的存储对象可能变为孤立状态。

孤立的存储对象可能存在以下问题：

• 因为DEFINER帐户不存在，如果在定义者安全上下文中执行对象，则该对象可能无法按预期工作：

  • 对于存储过程，如果SQL SECURITY值为DEFINER但定义者帐户不存在，则在例程执行时会出现错误。

  • 对于触发器，直到帐户实际存在之前触发器激活并不是一个好主意。否则，关于权限检查的行为是未定义的。

  • 对于事件，如果帐户不存在，则在事件执行时会出现错误。

  • 对于视图，如果SQL SECURITY值为DEFINER但定义者帐户不存在，则在引用视图时会出现错误。

• 如果不存在的DEFINER帐户随后被重新创建用于与对象无关的目的，则该对象可能存在安全风险。在这种情况下，该帐户“接管”了对象，并且在具有适当权限的情况下，即使不打算如此，也能执行它。

从 MySQL 8.0.22 开始，服务器实施了额外的帐户管理安全检查，旨在防止（可能无意中）导致存储对象变为孤立或导致接管当前孤立的存储对象的操作：

• DROP USER如果要删除的任何帐户被命名为任何存储对象的DEFINER属性，则会出现错误。（也就是说，如果删除帐户会导致存储对象变成孤立状态，则该语句将失败。）

• RENAME USER如果要重命名的任何帐户被命名为任何存储对象的DEFINER属性，则会出现错误。（也就是说，如果重命名帐户会导致存储对象变成孤立状态，则该语句将失败。）

• CREATE USER如果要创建的任何帐户被命名为任何存储对象的DEFINER属性，则会出现错误。（也就是说，如果创建帐户会导致帐户接管当前孤立的存储对象，则该语句将失败。）

在某些情况下，可能需要故意执行那些帐户管理语句，即使它们本来会失败。为了实现这一点，如果用户具有SET_USER_ID权限，则该权限将覆盖孤立对象安全检查，并且语句将成功并显示警告，而不是失败并显示错误。

要获取有关在 MySQL 安装中用作存储对象定义者的帐户的信息，请查询INFORMATION_SCHEMA。

此查询标识了哪些INFORMATION_SCHEMA表描述具有DEFINER属性的对象：

mysql> SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.COLUMNS
       WHERE COLUMN_NAME = 'DEFINER';
+--------------------+------------+
| TABLE_SCHEMA       | TABLE_NAME |
+--------------------+------------+
| information_schema | EVENTS     |
| information_schema | ROUTINES   |
| information_schema | TRIGGERS   |
| information_schema | VIEWS      |
+--------------------+------------+

结果告诉您要查询哪些表以发现哪些存储对象DEFINER值存在以及哪些对象具有特定的DEFINER值：

• 要确定每个表中存在哪些DEFINER值，请使用以下查询：

  SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.EVENTS;
  SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.ROUTINES;
  SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.TRIGGERS;
  SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.VIEWS;
  

  查询结果对于任何显示为以下内容的帐户都很重要：

  • 如果账户存在，则删除或重命名它会导致存储对象变为孤立。如果计划删除或重命名账户，请首先考虑删除其关联的存储对象或重新定义它们以具有不同的定义者。

  • 如果账户不存在，则创建它会导致它接管当前孤立的存储对象。如果计划创建账户，请考虑是否应将孤立的对象与之关联。如果不需要，请重新定义它们以具有不同的定义者。

  要重新定义具有不同定义者的对象，可以使用ALTER EVENT或ALTER VIEW直接修改事件和视图的DEFINER账户。对于存储过程和函数以及触发器，必须删除对象并重新创建以分配不同的DEFINER账户。

• 要识别具有特定DEFINER账户的对象，请使用以下查询，将感兴趣的账户替换为*user_name*@*host_name*：

  SELECT EVENT_SCHEMA, EVENT_NAME FROM INFORMATION_SCHEMA.EVENTS
  WHERE DEFINER = '*user_name*@*host_name*';
  SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE
  FROM INFORMATION_SCHEMA.ROUTINES
  WHERE DEFINER = '*user_name*@*host_name*';
  SELECT TRIGGER_SCHEMA, TRIGGER_NAME FROM INFORMATION_SCHEMA.TRIGGERS
  WHERE DEFINER = '*user_name*@*host_name*';
  SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.VIEWS
  WHERE DEFINER = '*user_name*@*host_name*';
  

  对于ROUTINES表，查询包括ROUTINE_TYPE列，以便输出行区分DEFINER是存储过程还是存储函数。

  如果您正在搜索的账户不存在，则这些查询显示的任何对象都是孤立对象。

风险最小化准则

为了最大限度地减少存储对象创建和使用的风险潜力，请遵循以下准则：

• 不要创建孤立的存储对象；也就是说，DEFINER属性命名不存在的账户的对象。不要通过删除或重命名DEFINER属性命名的任何现有对象的账户来导致存储对象变为孤立。

• 对于存储过程或视图，在对象定义中尽可能使用SQL SECURITY INVOKER，以便它只能被具有适合对象执行操作权限的用户使用。

• 如果在具有SET_USER_ID权限（或已弃用的SUPER权限）的账户下创建定义者上下文存储对象，请指定一个显式的DEFINER属性，命名一个仅具有对象执行所需权限的账户。仅在绝对必要时指定高权限的DEFINER账户。

• 管理员可以通过不授予他们SET_USER_ID权限（或已弃用的SUPER权限）来防止用户创建指定高权限DEFINER账户的存储对象。

• 定义者上下文对象应该编写时考虑到它们可能能够访问调用用户没有权限的数据。在某些情况下，您可以通过不授予未经授权的用户特定权限来防止对这些对象的引用：

  • 未授予EXECUTE权限的用户无法引用存储过程。

  • 未授予适当权限的用户无法引用视图（需要SELECT从中选择，INSERT插入等）。

  然而，对于触发器和事件，不存在这样的控制，因为它们始终在定义者上下文中执行。服务器根据需要自动调用这些对象，用户不直接引用它们：

  • 触发器通过访问与其关联的表而被激活，即使是普通用户也可以访问没有特殊权限的表。

  • 事件由服务器定期执行。

  在这两种情况下，如果DEFINER账户权限很高，对象可能能够执行敏感或危险的操作。即使从创建对象所需的权限中撤销了创建者账户的权限，这仍然成立。管理员在授予用户对象创建权限时应格外小心。

• 默认情况下，当具有SQL SECURITY DEFINER特性的存储过程被执行时，MySQL 服务器不会为DEFINER子句中命名的 MySQL 账户设置任何活动角色，只有默认角色。例外情况是如果启用了activate_all_roles_on_login系统变量，此时 MySQL 服务器会设置所有授予DEFINER用户的角色，包括强制角色。因此，默认情况下，在发出CREATE PROCEDURE或CREATE FUNCTION语句时，不会检查通过角色授予的任何权限。对于存储程序，如果执行应该使用与默认不同的角色，则程序体可以执行SET ROLE来激活所需的角色。这必须谨慎进行，因为分配给角色的权限可能会更改。

27.7 存储程序二进制日志记录

原文：dev.mysql.com/doc/refman/8.0/en/stored-programs-logging.html

二进制日志包含有关修改数据库内容的 SQL 语句的信息。这些信息以描述修改的“事件”形式存储。（二进制日志事件与计划事件存储对象不同。）二进制日志有两个重要目的：

• 对于复制，二进制日志在源复制服务器上用作要发送到副本服务器的语句记录。源服务器将其二进制日志中包含的事件发送到其副本，副本执行这些事件以进行与源上进行的相同数据更改。请参阅 Section 19.2, “Replication Implementation”。

• 某些数据恢复操作需要使用二进制日志。在恢复备份文件后，将重新执行在备份文件生成后记录的二进制日志中的事件。这些事件将数据库从备份点更新到最新。请参阅 Section 9.3.2, “Using Backups for Recovery”。

然而，如果日志记录发生在语句级别，那么关于存储程序（存储过程和函数、触发器和事件）的二进制日志记录存在某些问题：

• 在某些情况下，一条语句可能会影响源和副本上的不同行集。

• 在副本上执行的复制语句由副本的应用程序线程处理。除非您实现了复制权限检查，这些权限从 MySQL 8.0.18 开始提供（请参阅 Section 19.3.3, “Replication Privilege Checks”），否则应用程序线程具有完全权限。在这种情况下，一个过程可能会在源服务器和副本服务器上遵循不同的执行路径，因此用户可以编写一个包含仅在副本上执行的危险语句的例程。

• 如果修改数据的存储程序是不确定性的，那么它就不可重复。这可能导致源和副本上的数据不同，或导致恢复的数据与原始数据不同。

本节描述了 MySQL 如何处理存储程序的二进制日志记录。它说明了实现对存储程序使用的当前条件，以及您可以采取什么措施避免日志记录问题。它还提供了关于这些条件原因的额外信息。

除非另有说明，这里的备注假定服务器上已启用二进制日志记录（参见第 7.4.4 节，“二进制日志”）。如果未启用二进制日志，则无法进行复制，也无法使用二进制日志进行数据恢复。从 MySQL 8.0 开始，默认启用二进制日志记录，只有在启动时指定 --skip-log-bin 或 --disable-log-bin 选项时才会禁用。

通常，描述的问题是在 SQL 语句级别发生二进制日志记录时（基于语句的二进制日志记录）产生的。如果使用基于行的二进制日志记录，日志将包含执行 SQL 语句导致的单个行的更改。当例程或触发器执行时，将记录行更改，而不是进行更改的语句。对于存储过程，这意味着 CALL 语句不会被记录。对于存储函数，将记录函数内部进行的行更改，而不是函数调用。对于触发器，将记录触发器进行的行更改。在副本端，只能看到行更改，而看不到存储程序调用。

混合格式二进制日志记录（binlog_format=MIXED）使用基于语句的二进制日志记录，除非只有基于行的二进制日志记录才能确保产生正确结果的情况。使用混合格式时，当存储函数、存储过程、触发器、事件或准备语句包含任何不适合基于语句的二进制日志记录的内容时，整个语句将被标记为不安全，并以行格式记录。用于创建和删除过程、函数、触发器和事件的语句始终是安全的，并以语句格式记录。有关基于行、混合和基于语句的日志记录以及如何确定安全和不安全语句的更多信息，请参见第 19.2.1 节，“复制格式”。

MySQL 中对存储函数使用的条件可以总结如下。这些条件不适用于存储过程或事件调度器事件，也不适用于未启用二进制日志记录的情况。

• 要创建或更改存储函数，您必须具有SET_USER_ID权限（或已弃用的SUPER权限），除了通常所需的CREATE ROUTINE或ALTER ROUTINE权限。 （根据函数定义中的DEFINER值，无论是否启用了二进制日志记录，可能需要SET_USER_ID或SUPER。请参阅第 15.1.17 节，“CREATE PROCEDURE and CREATE FUNCTION Statements”.）

• 创建存储函数时，必须声明其是确定性的或不修改数据。否则，可能对数据恢复或复制不安全。

  默认情况下，要接受CREATE FUNCTION语句，必须明确指定DETERMINISTIC、NO SQL或READS SQL DATA中的至少一个。否则会出现错误：

  ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL,
  or READS SQL DATA in its declaration and binary logging is enabled
  (you *might* want to use the less safe log_bin_trust_function_creators
  variable)
  

  此函数是确定性的（且不修改数据），因此是安全的：

  CREATE FUNCTION f1(i INT)
  RETURNS INT
  DETERMINISTIC
  READS SQL DATA
  BEGIN
    RETURN i;
  END;
  

  此函数使用UUID()，这是不确定性的，因此该函数也是不确定性的且不安全的：

  CREATE FUNCTION f2()
  RETURNS CHAR(36) CHARACTER SET utf8mb4
  BEGIN
    RETURN UUID();
  END;
  

  此函数修改数据，因此可能不安全：

  CREATE FUNCTION f3(p_id INT)
  RETURNS INT
  BEGIN
    UPDATE t SET modtime = NOW() WHERE id = p_id;
    RETURN ROW_COUNT();
  END;
  

  对函数性质的评估基于创建者的“诚实”。MySQL 不会检查声明为DETERMINISTIC的函数是否不包含产生非确定性结果的语句。

• 当您尝试执行存储函数时，如果设置了binlog_format=STATEMENT，则必须在函数定义中指定DETERMINISTIC关键字。如果没有这样做，将生成错误并且函数不会运行，除非指定log_bin_trust_function_creators=1以覆盖此检查（见下文）。对于递归函数调用，只有在最外层调用上才需要DETERMINISTIC关键字。如果使用基于行或混合二进制日志记录，则即使函数在没有DETERMINISTIC关键字的情况下定义，该语句也会被接受和复制。

• 因为 MySQL 在创建时不会检查函数是否真的是确定性的，所以带有DETERMINISTIC关键字的存储函数的调用可能执行对基于语句的日志记录不安全的操作，或调用包含不安全语句的函数或过程。如果在设置了binlog_format=STATEMENT时发生这种情况，则会发出警告消息。如果使用基于行或混合二进制日志记录，则不会发出警告，并且该语句以基于行的格式被复制。

• 放宽函数创建的先决条件（必须具有SUPER权限，并且函数必须声明为确定性或不修改数据），将全局log_bin_trust_function_creators系统变量设置为 1。默认情况下，此变量的值为 0，但您可以像这样更改它：

  mysql> SET GLOBAL log_bin_trust_function_creators = 1;
  

  您也可以在服务器启动时设置此变量。

  如果未启用二进制日志记录，则log_bin_trust_function_creators不适用。除非如前所述，函数定义中的DEFINER值要求，否则不需要SUPER权限来创建函数。

• 有关内置函数可能不安全用于复制（因此导致使用它们的存储函数也不安全）的信息，请参阅 Section 19.5.1, “Replication Features and Issues”。

触发器类似于存储函数，因此关于函数的先前备注也适用于触发器，唯一的例外是：CREATE TRIGGER没有可选的DETERMINISTIC特征，因此假定触发器始终是确定性的。但是，在某些情况下，这种假设可能是无效的。例如，UUID()函数是不确定性的（且不会复制）。在触发器中使用此类函数时要小心。

触发器可以更新表，因此如果没有所需权限，与存储函数类似的错误消息将在CREATE TRIGGER时出现。在副本端，副本使用触发器的DEFINER属性来确定哪个用户被视为触发器的创建者。

本节的其余部分提供了有关日志记录实现及其影响的额外细节。除非您对当前与存储例程使用相关的日志记录条件的背景感兴趣，否则无需阅读。此讨论仅适用于基于语句的日志记录，不适用于基于行的日志记录，除了第一项：CREATE和DROP语句无论日志记录模式如何都将作为语句记录。

• 服务器将CREATE EVENT、CREATE PROCEDURE、CREATE FUNCTION、ALTER EVENT、ALTER PROCEDURE、ALTER FUNCTION、DROP EVENT、DROP PROCEDURE和DROP FUNCTION语句写入二进制日志。

• 如果函数更改数据并且出现在否则不会被记录的语句中，则存储函数调用将被记录为SELECT语句。这可以防止由于在非记录语句中使用存储函数而导致的数据更改不被复制。例如，SELECT语句不会被写入二进制日志，但是SELECT可能调用一个进行更改的存储函数。为了处理这种情况，当给定函数进行更改时，将SELECT *func_name*()语句写入二进制日志。假设以下语句在源服务器上执行：

  CREATE FUNCTION f1(a INT) RETURNS INT
  BEGIN
    IF (a < 3) THEN
      INSERT INTO t2 VALUES (a);
    END IF;
    RETURN 0;
  END;
  
  CREATE TABLE t1 (a INT);
  INSERT INTO t1 VALUES (1),(2),(3);
  
  SELECT f1(a) FROM t1;
  

  当SELECT语句执行时，函数f1()被调用三次。其中两次调用插入一行，并且 MySQL 为每次插入都记录了一个SELECT语句。也就是说，MySQL 将以下语句写入二进制日志：

  SELECT f1(1);
  SELECT f1(2);
  

  当函数调用存储过程导致错误时，服务器还会记录一个SELECT语句。在这种情况下，服务器将SELECT语句与预期的错误代码一起写入日志。在副本中，如果发生相同的错误，那就是预期的结果，复制将继续。否则，复制将停止。

• 记录存储函数调用而不是函数执行的语句对复制有安全影响，这是由两个因素引起的：

  • 函数可能在源服务器和副本服务器上遵循不同的执行路径。

  • 在副本上执行的语句由副本的应用程序线程处理。除非您实现了复制权限检查，这在 MySQL 8.0.18 中可用（参见 Section 19.3.3, “Replication Privilege Checks”），否则应用程序线程具有完全权限。

  这意味着，尽管用户必须拥有 CREATE ROUTINE 权限才能创建函数，但用户可以编写一个包含危险语句的函数，只在复制品上执行，由具有完全权限的线程处理。例如，如果源服务器和复制品服务器的服务器 ID 值分别为 1 和 2，则源服务器上的用户可以创建并调用一个不安全的函数 unsafe_func() 如下：

  mysql> delimiter //
  mysql> CREATE FUNCTION unsafe_func () RETURNS INT
   -> BEGIN
   ->   IF @@server_id=2 THEN *dangerous_statement*; END IF;
   ->   RETURN 1;
   -> END;
   -> //
  mysql> delimiter ;
  mysql> INSERT INTO t VALUES(unsafe_func());
  

  CREATE FUNCTION 和 INSERT 语句被写入二进制日志，因此复制品会执行它们。由于复制品的应用程序线程拥有完全权限，它会执行危险的语句。因此，函数调用对源和复制品有不同的影响，不是复制安全的。

  为了防范启用了二进制日志记录的服务器的这种危险，存储函数创建者必须拥有 SUPER 权限，除了通常需要的 CREATE ROUTINE 权限。同样，要使用 ALTER FUNCTION，除了 ALTER ROUTINE 权限外，还必须拥有 SUPER 权限。如果没有 SUPER 权限，会出现错误：

  ERROR 1419 (HY000): You do not have the SUPER privilege and
  binary logging is enabled (you *might* want to use the less safe
  log_bin_trust_function_creators variable)
  

  如果不希望要求函数创建者拥有 SUPER 权限（例如，如果系统上所有具有 CREATE ROUTINE 权限的用户都是经验丰富的应用程序开发人员），请将全局 log_bin_trust_function_creators 系统变量设置为 1. 您也可以在服务器启动时设置此变量。如果未启用二进制日志记录，则 log_bin_trust_function_creators 不适用。除非如前所述，函数定义中的 DEFINER 值要求，否则不需要 SUPER 权限来创建函数。

• 建议无论您对函数创建者的权限做出何种选择，都使用可用的复制权限检查（从 MySQL 8.0.18 开始）。可以设置复制权限检查以确保仅授权复制通道的预期和相关操作。有关如何执行此操作的说明，请参见 Section 19.3.3, “Replication Privilege Checks”。

• 如果执行更新的函数是非确定性的，则不可重复。这可能会产生两个不良影响：

  • 它导致复制品与源不同。

  • 恢复的数据与原始数据不匹配。

  为了解决这些问题，MySQL 强制执行以下要求：在源服务器上，除非声明函数是确定性的或不修改数据，否则拒绝创建和修改函数。这里有两组函数特性：

  • DETERMINISTIC 和 NOT DETERMINISTIC 特性指示函数是否对给定输入始终产生相同的结果。如果没有给出任何特性，则默认为 NOT DETERMINISTIC。要声明函数是确定性的，必须明确指定 DETERMINISTIC。

  • CONTAINS SQL、NO SQL、READS SQL DATA 和 MODIFIES SQL DATA 特性提供了关于函数是否读取或写入数据的信息。NO SQL 或 READS SQL DATA 表明函数不会改变数据，但如果没有明确指定特性，则默认为 CONTAINS SQL。

  默认情况下，要接受CREATE FUNCTION语句，必须明确指定至少一个 DETERMINISTIC、NO SQL 或 READS SQL DATA。否则会出现错误：

  ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL,
  or READS SQL DATA in its declaration and binary logging is enabled
  (you *might* want to use the less safe log_bin_trust_function_creators
  variable)
  

  如果将log_bin_trust_function_creators设置为 1，则不再需要函数是确定性的或不修改数据的要求。

• 存储过程调用在语句级别而不是CALL级别记录。也就是说，服务器不会记录CALL语句，而是记录实际执行的过程中的语句。因此，在源服务器上发生的更改也会在副本上发生。这可以防止由于过程在不同机器上具有不同的执行路径而导致的问题。

  一般来说，在存储过程中执行的语句会按照在独立方式执行时应用的相同规则写入二进制日志。在记录过程语句时需要特别注意，因为过程内的语句执行与非过程上下文中的执行不完全相同：

  • 要记录的语句可能包含对本地过程变量的引用。这些变量在存储过程上下文之外不存在，因此引用这样一个变量的语句不能直接记录。而是为了记录目的，将每个对本地变量的引用替换为以下构造：

    NAME_CONST(*var_name*, *var_value*)
    

    var_name 是本地变量名称，var_value 是指示变量在记录语句时的值的常量。NAME_CONST() 的值为 var_value，“名称”为 var_name。因此，如果直接调用此函数，将获得如下结果：

    mysql> SELECT NAME_CONST('myname', 14);
    +--------+
    | myname |
    +--------+
    |     14 |
    +--------+
    

    NAME_CONST()使得可以在副本上执行一个已记录的独立语句，其效果与在源上执行的原始语句相同，而原始语句是在存储过程中执行的。

    使用NAME_CONST()可能会导致在CREATE TABLE ... SELECT语句中出现问题，当源列表达式引用本地变量时。将这些引用转换为NAME_CONST()表达式可能导致源服务器和副本服务器上的列名不同，或者列名过长而无法成为合法的列标识符。一个解决方法是为引用本地变量的列提供别名。考虑当myvar的值为 1 时的语句：

    CREATE TABLE t1 SELECT myvar;
    

    重写如下：

    CREATE TABLE t1 SELECT NAME_CONST(myvar, 1);
    

    为确保源和副本表具有相同的列名，应该这样写语句：

    CREATE TABLE t1 SELECT myvar AS myvar;
    

    重写后的语句如下：

    CREATE TABLE t1 SELECT NAME_CONST(myvar, 1) AS myvar;
    

  • 要记录的语句可能包含对用户定义变量的引用。为了处理这个问题，MySQL 在二进制日志中写入一个SET语句，以确保变量在副本上存在，并且具有与源相同的值。例如，如果一个语句引用变量@my_var，那么该语句在二进制日志中的前面会有以下语句，其中value是源上@my_var的值：

    SET @my_var = *value*;
    

  • 过程调用可以发生在已提交或已回滚的事务中。事务上下文被考虑，以便正确复制过程执行的事务方面。也就是说，服务器记录那些在过程中实际执行和修改数据的语句，并根据需要记录BEGIN、COMMIT和ROLLBACK语句。例如，如果一个过程只更新事务表，并在回滚的事务中执行，那些更新不会被记录。如果过程发生在已提交的事务中，BEGIN和COMMIT语句将与更新一起记录。对于在已回滚事务中执行的过程，其语句将使用与在独立方式下执行时相同的规则进行记录：

    • 对事务表的更新不会被记录。

    • 对非事务表的更新是被记录的，因为回滚不会取消它们。

    • 更新混合事务和非事务表的操作被记录在BEGIN和ROLLBACK之间，以便副本执行与源相同的更改和回滚。

• 如果存储过程是在存储函数内部调用的，则存储过程调用不会以语句级别写入二进制日志。在这种情况下，记录的仅是调用函数的语句（如果它出现在被记录的语句内部）或一个DO语句（如果它出现在未记录的语句内部）。因此，即使存储过程本身是安全的，也应谨慎使用调用存储过程的存储函数。

27.8 存储程序的限制

原文：dev.mysql.com/doc/refman/8.0/en/stored-program-restrictions.html

• 存储过程中不允许的 SQL 语句

• 存储函数的限制

• 触发器的限制

• 存储过程中的名称冲突

• 复制注意事项

• 调试注意事项

• 不支持的 SQL:2003 标准语法

• 存储过程并发性注意事项

• 事件调度程序的限制

• NDB Cluster 中的存储过程和触发器

这些限制适用于第二十七章，存储对象中描述的功能。

这里提到的一些限制适用于所有存储过程；即，既适用于存储过程也适用于存储函数。还有一些特定于存储函数的限制但不适用于存储过程。

存储函数的限制也适用于触发器。还有一些特定于触发器的限制。

存储过程的限制也适用于事件调度程序事件定义的DO子句。还有一些特定于事件的限制。

存储过程中不允许的 SQL 语句

存储过程不能包含任意的 SQL 语句。以下语句不允许：

• 锁定语句LOCK TABLES和UNLOCK TABLES。

• ALTER VIEW。

• LOAD DATA 和 LOAD XML。

• SQL 准备语句（PREPARE，EXECUTE，DEALLOCATE PREPARE。例外是 SIGNAL，RESIGNAL 和 GET DIAGNOSTICS，它们不允许作为准备语句，但允许在存储程序中。

• 由于局部变量仅在存储程序执行期间处于作用域内，因此在存储程序内创建的准备语句中不允许引用它们。准备语句的作用域是当前会话，而不是存储程序，因此该语句可能在程序结束后执行，此时变量将不再处于作用域内。例如，SELECT ... INTO *local_var* 不能作为准备语句使用。此限制也适用于存储过程和函数参数。请参见 Section 15.5.1, “PREPARE Statement”。

• 在所有存储程序（存储过程和函数，触发器和事件）中，解析器将 BEGIN [WORK] 视为 BEGIN ... END 块的开始。在此上下文中开始事务，请改用 START TRANSACTION。

存储函数的限制

在存储函数中不允许以下附加语句或操作。它们在存储过程中允许，除了从存储函数或触发器内调用的存储过程。例如，如果您在存储过程中使用 FLUSH，则该存储过程不能从存储函数或触发器中调用。

• 执行显式或隐式提交或回滚的语句。SQL 标准不要求支持这些语句，它规定每个 DBMS 供应商可以决定是否允许它们。

• 返回结果集的语句。这包括没有INTO *var_list*子句的SELECT语句以及其他语句，如SHOW、EXPLAIN和CHECK TABLE。函数可以使用SELECT ... INTO *var_list*或使用游标和FETCH语句处理结果集。请参见第 15.2.13.1 节，“SELECT ... INTO Statement”和第 15.6.6 节，“游标”。

• FLUSH语句。

• 存储函数不能递归使用。

• 存储函数或触发器不能修改已被调用函数或触发器的语句（用于读取或写入）中已经使用的表。

• 如果在存储函数中使用不同别名多次引用临时表，则会出现Can't reopen table: '*tbl_name*'`错误，即使引用出现在函数内的不同语句中也会发生。

• HANDLER ... READ语句调用存储函数可能导致复制错误，因此不允许。

`### 触发器的限制

对于触发器，以下附加限制适用：

• 触发器不会被外键操作激活。

• 在使用基于行的复制时，副本上的触发器不会被源上发起的语句激活。在使用基于语句的复制时，副本上的触发器会被激活。有关更多信息，请参见第 19.5.1.36 节，“复制和触发器”。

• RETURN语句不允许在触发器中使用，因为触发器不能返回值。要立即退出触发器，请使用LEAVE语句。

• 不允许在mysql数据库中的表上使用触发器。也不允许在INFORMATION_SCHEMA或performance_schema表上使用触发器。这些表实际上是视图，视图上不允许使用触发器。

• 触发器缓存无法检测基础对象的元数据是否发生了变化。如果触发器使用表，而表自加载触发器以来发生了变化，则触发器将使用过时的元数据运行。

存储例程内的名称冲突

相同的标识符可能用于例程参数、本地变量和表列。此外，相同的本地变量名称可以在嵌套块中使用。例如：

CREATE PROCEDURE p (i INT)
BEGIN
  DECLARE i INT DEFAULT 0;
  SELECT i FROM t;
  BEGIN
    DECLARE i INT DEFAULT 1;
    SELECT i FROM t;
  END;
END;

在这种情况下，标识符是模棱两可的，以下优先规则适用：

• 本地变量优先于例程参数或表列。

• 例程参数优先于表列。

• 内部块中的局部变量优先于外部块中的局部变量。

变量优先于表列的行为是非标准的。

复制考虑事项

使用存储例程可能会导致复制问题。此问题在第 27.7 节，“存储程序二进制日志记录”中进一步讨论。

--replicate-wild-do-table=*db_name.tbl_name* 选项适用于表、视图和触发器。不适用于存储过程和函数，或事件。要过滤操作后者对象的语句，请使用一个或多个 --replicate-*-db 选项。

调试考虑事项

没有存储例程调试设施。

来自 SQL:2003 标准的不支持语法

MySQL 存储例程语法基于 SQL:2003 标准。该标准中的以下项目目前不受支持：

• UNDO 处理程序

• FOR 循环

存储例程并发考虑事项

为了防止会话之间的交互问题，当客户端发出语句时，服务器使用可执行该语句的例程和触发器的快照。也就是说，服务器计算在执行语句期间可能使用的过程、函数和触发器列表，加载它们，然后继续执行语句。在语句执行时，它不会看到其他会话执行的例程的更改。

为了最大并发性，存储函数应最小化其副作用；特别是，在存储函数中更新表可能会减少对该表的并发操作。存储函数在执行之前获取表锁，以避免由于语句执行顺序不匹配和在日志中出现时导致二进制日志不一致。当使用基于语句的二进制日志记录时，调用函数的语句会被记录，而不是在函数内执行的语句。因此，更新相同基础表的存储函数不会并行执行。相反，存储过程不会获取表级锁。在存储过程中执行的所有语句都会写入二进制日志，即使是基于语句的二进制日志记录。参见第 27.7 节，“存储程序二进制日志记录”。

事件调度程序限制

以下限制特定于事件调度程序：

• 事件名称以不区分大小写的方式处理。例如，不能在同一数据库中使用名称为 anEvent 和 AnEvent 的两个事件。

• 不能在存储过程内创建事件。如果事件名称是通过变量指定的，则不能在存储过程内更改或删除事件。事件也不能创建、更改或删除存储例程或触发器。

• 在执行LOCK TABLES语句时，禁止对事件进行 DDL 语句。

• 使用YEAR、QUARTER、MONTH和YEAR_MONTH间隔的事件时间以月为单位解析；使用其他任何间隔的事件时间以秒为单位解析。无法使安排在同一秒执行的事件按照给定顺序执行。此外，由于四舍五入、多线程应用程序的性质以及创建事件和信号其执行所需的非零时间，事件可能会延迟至多 1 或 2 秒。然而，在信息模式EVENTS表的LAST_EXECUTED列中显示的时间始终准确到实际事件执行时间的一秒内。（另请参见 Bug #16522。）

• 事件体中包含的语句的每次执行都在一个新连接中进行；因此，这些语句对服务器的语句计数（如Com_select和Com_insert）在给定用户会话中没有影响，这些计数是通过SHOW STATUS显示的。然而，这些计数在全局范围内是更新的。（Bug #16422）

• 事件不支持晚于 Unix 纪元结束的时间；这大约是 2038 年初。这些日期明确不被事件调度程序允许。（Bug #16396）

• 在CREATE EVENT和ALTER EVENT语句的ON SCHEDULE子句中引用存储函数、可加载函数和表格是不被支持的。这类引用是不允许的。（更多信息请参见 Bug #22830。）

NDB 集群中的存储过程和触发器

虽然NDB存储引擎支持表格使用存储过程、存储函数、触发器和定时事件，但你必须记住这些在充当集群 SQL 节点的 MySQL 服务器之间不会自动传播。这是因为存储过程和触发器定义存储在InnoDB表格中的mysql系统数据库中，这些表格在集群节点之间不会被复制。

与 MySQL Cluster 表交互的任何存储过程或触发器都必须通过在参与使用存储过程或触发器的每个 MySQL 服务器上运行适当的CREATE PROCEDURE、CREATE FUNCTION或CREATE TRIGGER语句来重新创建。同样，对现有存储过程或触发器的任何更改都必须在所有 Cluster SQL 节点上显式执行，使用适当的ALTER或DROP语句在访问集群的每个 MySQL 服务器上执行。

警告

不要尝试通过将任何mysql数据库表转换为使用NDB存储引擎来解决刚才描述的问题。修改mysql数据库中的系统表不受支持，很可能会产生不良结果。

27.9 视图的限制

原文：dev.mysql.com/doc/refman/8.0/en/view-restrictions.html

在视图定义中引用的表的最大数量为 61。

视图处理未经优化：

• 不可能在视图上创建索引。

• 使用合并算法处理的视图可以使用索引。然而，使用 temptable 算法处理的视图无法利用其基础表的索引（尽管在生成临时表时可以使用索引）。

有一个普遍原则，即您不能在子查询中修改表并从同一表中进行选择。参见 Section 15.2.15.12, “子查询的限制”。

如果您从选择表的视图中选择，如果视图从子查询中选择表，并且使用合并算法评估视图，则也适用相同原则。例如：

CREATE VIEW v1 AS
SELECT * FROM t2 WHERE EXISTS (SELECT 1 FROM t1 WHERE t1.a = t2.a);

UPDATE t1, v2 SET t1.a = 1 WHERE t1.b = v2.b;

如果视图使用临时表进行评估，您可以从视图子查询中选择表，并在外部查询中修改该表。在这种情况下，视图存储在临时表中，因此您实际上并没有同时从子查询中选择表并修改它。（这是您可能希望通过在视图定义中指定 ALGORITHM = TEMPTABLE 强制 MySQL 使用 temptable 算法的另一个原因。）

您可以使用 DROP TABLE 或 ALTER TABLE 删除或更改视图定义中使用的表。即使这使视图无效，DROP 或 ALTER 操作也不会产生警告。相反，在使用视图时会稍后出现错误。可以使用 CHECK TABLE 来检查已被 DROP 或 ALTER 操作使无效的视图。

关于视图的可更新性，视图的总体目标是，如果任何视图在理论上是可更新的，那么在实践中它应该是可更新的。许多在理论上可更新的视图现在可以更新，但仍然存在限制。有关详细信息，请参见 Section 27.5.3, “可更新和可插入的视图”。

当前视图实现存在一个缺陷。如果用户被授予创建视图所需的基本权限（CREATE VIEW 和 SELECT 权限），那么该用户除非也被授予 SHOW VIEW 权限，否则不能调用 SHOW CREATE VIEW 查看该对象。

这个缺陷可能导致使用mysqldump备份数据库时出现问题，可能由于权限不足而失败。这个问题在 Bug #22062 中有描述。

解决这个问题的方法是管理员手动授予SHOW VIEW权限给被授予CREATE VIEW权限的用户，因为 MySQL 在创建视图时不会隐式授予该权限。

视图没有索引，因此索引提示不适用。在从视图中进行选择时，不允许使用索引提示。

SHOW CREATE VIEW使用AS *alias_name*子句显示视图定义中的每个列。如果列是从表达式创建的，则默认别名是表达式文本，可能会很长。在CREATE VIEW语句中，列名的别名会被检查是否超过 64 个字符的最大列长度（而不是 256 个字符的最大别名长度）。因此，如果任何列别名超过 64 个字符，则从SHOW CREATE VIEW输出创建的视图会失败。这可能会导致以下情况的问题，对于具有过长别名的视图：

• 视图定义无法复制到强制执行列长度限制的新副本中。

• 使用mysqldump创建的转储文件无法加载到强制执行列长度限制的服务器中。

为了解决这两个问题，一个解决方法是修改每个有问题的视图定义，使用提供更短列名的别名。然后视图就能正确复制，并且可以在不引起错误的情况下进行转储和重新加载。要修改定义，可以使用DROP VIEW和CREATE VIEW重新创建视图，或者用CREATE OR REPLACE VIEW替换定义。

对于在转储文件中重新加载视图定义时出现的问题，另一个解决方法是编辑转储文件以修改其CREATE VIEW语句。然而，这并不会改变原始视图定义，这可能会导致后续转储操作出现问题。

第二十八章 INFORMATION_SCHEMA 表

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

目录

28.1 简介

28.2 INFORMATION_SCHEMA 表参考

28.3 INFORMATION_SCHEMA 通用表

28.3.1 INFORMATION_SCHEMA 通用表参考

28.3.2 INFORMATION_SCHEMA ADMINISTRABLE_ROLE_AUTHORIZATIONS 表

28.3.3 INFORMATION_SCHEMA APPLICABLE_ROLES 表

28.3.4 INFORMATION_SCHEMA CHARACTER_SETS 表

28.3.5 INFORMATION_SCHEMA CHECK_CONSTRAINTS 表

28.3.6 INFORMATION_SCHEMA COLLATIONS 表

28.3.7 INFORMATION_SCHEMA COLLATION_CHARACTER_SET_APPLICABILITY 表

28.3.8 INFORMATION_SCHEMA COLUMNS 表

28.3.9 INFORMATION_SCHEMA COLUMNS_EXTENSIONS 表

28.3.10 INFORMATION_SCHEMA COLUMN_PRIVILEGES 表

28.3.11 INFORMATION_SCHEMA COLUMN_STATISTICS 表

28.3.12 INFORMATION_SCHEMA ENABLED_ROLES 表

28.3.13 INFORMATION_SCHEMA ENGINES 表

28.3.14 INFORMATION_SCHEMA EVENTS 表

28.3.15 INFORMATION_SCHEMA FILES ��

28.3.16 INFORMATION_SCHEMA KEY_COLUMN_USAGE 表

28.3.17 INFORMATION_SCHEMA KEYWORDS 表

28.3.18 INFORMATION_SCHEMA ndb_transid_mysql_connection_map 表

28.3.19 INFORMATION_SCHEMA OPTIMIZER_TRACE 表

28.3.20 INFORMATION_SCHEMA PARAMETERS 表

28.3.21 INFORMATION_SCHEMA PARTITIONS 表

28.3.22 INFORMATION_SCHEMA PLUGINS 表

28.3.23 INFORMATION_SCHEMA PROCESSLIST 表

28.3.24 INFORMATION_SCHEMA PROFILING 表

28.3.25 INFORMATION_SCHEMA REFERENTIAL_CONSTRAINTS 表

28.3.26 INFORMATION_SCHEMA RESOURCE_GROUPS 表

28.3.27 INFORMATION_SCHEMA ROLE_COLUMN_GRANTS 表

28.3.28 INFORMATION_SCHEMA ROLE_ROUTINE_GRANTS 表

28.3.29 INFORMATION_SCHEMA ROLE_TABLE_GRANTS 表

28.3.30 INFORMATION_SCHEMA ROUTINES 表

28.3.31 INFORMATION_SCHEMA SCHEMATA 表

28.3.32 INFORMATION_SCHEMA SCHEMATA_EXTENSIONS 表

28.3.33 INFORMATION_SCHEMA SCHEMA_PRIVILEGES 表

28.3.34 INFORMATION_SCHEMA STATISTICS 表

28.3.35 INFORMATION_SCHEMA ST_GEOMETRY_COLUMNS 表

28.3.36 INFORMATION_SCHEMA ST_SPATIAL_REFERENCE_SYSTEMS 表

28.3.37 INFORMATION_SCHEMA ST_UNITS_OF_MEASURE 表

28.3.38 INFORMATION_SCHEMA TABLES 表

28.3.39 INFORMATION_SCHEMA TABLES_EXTENSIONS 表

28.3.40 INFORMATION_SCHEMA TABLESPACES 表

28.3.41 INFORMATION_SCHEMA TABLESPACES_EXTENSIONS 表

28.3.42 INFORMATION_SCHEMA TABLE_CONSTRAINTS 表

28.3.43 INFORMATION_SCHEMA TABLE_CONSTRAINTS_EXTENSIONS 表

28.3.44 INFORMATION_SCHEMA TABLE_PRIVILEGES 表

28.3.45 INFORMATION_SCHEMA TRIGGERS 表

28.3.46 INFORMATION_SCHEMA USER_ATTRIBUTES 表

28.3.47 INFORMATION_SCHEMA USER_PRIVILEGES 表

28.3.48 INFORMATION_SCHEMA VIEWS 表

28.3.49 INFORMATION_SCHEMA VIEW_ROUTINE_USAGE 表

28.3.50 INFORMATION_SCHEMA VIEW_TABLE_USAGE 表

28.4 INFORMATION_SCHEMA InnoDB 表

28.4.1 INFORMATION_SCHEMA InnoDB 表参考

28.4.2 INFORMATION_SCHEMA INNODB_BUFFER_PAGE 表

28.4.3 INFORMATION_SCHEMA INNODB_BUFFER_PAGE_LRU 表

28.4.4 INFORMATION_SCHEMA INNODB_BUFFER_POOL_STATS 表

28.4.5 INFORMATION_SCHEMA INNODB_CACHED_INDEXES 表

28.4.6 INFORMATION_SCHEMA INNODB_CMP 和 INNODB_CMP_RESET 表

28.4.7 INFORMATION_SCHEMA INNODB_CMPMEM 和 INNODB_CMPMEM_RESET 表

28.4.8 INFORMATION_SCHEMA INNODB_CMP_PER_INDEX 和 INNODB_CMP_PER_INDEX_RESET 表

28.4.9 INFORMATION_SCHEMA INNODB_COLUMNS 表

28.4.10 INFORMATION_SCHEMA INNODB_DATAFILES 表

28.4.11 INFORMATION_SCHEMA INNODB_FIELDS 表

28.4.12 INFORMATION_SCHEMA INNODB_FOREIGN 表

28.4.13 INFORMATION_SCHEMA INNODB_FOREIGN_COLS 表

28.4.14 INFORMATION_SCHEMA INNODB_FT_BEING_DELETED 表

28.4.15 INFORMATION_SCHEMA INNODB_FT_CONFIG 表

28.4.16 INFORMATION_SCHEMA INNODB_FT_DEFAULT_STOPWORD 表

28.4.17 INFORMATION_SCHEMA INNODB_FT_DELETED 表

28.4.18 INFORMATION_SCHEMA INNODB_FT_INDEX_CACHE 表

28.4.19 INFORMATION_SCHEMA INNODB_FT_INDEX_TABLE 表

28.4.20 INFORMATION_SCHEMA INNODB_INDEXES 表

28.4.21 INFORMATION_SCHEMA INNODB_METRICS 表

28.4.22 INFORMATION_SCHEMA INNODB_SESSION_TEMP_TABLESPACES 表

28.4.23 INFORMATION_SCHEMA INNODB_TABLES 表

28.4.24 INFORMATION_SCHEMA INNODB_TABLESPACES 表

28.4.25 INFORMATION_SCHEMA INNODB_TABLESPACES_BRIEF 表

28.4.26 INFORMATION_SCHEMA INNODB_TABLESTATS 视图

28.4.27 INFORMATION_SCHEMA INNODB_TEMP_TABLE_INFO 表

28.4.28 INFORMATION_SCHEMA INNODB_TRX 表

28.4.29 INFORMATION_SCHEMA INNODB_VIRTUAL 表

28.5 INFORMATION_SCHEMA 线程池表

28.5.1 INFORMATION_SCHEMA 线程池表参考

28.5.2 INFORMATION_SCHEMA TP_THREAD_GROUP_STATE 表

28.5.3 INFORMATION_SCHEMA TP_THREAD_GROUP_STATS 表

28.5.4 INFORMATION_SCHEMA TP_THREAD_STATE 表

28.6 INFORMATION_SCHEMA 连接控制表

28.6.1 INFORMATION_SCHEMA 连接控制表参考

28.6.2 INFORMATION_SCHEMA CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS 表

28.7 INFORMATION_SCHEMA MySQL 企业防火墙表

28.7.1 INFORMATION_SCHEMA 防火墙表参考

28.7.2 INFORMATION_SCHEMA MYSQL_FIREWALL_USERS 表

28.7.3 INFORMATION_SCHEMA MYSQL_FIREWALL_WHITELIST 表

28.8 SHOW 语句的扩展

INFORMATION_SCHEMA 提供对数据库元数据的访问，以及关于 MySQL 服务器的信息，如数据库或表的名称、列的数据类型或访问权限。有时用于表示这些信息的其他术语包括数据字典和系统目录。

28.1 介绍

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

INFORMATION_SCHEMA提供对数据库元数据的访问，包括有关 MySQL 服务器的信息，如数据库或表的名称、列的数据类型或访问权限。有时用于表示此信息的其他术语是数据字典和系统目录。

• INFORMATION_SCHEMA 使用注意事项

• 字符集考虑

• INFORMATION_SCHEMA 作为 SHOW 语句的替代

• INFORMATION_SCHEMA 和权限

• 性能考虑

• 标准考虑

• INFORMATION_SCHEMA 参考部分中的约定

• 相关信息

INFORMATION_SCHEMA 使用注意事项

INFORMATION_SCHEMA是每个 MySQL 实例中的一个数据库，存储有关 MySQL 服务器维护的所有其他数据库的信息的地方。INFORMATION_SCHEMA数据库包含几个只读表。它们实际上是视图，而不是基本表，因此与它们关联的文件不存在，您不能在它们上设置触发器。此外，没有以该名称命名的数据库目录。

尽管您可以使用USE语句将INFORMATION_SCHEMA选择为默认数据库，但您只能读取表的内容，而不能对其执行INSERT、UPDATE或DELETE操作。

这里是一个从INFORMATION_SCHEMA中检索信息的语句示例：

mysql> SELECT table_name, table_type, engine
       FROM information_schema.tables
       WHERE table_schema = 'db5'
       ORDER BY table_name;
+------------+------------+--------+
| table_name | table_type | engine |
+------------+------------+--------+
| fk         | BASE TABLE | InnoDB |
| fk2        | BASE TABLE | InnoDB |
| goto       | BASE TABLE | MyISAM |
| into       | BASE TABLE | MyISAM |
| k          | BASE TABLE | MyISAM |
| kurs       | BASE TABLE | MyISAM |
| loop       | BASE TABLE | MyISAM |
| pk         | BASE TABLE | InnoDB |
| t          | BASE TABLE | MyISAM |
| t2         | BASE TABLE | MyISAM |
| t3         | BASE TABLE | MyISAM |
| t7         | BASE TABLE | MyISAM |
| tables     | BASE TABLE | MyISAM |
| v          | VIEW       | NULL   |
| v2         | VIEW       | NULL   |
| v3         | VIEW       | NULL   |
| v56        | VIEW       | NULL   |
+------------+------------+--------+
17 rows in set (0.01 sec)

解释：该语句请求列出数据库db5中所有表的列表，仅显示三个信息：表的名称、类型和存储引擎。

从 MySQL 8.0.30 开始，默认情况下，描述表列、键或两者的所有INFORMATION_SCHEMA表中可见生成的不可见主键的信息，例如COLUMNS和STATISTICS表。如果您希望使这些信息对从这些表中选择的查询隐藏，可以通过将show_gipk_in_create_table_and_information_schema服务器系统变量的值设置为OFF来实现。有关更多信息，请参见 Section 15.1.20.11，“生成的不可见主键”。

字符集考虑

字符列的定义（例如，TABLES.TABLE_NAME）通常是VARCHAR(*N*) CHARACTER SET utf8mb3，其中N至少为 64。MySQL 对此字符集（utf8mb3_general_ci）使用默认排序规则进行所有搜索、排序、比较和其他字符串操作。

因为一些 MySQL 对象表示为文件，对INFORMATION_SCHEMA字符串列的搜索可能会受到文件系统的大小写敏感性的影响。有关更多信息，请参见 Section 12.8.7，“在 INFORMATION_SCHEMA 搜索中使用排序规则”。

INFORMATION_SCHEMA 作为 SHOW 语句的替代

SELECT ... FROM INFORMATION_SCHEMA语句旨在提供一种更一致的方式来访问 MySQL 支持的各种SHOW语句提供的信息（SHOW DATABASES、SHOW TABLES等）。与SHOW相比，使用SELECT具有以下优势：

• 它符合 Codd 的规则，因为所有访问都是在表上进行的。

• 您可以使用SELECT语句的熟悉语法，只需学习一些表和列名称。

• 实施者无需担心添加关键字。

• 您可以将INFORMATION_SCHEMA查询的结果进行过滤、排序、连接和转换为应用程序需要的任何格式，例如数据结构或文本表示以进行解析。

• 这种技术与其他数据库系统更具互操作性。例如，Oracle Database 用户熟悉在 Oracle 数据字典中查询表。

由于SHOW是熟悉且广泛使用的，SHOW语句仍然作为一种选择。实际上，随着INFORMATION_SCHEMA的实现，SHOW有一些增强，如第 28.8 节，“SHOW 语句的扩展”中所述。

INFORMATION_SCHEMA 和权限

对于大多数INFORMATION_SCHEMA表，每个 MySQL 用户都有权访问它们，但只能看到与用户具有适当访问权限的对象对应的表中的行。在某些情况下（例如INFORMATION_SCHEMA ROUTINES表中的ROUTINE_DEFINITION列），权限不足的用户会看到NULL。一些表具有不同的权限要求；对于这些表，要求在适用的表描述中提到。例如，InnoDB表（以INNODB_开头的表）需要PROCESS权限。

选择从INFORMATION_SCHEMA中获取信息和通过SHOW语句查看相同信息的权限是相同的。在任何情况下，您必须对对象具有某些权限才能查看有关它的信息。

性能考虑

从多个数据库中搜索信息的INFORMATION_SCHEMA查询可能需要很长时间并影响性能。要检查查询的效率，可以使用EXPLAIN。有关使用EXPLAIN输出来调整INFORMATION_SCHEMA查询的信息，请参阅第 10.2.3 节，“优化 INFORMATION_SCHEMA 查询”。

标准考虑

MySQL 中INFORMATION_SCHEMA表结构的实现遵循 ANSI/ISO SQL:2003 标准第 11 部分Schemata。我们的目标是与 SQL:2003 核心功能 F021 基本信息模式大致符合。

使用 SQL Server 2000（也遵循标准）的用户可能会注意到很强的相似性。然而，MySQL 省略了许多对我们实现不相关的列，并添加了 MySQL 特定的列。INFORMATION_SCHEMA TABLES表中的ENGINE列就是这样一个添加的列。

尽管其他 DBMS 使用各种名称，如syscat或system，但标准名称是INFORMATION_SCHEMA。

为避免使用标准中保留的任何名称或在 DB2、SQL Server 或 Oracle 中保留的名称，我们更改了一些标记为“MySQL 扩展”的列的名称。（例如，在 TABLES 表中，我们将 COLLATION 更改为 TABLE_COLLATION。）请参阅本文末尾的保留字列表：web.archive.org/web/20070428032454/http://www.dbazine.com/db2/db2-disarticles/gulutzan5。

INFORMATION_SCHEMA 参考部分的约定

以下部分描述了 INFORMATION_SCHEMA 中的每个表和列。对于每列，有三个信息：

• “INFORMATION_SCHEMA Name” 表示 INFORMATION_SCHEMA 表中列的名称。除非“备注”字段说“MySQL 扩展”，否则这对应于标准 SQL 名称。

• “SHOW Name” 表示最接近的 SHOW 语句中的等效字段名称，如果有的话。

• “备注”在适用时提供额外信息。如果此字段为 NULL，则表示列的值始终为 NULL。如果此字段说“MySQL 扩展”，则该列是标准 SQL 的 MySQL 扩展。

许多部分指示了 SHOW 语句等效于从 INFORMATION_SCHEMA 检索信息的 SELECT 语句。对于 SHOW 语句，如果省略 FROM *db_name* 子句，则会显示默认数据库的信息，您可以通过在检索信息的查询的 WHERE 子句中添加 AND TABLE_SCHEMA = SCHEMA() 条件来选择默认数据库的信息。

相关信息

这些部分讨论了其他与 INFORMATION_SCHEMA 相关的主题：

• 有关 InnoDB 存储引擎特定的 INFORMATION_SCHEMA 表的信息：第 28.4 节，“INFORMATION_SCHEMA InnoDB 表”

• 有关线程池插件特定的 INFORMATION_SCHEMA 表的信息：第 28.5 节，“INFORMATION_SCHEMA 线程池表”

• 有关 CONNECTION_CONTROL 插件特定的 INFORMATION_SCHEMA 表的信息：第 28.6 节，“INFORMATION_SCHEMA 连接控制表”

• 关于 INFORMATION_SCHEMA 数据库经常被问到的问题的答案：第 A.7 节，“MySQL 8.0 FAQ: INFORMATION_SCHEMA”

• INFORMATION_SCHEMA 查询和优化器：第 10.2.3 节，“优化 INFORMATION_SCHEMA 查询”

• 校对对 INFORMATION_SCHEMA 比较的影响：第 12.8.7 节，“在 INFORMATION_SCHEMA 搜索中使用校对”

28.2 INFORMATION_SCHEMA 表参考

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-table-reference.html

以下表总结了所有可用的INFORMATION_SCHEMA表。更详细的信息，请参阅各个表的描述。

表 28.1 INFORMATION_SCHEMA 表

表名	描述	引入版本	废弃版本
ADMINISTRABLE_ROLE_AUTHORIZATIONS	当前用户或角色可授权的用户或角色	8.0.19
APPLICABLE_ROLES	当前用户适用的角色	8.0.19
CHARACTER_SETS	可用字符集
CHECK_CONSTRAINTS	表和列的检查约束	8.0.16
COLLATION_CHARACTER_SET_APPLICABILITY	每个排序规则适用的字符集
COLLATIONS	每个字符集的排序规则
COLUMN_PRIVILEGES	列上定义的权限
COLUMN_STATISTICS	列值的直方图统计
COLUMNS	每个表中的列
COLUMNS_EXTENSIONS	主要和次要存储引擎的列属性	8.0.21
CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS	每个账户连续失败连接尝试的当前次数
ENABLED_ROLES	当前会话中启用的角色	8.0.19
ENGINES	存储引擎属性
EVENTS	事件管理器事件
FILES	存储表空间数据的文件
INNODB_BUFFER_PAGE	InnoDB 缓冲池中的页面
INNODB_BUFFER_PAGE_LRU	InnoDB 缓冲池中页面的 LRU 排序
INNODB_BUFFER_POOL_STATS	InnoDB 缓冲池统计信息
INNODB_CACHED_INDEXES	InnoDB 缓冲池中每个索引缓存的索引页数
INNODB_CMP	与压缩的 InnoDB 表相关的操作状态
INNODB_CMP_PER_INDEX	与压缩的 InnoDB 表和索引相关的操作状态
INNODB_CMP_PER_INDEX_RESET	与压缩的 InnoDB 表和索引相关的操作状态
INNODB_CMP_RESET	与压缩的 InnoDB 表相关的操作状态
INNODB_CMPMEM	InnoDB 缓冲池中压缩页面的状态
INNODB_CMPMEM_RESET	InnoDB 缓冲池中压缩页面的状态
INNODB_COLUMNS	每个 InnoDB 表中的列
INNODB_DATAFILES	InnoDB 每表一个文件和通用表空间的数据文件路径信息
INNODB_FIELDS	InnoDB 索引的关键列
INNODB_FOREIGN	InnoDB 外键元数据
INNODB_FOREIGN_COLS	InnoDB 外键列状态信息
INNODB_FT_BEING_DELETED	INNODB_FT_DELETED 表的快照
INNODB_FT_CONFIG	InnoDB 表全文索引和相关处理的元数据
INNODB_FT_DEFAULT_STOPWORD	InnoDB 全文索引的默认停用词列表
INNODB_FT_DELETED	从 InnoDB 表全文索引中删除的行
INNODB_FT_INDEX_CACHE	InnoDB 全文索引中新插入行的标记信息
INNODB_FT_INDEX_TABLE	用于处理针对 InnoDB 表全文索引的文本搜索的倒排索引信息
INNODB_INDEXES	InnoDB 索引元数据
INNODB_METRICS	InnoDB 性能信息
INNODB_SESSION_TEMP_TABLESPACES	会话临时表空间元数据	8.0.13
INNODB_TABLES	InnoDB 表元数据
INNODB_TABLESPACES	InnoDB 每表文件、通用和撤销表空间元数据
INNODB_TABLESPACES_BRIEF	简要的文件、通用、撤销和系统表空间元��据
INNODB_TABLESTATS	InnoDB 表低级状态信息
INNODB_TEMP_TABLE_INFO	关于活动用户创建的 InnoDB 临时表的信息
INNODB_TRX	活动的 InnoDB 事务信息
INNODB_VIRTUAL	InnoDB 虚拟生成列元数据
KEY_COLUMN_USAGE	具有约束的关键列
KEYWORDS	MySQL 关键字
MYSQL_FIREWALL_USERS	账户配置的防火墙内存数据		8.0.26
MYSQL_FIREWALL_WHITELIST	账户配置的防火墙内存数据允许列表		8.0.26
ndb_transid_mysql_connection_map	NDB 事务信息
OPTIMIZER_TRACE	优化器跟踪活动产生的信息
PARAMETERS	存储过程参数和存储函数返回值
PARTITIONS	表分区信息
PLUGINS	插件信息
PROCESSLIST	当前执行线程的信息
PROFILING	语句分析信息
REFERENTIAL_CONSTRAINTS	外键信息
RESOURCE_GROUPS	资源组信息
ROLE_COLUMN_GRANTS	当前启用角色可用或授予的列权限	8.0.19
ROLE_ROUTINE_GRANTS	当前启用角色可用或授予的例程权限	8.0.19
ROLE_TABLE_GRANTS	当前启用角色可用或授予的表权限	8.0.19
ROUTINES	存储过程信息
SCHEMA_PRIVILEGES	在模式上定义的权限
SCHEMATA	模式信息
SCHEMATA_EXTENSIONS	模式选项	8.0.22
ST_GEOMETRY_COLUMNS	每个表中存储空间数据的列
ST_SPATIAL_REFERENCE_SYSTEMS	可用的空间参考系统
ST_UNITS_OF_MEASURE	ST_Distance()可接受的单位	8.0.14
STATISTICS	表索引统计信息
TABLE_CONSTRAINTS	哪些表具有约束
TABLE_CONSTRAINTS_EXTENSIONS	主要和次要存储引擎的表约束属性	8.0.21
TABLE_PRIVILEGES	在表上定义的权限
TABLES	表信息
TABLES_EXTENSIONS	主要和次要存储引擎的表属性	8.0.21
TABLESPACES	表空间信息		8.0.22
TABLESPACES_EXTENSIONS	主存储引擎表空间属性	8.0.21
TP_THREAD_GROUP_STATE	线程池线程组状态
TP_THREAD_GROUP_STATS	线程池线程组统计信息
TP_THREAD_STATE	线程池线程信息
TRIGGERS	触发器信息
USER_ATTRIBUTES	用户注释和属性	8.0.21
USER_PRIVILEGES	每个用户全局定义的权限
VIEW_ROUTINE_USAGE	在视图中使用的存储函数	8.0.13
VIEW_TABLE_USAGE	在视图中使用的表和视图	8.0.13
VIEWS	视图信息
表名	描述	引入版本	废弃版本

28.3 INFORMATION_SCHEMA 通用表

原文：dev.mysql.com/doc/refman/8.0/en/general-information-schema-tables.html

28.3.1 INFORMATION_SCHEMA 通用表参考

28.3.2 INFORMATION_SCHEMA ADMINISTRABLE_ROLE_AUTHORIZATIONS 表

28.3.3 INFORMATION_SCHEMA APPLICABLE_ROLES 表

28.3.4 INFORMATION_SCHEMA CHARACTER_SETS 表

28.3.5 INFORMATION_SCHEMA CHECK_CONSTRAINTS 表

28.3.6 INFORMATION_SCHEMA COLLATIONS 表

28.3.7 INFORMATION_SCHEMA COLLATION_CHARACTER_SET_APPLICABILITY 表

28.3.8 INFORMATION_SCHEMA COLUMNS 表

28.3.9 INFORMATION_SCHEMA COLUMNS_EXTENSIONS 表

28.3.10 INFORMATION_SCHEMA COLUMN_PRIVILEGES 表

28.3.11 INFORMATION_SCHEMA COLUMN_STATISTICS 表

28.3.12 INFORMATION_SCHEMA ENABLED_ROLES 表

28.3.13 INFORMATION_SCHEMA ENGINES 表

28.3.14 INFORMATION_SCHEMA EVENTS 表

28.3.15 INFORMATION_SCHEMA FILES 表

28.3.16 INFORMATION_SCHEMA KEY_COLUMN_USAGE 表

28.3.17 INFORMATION_SCHEMA KEYWORDS 表

28.3.18 INFORMATION_SCHEMA ndb_transid_mysql_connection_map 表

28.3.19 INFORMATION_SCHEMA OPTIMIZER_TRACE 表

28.3.20 INFORMATION_SCHEMA PARAMETERS 表

28.3.21 INFORMATION_SCHEMA PARTITIONS 表

28.3.22 INFORMATION_SCHEMA PLUGINS 表

28.3.23 INFORMATION_SCHEMA PROCESSLIST 表

28.3.24 INFORMATION_SCHEMA PROFILING 表

28.3.25 INFORMATION_SCHEMA REFERENTIAL_CONSTRAINTS 表

28.3.26 INFORMATION_SCHEMA RESOURCE_GROUPS 表

28.3.27 INFORMATION_SCHEMA ROLE_COLUMN_GRANTS 表

28.3.28 INFORMATION_SCHEMA ROLE_ROUTINE_GRANTS 表

28.3.29 INFORMATION_SCHEMA ROLE_TABLE_GRANTS 表

28.3.30 INFORMATION_SCHEMA ROUTINES 表

28.3.31 INFORMATION_SCHEMA SCHEMATA 表

28.3.32 INFORMATION_SCHEMA SCHEMATA_EXTENSIONS 表

28.3.33 INFORMATION_SCHEMA SCHEMA_PRIVILEGES 表

28.3.34 INFORMATION_SCHEMA STATISTICS 表

28.3.35 INFORMATION_SCHEMA ST_GEOMETRY_COLUMNS 表

28.3.36 INFORMATION_SCHEMA ST_SPATIAL_REFERENCE_SYSTEMS 表

28.3.37 INFORMATION_SCHEMA ST_UNITS_OF_MEASURE 表

28.3.38 INFORMATION_SCHEMA TABLES 表

28.3.39 INFORMATION_SCHEMA TABLES_EXTENSIONS 表

28.3.40 INFORMATION_SCHEMA TABLESPACES 表

28.3.41 INFORMATION_SCHEMA TABLESPACES_EXTENSIONS 表

28.3.42 INFORMATION_SCHEMA TABLE_CONSTRAINTS 表

28.3.43 INFORMATION_SCHEMA TABLE_CONSTRAINTS_EXTENSIONS 表

28.3.44 INFORMATION_SCHEMA TABLE_PRIVILEGES 表

28.3.45 INFORMATION_SCHEMA TRIGGERS 表

28.3.46 INFORMATION_SCHEMA USER_ATTRIBUTES 表

28.3.47 INFORMATION_SCHEMA USER_PRIVILEGES 表

28.3.48 INFORMATION_SCHEMA VIEWS 表

28.3.49 INFORMATION_SCHEMA VIEW_ROUTINE_USAGE 表

28.3.50 INFORMATION_SCHEMA VIEW_TABLE_USAGE 表

以下部分描述了可能被称为“通用”INFORMATION_SCHEMA表的内容。这些表与特定存储引擎、组件或插件无关。

28.3.1 INFORMATION_SCHEMA 通用表参考

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-general-table-reference.html

以下表格总结了INFORMATION_SCHEMA通用表。更详细的信息，请参阅各个表的描述。

表 28.2 INFORMATION_SCHEMA 通用表

表名	描述	引入版本	废弃版本
ADMINISTRABLE_ROLE_AUTHORIZATIONS	当前用户或角色可授权的用户或角色	8.0.19
APPLICABLE_ROLES	当前用户适用的角色	8.0.19
CHARACTER_SETS	可用字符集
CHECK_CONSTRAINTS	表和列的检查约束	8.0.16
COLLATION_CHARACTER_SET_APPLICABILITY	每个排序规则适用的字符集
COLLATIONS	每个字符集的排序规则
COLUMN_PRIVILEGES	列上定义的权限
COLUMN_STATISTICS	列值的直方图统计
COLUMNS	每个表中的列
COLUMNS_EXTENSIONS	主要和次要存储引擎的列属性	8.0.21
ENABLED_ROLES	当前会话中启用的角色	8.0.19
ENGINES	存储引擎属性
EVENTS	事件管理器事件
FILES	存储表空间数据的文件
KEY_COLUMN_USAGE	具有约束的关键列
KEYWORDS	MySQL 关键词
ndb_transid_mysql_connection_map	NDB 事务信息
OPTIMIZER_TRACE	优化器跟踪活动产生的信息
PARAMETERS	存储过程参数和存储函数返回值
PARTITIONS	表分区信息
PLUGINS	插件信息
PROCESSLIST	当前执行线程的信息
PROFILING	语句分析信息
REFERENTIAL_CONSTRAINTS	外键信息
RESOURCE_GROUPS	资源组信息
ROLE_COLUMN_GRANTS	当前启用角色可用或授予的列权限	8.0.19
ROLE_ROUTINE_GRANTS	当前启用角色可用或授予的例程权限	8.0.19
ROLE_TABLE_GRANTS	当前启用角色可用或授予的表权限	8.0.19
ROUTINES	存储过程信息
SCHEMA_PRIVILEGES	在模式上定义的权限
SCHEMATA	模式信息
SCHEMATA_EXTENSIONS	模式选项	8.0.22
ST_GEOMETRY_COLUMNS	每个存储空间数据的表中的列
ST_SPATIAL_REFERENCE_SYSTEMS	可用的空间参考系统
ST_UNITS_OF_MEASURE	ST_Distance()可接受的单位	8.0.14
STATISTICS	表索引统计
TABLE_CONSTRAINTS	哪些表具有约束
TABLE_CONSTRAINTS_EXTENSIONS	主要和次要存储引擎的表约束属性	8.0.21
TABLE_PRIVILEGES	表上定义的权限
TABLES	表信息
TABLES_EXTENSIONS	主要和次要存储引擎的表属性	8.0.21
TABLESPACES	表空间信息		8.0.22
TABLESPACES_EXTENSIONS	主要存储引擎的表空间属性	8.0.21
TRIGGERS	触发器信息
USER_ATTRIBUTES	用户评论和属性	8.0.21
USER_PRIVILEGES	每个用户全局定义的权限
VIEW_ROUTINE_USAGE	在视图中使用的存储函数	8.0.13
VIEW_TABLE_USAGE	在视图中使用的表和视图	8.0.13
视图	视图信息
表名	描述	引入	废弃

28.3.2 INFORMATION_SCHEMA ADMINISTRABLE_ROLE_AUTHORIZATIONS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-administrable-role-authorizations-table.html

ADMINISTRABLE_ROLE_AUTHORIZATIONS 表（自 MySQL 8.0.19 起可用）提供有关当前用户或角色适用的哪些角色可以授予给其他用户或角色的信息。

ADMINISTRABLE_ROLE_AUTHORIZATIONS 表具有以下列：

• USER

  当前用户帐户的用户名称部分。

• HOST

  当前用户帐户的主机名部分。

• GRANTEE

  授予角色的帐户的用户名称部分。

• GRANTEE_HOST

  授予角色的帐户的主机名部分。

• ROLE_NAME

  授予角色的用户名称部分。

• ROLE_HOST

  授予角色的主机名部分。

• IS_GRANTABLE

  YES 或 NO，取决于角色是否可以授予给其他帐户。

• IS_DEFAULT

  YES 或 NO，取决于角色是否是默认角色。

• IS_MANDATORY

  YES 或 NO，取决于角色是否是强制角色。

28.3.3 INFORMATION_SCHEMA APPLICABLE_ROLES 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-applicable-roles-table.html

APPLICABLE_ROLES 表（自 MySQL 8.0.19 起可用）提供了关于适用于当前用户的角色的信息。

APPLICABLE_ROLES 表具有以下列：

• USER

  当前用户账户的用户名部分。

• HOST

  当前用户账户的主机名部分。

• GRANTEE

  被授予角色的账户的用户名部分。

• GRANTEE_HOST

  被授予角色的账户的主机名部分。

• ROLE_NAME

  被授予角色的用户名部分。

• ROLE_HOST

  被授予角色的主机名部分。

• IS_GRANTABLE

  YES 或 NO，取决于角色是否可授予给其他账户。

• IS_DEFAULT

  YES 或 NO，取决于角色是否为默认角色。

• IS_MANDATORY

  YES 或 NO，取决于角色是否为强制角色。

28.3.4 The INFORMATION_SCHEMA CHARACTER_SETS Table

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-character-sets-table.html

CHARACTER_SETS 表提供了关于可用字符集的信息。

CHARACTER_SETS 表包含以下列：

• CHARACTER_SET_NAME

  字符集名称。

• DEFAULT_COLLATE_NAME

  字符集的默认排序规则。

• DESCRIPTION

  字符集的描述。

• MAXLEN

  存储一个字符所需的最大字节数。

注意

字符集信息也可以通过 SHOW CHARACTER SET 语句获取。参见 Section 15.7.7.3, “SHOW CHARACTER SET Statement”。以下语句是等效的：

SELECT * FROM INFORMATION_SCHEMA.CHARACTER_SETS
  [WHERE CHARACTER_SET_NAME LIKE '*wild*']

SHOW CHARACTER SET
  [LIKE '*wild*']

28.3.5 INFORMATION_SCHEMA CHECK_CONSTRAINTS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-check-constraints-table.html

截至 MySQL 8.0.16，CREATE TABLE允许表和列CHECK约束的核心特性，并且CHECK_CONSTRAINTS表提供关于这些约束的信息。

CHECK_CONSTRAINTS表具有以下列：

• CONSTRAINT_CATALOG

  约束所属的目录的名称。此值始终为def。

• CONSTRAINT_SCHEMA

  约束所属的模式（数据库）的名称。

• CONSTRAINT_NAME

  约束的名称。

• CHECK_CLAUSE

  指定约束条件的表达式。

28.3.6 INFORMATION_SCHEMA COLLATIONS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-collations-table.html

COLLATIONS 表提供了每个字符集的排序规则信息。

COLLATIONS 表包含以下列：

• COLLATION_NAME

  排序规则名称。

• CHARACTER_SET_NAME

  与排序规则相关联的字符集的名称。

• ID

  排序规则 ID。

• IS_DEFAULT

  排序规则是否是其字符集的默认规则。

• IS_COMPILED

  字符集是否编译到服务器中。

• SORTLEN

  这与在字符集中表达的字符串所需的排序所需的内存量有关。

• PAD_ATTRIBUTE

  排序规则填充属性，可以是 NO PAD 或 PAD SPACE。此属性影响在字符串比较中是否尾随空格有意义；请参阅比较中的尾随空格处理。

注意事项

排序规则信息也可以从 SHOW COLLATION 语句中获取。请参阅 Section 15.7.7.4, “SHOW COLLATION 语句”。以下语句是等效的：

SELECT COLLATION_NAME FROM INFORMATION_SCHEMA.COLLATIONS
  [WHERE COLLATION_NAME LIKE '*wild*']

SHOW COLLATION
  [LIKE '*wild*']

28.3.7 INFORMATION_SCHEMA COLLATION_CHARACTER_SET_APPLICABILITY 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-collation-character-set-applicability-table.html

COLLATION_CHARACTER_SET_APPLICABILITY 表示适用于哪种排序的字符集。

COLLATION_CHARACTER_SET_APPLICABILITY 表包含以下列：

• COLLATION_NAME

  排序名称。

• CHARACTER_SET_NAME

  与排序关联的字符集的名称。

注意事项

COLLATION_CHARACTER_SET_APPLICABILITY 的列等同于 SHOW COLLATION 语句显示的前两列。

28.3.8 The INFORMATION_SCHEMA COLUMNS Table

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-columns-table.html

COLUMNS 表提供有关表中列的信息。相关的 ST_GEOMETRY_COLUMNS 表提供有关存储空间数据的表列的信息。请参阅 Section 28.3.35, “The INFORMATION_SCHEMA ST_GEOMETRY_COLUMNS Table”。

COLUMNS 表具有以下列：

• TABLE_CATALOG

  包含列的表所属的目录名称。此值始终为 def。

• TABLE_SCHEMA

  包含列的表所属的模式（数据库）的名称。

• TABLE_NAME

  包含列的表的名称。

• COLUMN_NAME

  列的名称。

• ORDINAL_POSITION

  列在表中的位置。ORDINAL_POSITION 是必要的，因为您可能想说 ORDER BY ORDINAL_POSITION。与 SHOW COLUMNS 不同，从 COLUMNS 表中的 SELECT 没有自动排序。

• COLUMN_DEFAULT

  列的默认值。如果列具有显式默认值为 NULL，或者列定义不包含 DEFAULT 子句，则为 NULL。

• IS_NULLABLE

  列的可空性。如果可以在列中存储 NULL 值，则值为 YES，否则为 NO。

• DATA_TYPE

  列数据类型。

  DATA_TYPE 值仅为类型名称，没有其他信息。COLUMN_TYPE 值包含类型名称，可能还包含其他信息，如精度或长度。

• CHARACTER_MAXIMUM_LENGTH

  对于字符串列，以字符为单位的最大长度。

• CHARACTER_OCTET_LENGTH

  对于字符串列，以字节为单位的最大长度。

• NUMERIC_PRECISION

  对于数字列，数字精度。

• NUMERIC_SCALE

  对于数字列，数字刻度。

• DATETIME_PRECISION

  对于时间列，小数秒精度。

• CHARACTER_SET_NAME

  对于字符串列，字符集名称。

• COLLATION_NAME

  对于字符串列，排序规则名称。

• COLUMN_TYPE

  列数据类型。

  DATA_TYPE 值仅为类型名称，没有其他信息。COLUMN_TYPE 值包含类型名称，可能还包含其他信息，如精度或长度。

• COLUMN_KEY

  列是否已索引：

  • 如果COLUMN_KEY为空，则该列未被索引或仅作为多列非唯一索引中的次要列被索引。

  • 如果COLUMN_KEY为PRI，则该列是PRIMARY KEY或是多列PRIMARY KEY中的一列。

  • 如果COLUMN_KEY为UNI，则该列是UNIQUE索引的第一列。（UNIQUE索引允许多个NULL值，但您可以通过检查Null列来确定列是否允许NULL。）

  • 如果COLUMN_KEY为MUL，则该列是非唯一索引的第一列，在该索引中允许在列内出现给定值的多个实例。

  如果表的给定列有多个COLUMN_KEY值适用，则COLUMN_KEY显示具有最高优先级的值，按照PRI，UNI，MUL的顺序。

  如果UNIQUE索引不能包含NULL值且表中没有PRIMARY KEY，则UNIQUE索引可能显示为PRI。如果几列形成复合UNIQUE索引，则UNIQUE索引可能显示为MUL；尽管列的组合是唯一的，但每列仍然可以包含给定值的多个实例。

• EXTRA

  关于给定列的任何其他可用信息。在这些情况下，该值不为空：

  • 对于具有AUTO_INCREMENT属性的列，显示auto_increment。

  • 对于具有ON UPDATE CURRENT_TIMESTAMP属性的TIMESTAMP或DATETIME列，显示on update CURRENT_TIMESTAMP。

  • 对于生成列，显示STORED GENERATED或VIRTUAL GENERATED。

  • DEFAULT_GENERATED 用于具有表达式默认值的列。

• PRIVILEGES

  您对该列拥有的权限。

• COLUMN_COMMENT

  包括在列定义中的任何注释。

• GENERATION_EXPRESSION

  对于生成的列，显示用于计算列值的表达式。对于非生成列为空。有关生成列的信息，请参见第 15.1.20.8 节，“CREATE TABLE 和生成列”。

• SRS_ID

  此值适用于空间列。它包含列SRID值，指示存储在列中的值的空间参考系统。参见第 13.4.1 节，“空间数据类型”和第 13.4.5 节，“空间参考系统支持”。对于非空间列和没有SRID属性的空间列，该值为NULL。

注释

• 在SHOW COLUMNS中，Type显示包括来自几个不同的COLUMNS列的值。

• CHARACTER_OCTET_LENGTH应与CHARACTER_MAXIMUM_LENGTH相同，除了多字节字符集。

• CHARACTER_SET_NAME可以从COLLATION_NAME派生。例如，如果你执行SHOW FULL COLUMNS FROM t，并且在COLLATION_NAME列中看到一个值为utf8mb4_swedish_ci，那么字符集就是出现在第一个下划线之前的内容：utf8mb4。

列信息也可以通过SHOW COLUMNS语句获取。参见 Section 15.7.7.5, “SHOW COLUMNS Statement”。以下语句几乎是等效的：

SELECT COLUMN_NAME, DATA_TYPE, IS_NULLABLE, COLUMN_DEFAULT
  FROM INFORMATION_SCHEMA.COLUMNS
  WHERE table_name = '*tbl_name*'
  [AND table_schema = '*db_name*']
  [AND column_name LIKE '*wild*']

SHOW COLUMNS
  FROM *tbl_name*
  [FROM *db_name*]
  [LIKE '*wild*']

在 MySQL 8.0.30 及更高版本中，默认情况下，此表中可见生成的不可见主键列的信息。您可以通过设置show_gipk_in_create_table_and_information_schema = OFF来隐藏这些信息。更多信息，请参见 Section 15.1.20.11, “Generated Invisible Primary Keys”。

28.3.9 INFORMATION_SCHEMA COLUMNS_EXTENSIONS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-columns-extensions-table.html

COLUMNS_EXTENSIONS 表（自 MySQL 8.0.21 起可用）提供有关为主存储引擎和次要存储引擎定义的列属性的信息。

注意

COLUMNS_EXTENSIONS 表保留供将来使用。

COLUMNS_EXTENSIONS 表包含以下列：

• TABLE_CATALOG

  表所属目录的名称。该值始终为 def。

• TABLE_SCHEMA

  表所属模式（数据库）的名称。

• TABLE_NAME

  表的名称。

• COLUMN_NAME

  列的名称。

• ENGINE_ATTRIBUTE

  为主存储引擎定义的列属性。保留供将来使用。

• SECONDARY_ENGINE_ATTRIBUTE

  为次要存储引擎定义的列属性。保留供将来使用。

28.3.10 INFORMATION_SCHEMA COLUMN_PRIVILEGES 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-column-privileges-table.html

COLUMN_PRIVILEGES 表提供有关列权限的信息。它从 mysql.columns_priv 系统表中获取其值。

COLUMN_PRIVILEGES 表具有以下列：

• GRANTEE

  授予权限的帐户的名称，格式为 '*user_name*'@'*host_name*'。

• TABLE_CATALOG

  包含列的表所属的目录的名称。此值始终为 def。

• TABLE_SCHEMA

  表中包含列的模式（数据库）的名称。

• TABLE_NAME

  包含列的表的名称。

• COLUMN_NAME

  列的名称。

• PRIVILEGE_TYPE

  授予的权限。该值可以是可以在列级别授予的任何权限；请参见第 15.7.1.6 节，“GRANT Statement”。每行列出一个权限，因此每个受让人持有的列权限都有一行。

  在 SHOW FULL COLUMNS 的输出中，权限都在一个列中且为小写，例如，select,insert,update,references。在 COLUMN_PRIVILEGES 中，每行一个权限，且为大写。

• IS_GRANTABLE

  如果用户具有 GRANT OPTION 权限，则为 YES，否则为 NO。输出不会将 GRANT OPTION 列为具有 PRIVILEGE_TYPE='GRANT OPTION' 的单独行。

注意

• COLUMN_PRIVILEGES 是一个非标准的 INFORMATION_SCHEMA 表。

以下语句不等价：

SELECT ... FROM INFORMATION_SCHEMA.COLUMN_PRIVILEGES

SHOW GRANTS ...

28.3.11 INFORMATION_SCHEMA COLUMN_STATISTICS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-column-statistics-table.html

COLUMN_STATISTICS 表提供对列值直方图统计信息的访问。

有关直方图统计信息，请参阅 Section 10.9.6, “优化器统计信息”和 Section 15.7.3.1, “ANALYZE TABLE 语句”。

你只能查看你拥有某些权限的列的信息。

COLUMN_STATISTICS 表包含以下列：

• SCHEMA_NAME

  统计信息适用的模式的名称。

• TABLE_NAME

  统计信息适用的列的名称。

• COLUMN_NAME

  统计信息适用的列的名称。

• HISTOGRAM

  一个描述列统计信息的JSON对象，存储为直方图。

28.3.12 The INFORMATION_SCHEMA ENABLED_ROLES Table

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-enabled-roles-table.html

ENABLED_ROLES 表（自 MySQL 8.0.19 起可用）提供了关于当前会话中启用的角色的信息。

ENABLED_ROLES 表包含以下列：

• ROLE_NAME

  被授予角色的用户名称部分。

• ROLE_HOST

  被授予角色的主机名部分。

• IS_DEFAULT

  YES 或 NO，取决于角色是否是默认角色。

• IS_MANDATORY

  YES 或 NO，取决于角色是否是强制性的。

28.3.13 INFORMATION_SCHEMA ENGINES 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-engines-table.html

ENGINES 表提供有关存储引擎的信息。这对于检查存储引擎是否受支持或查看默认引擎非常有用。

ENGINES 表具有以下列：

• ENGINE

  存储引擎的名称。

• SUPPORT

  服务器对存储引擎的支持级别，如下表所示。

  值	含义
  YES	该引擎受支持且处于活动状态
  DEFAULT	类似于 YES，并且这是默认引擎
  NO	该引擎不受支持
  DISABLED	该引擎受支持但已被禁用

  一个值为NO表示服务器在编译时没有对该引擎提供支持，因此无法在运行时启用。

  值为 DISABLED 可能是因为服务器启动时使用了禁用引擎的选项，或者因为没有提供启用它所需的所有选项。在后一种情况下，错误日志应包含指示为什么选项被禁用的原因。请参阅 Section 7.4.2, “The Error Log”。

  如果服务器编译时支持某个存储引擎，但是启动时使用了 --skip-*engine_name* 选项，则可能会看到存储引擎的 DISABLED。对于 NDB 存储引擎，DISABLED 表示服务器编译时支持 NDB Cluster，但未使用 --ndbcluster 选项启动。

  所有 MySQL 服务器都支持 MyISAM 表。无法禁用 MyISAM。

• COMMENT

  存储引擎的简要描述。

• TRANSACTIONS

  存储引擎是否支持事务。

• XA

  存储引擎是否支持 XA 事务。

• SAVEPOINTS

  存储引擎是否支持保存点。

注意

• ENGINES 是一个非标准的 INFORMATION_SCHEMA 表。

存储引擎信息也可以通过 SHOW ENGINES 语句获取。请参阅 Section 15.7.7.16, “SHOW ENGINES Statement”。以下语句是等效的：

SELECT * FROM INFORMATION_SCHEMA.ENGINES

SHOW ENGINES

28.3.14 INFORMATION_SCHEMA EVENTS Table

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-events-table.html

EVENTS表提供有关事件管理器事件的信息，这些事件在第 27.4 节“使用事件调度程序”中讨论。

EVENTS表具有以下列：

• EVENT_CATALOG

  事件所属的目录的名称。此值始终为def。

• EVENT_SCHEMA

  事件所属的模式（数据库）的名称。

• EVENT_NAME

  事件的名称。

• DEFINER

  DEFINER子句中指定的帐户（通常是创建事件的用户），格式为'*user_name*'@'*host_name*'。

• TIME_ZONE

  事件时区，用于调度事件并在事件执行时生效的时区。默认值为SYSTEM。

• EVENT_BODY

  事件的DO子句中语句的语言。该值始终为SQL。

• EVENT_DEFINITION

  事件的DO子句组成的 SQL 语句的文本；换句话说，此事件执行的语句。

• EVENT_TYPE

  事件重复类型，可以是ONE TIME（瞬时）或RECURRING（重复）。

• EXECUTE_AT

  对于一次性事件，这是在CREATE EVENT语句的AT子句中指定的DATETIME值，用于创建事件的最后一个ALTER EVENT语句，或修改事件的最后一个语句。此列中显示的值反映了事件的AT子句中包含的任何INTERVAL值的加法或减法。例如，如果使用ON SCHEDULE AT CURRENT_TIMESTAMP + '1:6' DAY_HOUR创建事件，并且事件在 2018-02-09 14:05:30 创建，则此列中显示的值将为'2018-02-10 20:05:30'。如果事件的时间由EVERY子句确定而不是AT子句（即，如果事件是重复的），则此列的值为NULL。

• INTERVAL_VALUE

  对于重复事件，事件执行之间等待的间隔数。对于瞬时事件，该值始终为NULL。

• INTERVAL_FIELD

  用于重复事件等待重复之前的间隔的时间单位。对于瞬时事件，该值始终为NULL。

• SQL_MODE

  创建或更改事件时生效的 SQL 模式，以及事件执行时使用的模式。有关允许的值，请参见第 7.1.11 节“服务器 SQL 模式”。

• STARTS

  重复事件的开始日期和时间。 这显示为 DATETIME 值，并且如果未为事件定义开始日期和时间，则为 NULL。 对于瞬时事件，此列始终为 NULL。 对于定义包含 STARTS 子句的重复事件，此列包含相应的 DATETIME 值。 与 EXECUTE_AT 列一样，此值解析任何使用的表达式。 如果没有 STARTS 子句影响事件的时间，此��为 NULL。

• ENDS

  对于定义包含 ENDS 子句的重复事件，此列包含相应的 DATETIME 值。 与 EXECUTE_AT 列一样，此值解析任何使用的表达式。 如果没有 ENDS 子句影响事件的时间，此列为 NULL。

• STATUS

  事件状态。 ENABLED、DISABLED 或 SLAVESIDE_DISABLED 中的一个。 SLAVESIDE_DISABLED 表示事件的创建发生在另一个充当复制源的 MySQL 服务器上，并被复制到当前充当副本的 MySQL 服务器，但事件目前未在副本上执行。 有关更多信息，请参见 Section 19.5.1.16, “Replication of Invoked Features”。

• ON_COMPLETION

  两个值之一 PRESERVE 或 NOT PRESERVE。

• CREATED

  事件创建的日期和时间。 这是一个 TIMESTAMP 值。

• LAST_ALTERED

  事件上次修改的日期和时间。 这是一个 TIMESTAMP 值。 如果事件自创建以来未被修改，则此值与 CREATED 值相同。

• LAST_EXECUTED

  事件上次执行的日期和时间。 这是一个 DATETIME 值。 如果事件从未执行过，则此列为 NULL。

  LAST_EXECUTED 表示事件开始的时间。 因此，ENDS 列永远不会小于 LAST_EXECUTED。

• EVENT_COMMENT

  如果事件有评论，则为评论的文本。 如果没有，则此值为空。

• ORIGINATOR

  MySQL 服务器的服务器 ID，在该服务器上创建事件时使用；用于复制。 如果在复制源上执行，则此值可能会由 ALTER EVENT 更新为发生该语句的服务器的服务器 ID。 默认值为 0。

• CHARACTER_SET_CLIENT

  事件创建时的 character_set_client 系统变量的会话值。

• COLLATION_CONNECTION

  事件创建时用户 'jon'@'ghidora' 的 collation_connection 系统变量的会话值。

• DATABASE_COLLATION

  与事件关联的数据库的排序规则。

注意

• EVENTS 是一个非标准的 INFORMATION_SCHEMA 表。

• EVENTS 表中的时间使用事件时区、当前会话时区或 UTC 显示，如 Section 27.4.4, “事件元数据” 中所述。

• 有关 SLAVESIDE_DISABLED 和 ORIGINATOR 列的更多信息，请参见 Section 19.5.1.16, “调用特性的复制”。

例子

假设用户 'jon'@'ghidora' 创建了一个名为 e_daily 的事件，然后几分钟后使用 ALTER EVENT 语句对其进行修改，如下所示：

DELIMITER |

CREATE EVENT e_daily
    ON SCHEDULE
      EVERY 1 DAY
    COMMENT 'Saves total number of sessions then clears the table each day'
    DO
      BEGIN
        INSERT INTO site_activity.totals (time, total)
          SELECT CURRENT_TIMESTAMP, COUNT(*)
            FROM site_activity.sessions;
        DELETE FROM site_activity.sessions;
      END |

DELIMITER ;

ALTER EVENT e_daily
    ENABLE;

（注意，注释可以跨越多行。）

然后，该用户可以运行以下 SELECT 语句，并获得如下输出：

mysql> SELECT * FROM INFORMATION_SCHEMA.EVENTS
       WHERE EVENT_NAME = 'e_daily'
       AND EVENT_SCHEMA = 'myschema'\G
*************************** 1\. row ***************************
       EVENT_CATALOG: def
        EVENT_SCHEMA: myschema
          EVENT_NAME: e_daily
             DEFINER: jon@ghidora
           TIME_ZONE: SYSTEM
          EVENT_BODY: SQL
    EVENT_DEFINITION: BEGIN
        INSERT INTO site_activity.totals (time, total)
          SELECT CURRENT_TIMESTAMP, COUNT(*)
            FROM site_activity.sessions;
        DELETE FROM site_activity.sessions;
      END
          EVENT_TYPE: RECURRING
          EXECUTE_AT: NULL
      INTERVAL_VALUE: 1
      INTERVAL_FIELD: DAY
            SQL_MODE: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,
                      NO_ZERO_IN_DATE,NO_ZERO_DATE,
                      ERROR_FOR_DIVISION_BY_ZERO,
                      NO_ENGINE_SUBSTITUTION
              STARTS: 2018-08-08 11:06:34
                ENDS: NULL
              STATUS: ENABLED
       ON_COMPLETION: NOT PRESERVE
             CREATED: 2018-08-08 11:06:34
        LAST_ALTERED: 2018-08-08 11:06:34
       LAST_EXECUTED: 2018-08-08 16:06:34
       EVENT_COMMENT: Saves total number of sessions then clears the
                      table each day
          ORIGINATOR: 1
CHARACTER_SET_CLIENT: utf8mb4
COLLATION_CONNECTION: utf8mb4_0900_ai_ci
  DATABASE_COLLATION: utf8mb4_0900_ai_ci

事件信息也可以通过 SHOW EVENTS 语句获取。参见 Section 15.7.7.18, “SHOW EVENTS 语句”。以下语句是等效的：

SELECT
    EVENT_SCHEMA, EVENT_NAME, DEFINER, TIME_ZONE, EVENT_TYPE, EXECUTE_AT,
    INTERVAL_VALUE, INTERVAL_FIELD, STARTS, ENDS, STATUS, ORIGINATOR,
    CHARACTER_SET_CLIENT, COLLATION_CONNECTION, DATABASE_COLLATION
  FROM INFORMATION_SCHEMA.EVENTS
  WHERE table_schema = '*db_name*'
  [AND column_name LIKE '*wild*']

SHOW EVENTS
  [FROM *db_name*]
  [LIKE '*wild*']

28.3.15 INFORMATION_SCHEMA FILES 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-files-table.html

FILES表提供关于存储 MySQL 表空间数据的文件的信息。

FILES表提供关于InnoDB数据文件的信息。在 NDB 集群中，此表还提供 NDB 集群磁盘数据表存储的文件信息。有关特定于InnoDB的其他信息，请参见本节后面的 InnoDB 注释；有关特定于 NDB 集群的其他信息，请参见 NDB 注释。

FILES表具有以下列：

• FILE_ID

  对于InnoDB：表空间 ID，也称为space_id或fil_space_t::id。

  对于NDB：文件标识符。FILE_ID列值是自动生成的。

• FILE_NAME

  对于InnoDB：数据文件的名称。每个表和通用表空间都有一个.ibd文件扩展名。撤销表空间以undo为前缀。系统表空间以ibdata为前缀。全局临时表空间以ibtmp为前缀。文件名包括文件路径，可能相对于 MySQL 数据目录（datadir系统变量的值）。

  对于NDB：由CREATE LOGFILE GROUP或ALTER LOGFILE GROUP创建的撤销日志文件的名称，或由CREATE TABLESPACE或ALTER TABLESPACE创建的数据文件的名称。在 NDB 8.0 中，文件名显示为相对路径；对于撤销日志文件，此路径相对于目录DataDir`/ndb_`NodeId`_fs/LG`；对于数据文件，相对于目录DataDir/ndb_NodeId_fs/TS。这意味着，例如，使用ALTER TABLESPACE ts ADD DATAFILE 'data_2.dat' INITIAL SIZE 256M创建的数据文件的名称显示为./data_2.dat。

• FILE_TYPE

  对于InnoDB：表空间文件类型。对于InnoDB文件，有三种可能的文件类型。TABLESPACE是任何系统、通用或每个表的表空间文件的文件类型，用于保存表、索引或其他形式的用户数据。TEMPORARY是临时表空间的文件类型。UNDO LOG是撤销表空间的文件类型，用于保存撤销记录。

  对于NDB：值之一为UNDO LOG或DATAFILE。在 NDB 8.0.13 之前，TABLESPACE也是可能的值。

• TABLESPACE_NAME

  与文件关联的表空间的名称。

  对于InnoDB：一般表空间名称在创建时指定。每表每文件表空间名称显示格式如下：*schema_name*/*table_name*。InnoDB系统表空间名称为innodb_system。全局临时表空间名称为innodb_temporary。默认撤销表空间名称��inndb_undo_001和inndb_undo_002。用户创建的撤销表空间名称在创建时指定。

• TABLE_CATALOG

  此值始终为空。

• TABLE_SCHEMA

  这总是NULL。

• TABLE_NAME

  这总是NULL。

• LOGFILE_GROUP_NAME

  对于InnoDB：这总是NULL。

  对于NDB：日志文件或数据文件所属的日志文件组的名称。

• LOGFILE_GROUP_NUMBER

  对于InnoDB：这总是NULL。

  对于NDB：对于磁盘数据撤销日志文件，日志文件所属的日志文件组的自动生成的 ID 号。这与ndbinfo.dict_obj_info表中的id列和ndbinfo.logspaces表中的log_id列以及此撤销日志文件的ndbinfo.logspaces表中的值相同。

• ENGINE

  对于InnoDB：此值始终为InnoDB。

  对于NDB：此值始终为ndbcluster。

• FULLTEXT_KEYS

  这总是NULL。

• DELETED_ROWS

  这总是NULL。

• UPDATE_COUNT

  这总是NULL。

• FREE_EXTENTS

  对于InnoDB：当前数据文件中完全空闲的扩展数。

  对于NDB：尚未被文件使用的扩展数。

• TOTAL_EXTENTS

  对于InnoDB：当前数据文件中使用的完整扩展数。文件末尾的任何部分扩展都不计算在内。

  对于NDB：分配给文件的总扩展数。

• EXTENT_SIZE

  对于InnoDB：对于具有 4KB、8KB 或 16KB 页面大小的文件，扩展大小为 1048576（1MB）。对于具有 32KB 页面大小的文件，扩展大小为 2097152 字节（2MB），对于具有 64KB 页面大小的文件，扩展大小为 4194304（4MB）。FILES不报告InnoDB页面大小。页面大小由innodb_page_size系统变量定义。扩展大小信息也可以从INNODB_TABLESPACES表中检索，其中FILES.FILE_ID = INNODB_TABLESPACES.SPACE。

  对于NDB：文件的扩展大小（以字节为单位）。

• INITIAL_SIZE

  对于InnoDB：文件的初始大小（以字节为单位）。

  对于NDB：文件的大小（以字节为单位）。这是在CREATE LOGFILE GROUP、ALTER LOGFILE GROUP、CREATE TABLESPACE或ALTER TABLESPACE语句中用于创建文件的INITIAL_SIZE子句中使用的相同值。

• MAXIMUM_SIZE

  对于InnoDB：文件中允许的最大字节数。对于除了预定义系统表空间数据文件之外的所有数据文件，该值为NULL。最大系统表空间文件大小由innodb_data_file_path定义。最大全局临时表空间文件大小由innodb_temp_data_file_path定义。对于预定义系统表空间数据文件的NULL值表示未明确定义文件大小限制。

  对于NDB：此值始终与INITIAL_SIZE值相同。

• AUTOEXTEND_SIZE

  表空间的自动扩展大小。对于NDB，AUTOEXTEND_SIZE始终为NULL。

• CREATION_TIME

  这始终为NULL。

• LAST_UPDATE_TIME

  这始终为NULL。

• LAST_ACCESS_TIME

  这始终为NULL。

• RECOVER_TIME

  这始终为NULL。

• TRANSACTION_COUNTER

  这始终为NULL。

• VERSION

  对于InnoDB：这始终为NULL。

  对于NDB：文件的版本号。

• ROW_FORMAT

  对于InnoDB：这始终为NULL。

  对于NDB：FIXED或DYNAMIC之一。

• TABLE_ROWS

  这始终为NULL。

• AVG_ROW_LENGTH

  这始终为NULL。

• DATA_LENGTH

  这始终为NULL。

• MAX_DATA_LENGTH

  这始终为NULL。

• INDEX_LENGTH

  这始终为NULL。

• DATA_FREE

  对于InnoDB：整个表空间的空闲空间总量（以字节为单位）。预定义系统表空间，包括系统表空间和临时表表空间，可能有一个或多个数据文件。

  对于NDB：这始终为NULL。

• CREATE_TIME

  这始终为NULL。

• UPDATE_TIME

  这始终为NULL。

• CHECK_TIME

  这始终为NULL。

• CHECKSUM

  这始终为NULL。

• STATUS

  对于InnoDB：默认情况下，此值为NORMAL。InnoDB文件表表空间可能报告IMPORTING，表示表空间尚不可用。

  对于NDB：对于 NDB Cluster Disk Data 文件，此值始终为NORMAL。

• EXTRA

  对于InnoDB：这始终为NULL。

  对于NDB：（NDB 8.0.15 及更高版本）对于撤销日志文件，此列显示撤销日志缓冲区大小；对于数据文件，始终为NULL。下面几段提供了更详细的解释。

  NDBCLUSTER在集群中的每个数据节点上存储每个数据文件和每个撤销日志文件的副本。在 NDB 8.0.13 及更高版本中，FILES表仅包含每个此类文件的一行。假设您在具有四个数据节点的 NDB 集群上运行以下两个语句：

  CREATE LOGFILE GROUP mygroup
      ADD UNDOFILE 'new_undo.dat'
      INITIAL_SIZE 2G
      ENGINE NDBCLUSTER;
  
  CREATE TABLESPACE myts
      ADD DATAFILE 'data_1.dat'
      USE LOGFILE GROUP mygroup
      INITIAL_SIZE 256M
      ENGINE NDBCLUSTER;
  

  运行这两个语句成功后，您应该看到与针对FILES表的查询所示的结果类似的结果：

  mysql> SELECT LOGFILE_GROUP_NAME, FILE_TYPE, EXTRA
   ->     FROM INFORMATION_SCHEMA.FILES
   ->     WHERE ENGINE = 'ndbcluster';
  
  +--------------------+-----------+--------------------------+
  | LOGFILE_GROUP_NAME | FILE_TYPE | EXTRA                    |
  +--------------------+-----------+--------------------------+
  | mygroup            | UNDO LOG  | UNDO_BUFFER_SIZE=8388608 |
  | mygroup            | DATAFILE  | NULL                     |
  +--------------------+-----------+--------------------------+
  

  NDB 8.0.13 中意外删除了撤销日志缓冲区大小信息，但在 NDB 8.0.15 中恢复了。（Bug #92796，Bug #28800252）

  在 NDB 8.0.13 之前，FILES表对于每个数据节点上的每个文件都包含一行，以及其撤销缓冲区的大小。在这些版本中，相同查询的结果每个数据节点包含一行，如下所示：

  +--------------------+-----------+-----------------------------------------+
  | LOGFILE_GROUP_NAME | FILE_TYPE | EXTRA                                   |
  +--------------------+-----------+-----------------------------------------+
  | mygroup            | UNDO LOG  | CLUSTER_NODE=5;UNDO_BUFFER_SIZE=8388608 |
  | mygroup            | UNDO LOG  | CLUSTER_NODE=6;UNDO_BUFFER_SIZE=8388608 |
  | mygroup            | UNDO LOG  | CLUSTER_NODE=7;UNDO_BUFFER_SIZE=8388608 |
  | mygroup            | UNDO LOG  | CLUSTER_NODE=8;UNDO_BUFFER_SIZE=8388608 |
  | mygroup            | DATAFILE  | CLUSTER_NODE=5                          |
  | mygroup            | DATAFILE  | CLUSTER_NODE=6                          |
  | mygroup            | DATAFILE  | CLUSTER_NODE=7                          |
  | mygroup            | DATAFILE  | CLUSTER_NODE=8                          |
  +--------------------+-----------+-----------------------------------------+
  

注意

• FILES是一个非标准的INFORMATION_SCHEMA表。

• 截至 MySQL 8.0.21，您必须具有PROCESS权限才能查询此表。

InnoDB 注意事项

以下注意事项适用于InnoDB数据文件。

• FILES报告的信息是从InnoDB内存中的打开文件缓存中获取的，而INNODB_DATAFILES从InnoDB的SYS_DATAFILES内部数据字典表中获取数据。

• FILES提供的信息包括全局临时表空间信息，这些信息在InnoDB的SYS_DATAFILES内部数据字典表中不可用，因此不包括在INNODB_DATAFILES中。

• 当存在单独的撤销表空间时，FILES中显示撤销表空间信息，这在 MySQL 8.0 中是默认情况。

• 以下查询返回与InnoDB表空间相关的所有FILES表信息。

  SELECT
    FILE_ID, FILE_NAME, FILE_TYPE, TABLESPACE_NAME, FREE_EXTENTS,
    TOTAL_EXTENTS, EXTENT_SIZE, INITIAL_SIZE, MAXIMUM_SIZE,
    AUTOEXTEND_SIZE, DATA_FREE, STATUS
  FROM INFORMATION_SCHEMA.FILES
  WHERE ENGINE='InnoDB'\G
  

NDB 注意事项

• FILES表仅提供有关磁盘数据文件的信息；您不能用它来确定单个NDB表的磁盘空间分配或可用性。但是，可以使用ndb_desc来查看每个存储在磁盘上的NDB表分配了多少空间，以及该表在磁盘上存储数据的剩余可用空间。

• 从 NDB 8.0.29 开始，FILES表中的许多信息也可以在ndbinfo.files表中找到。

• CREATION_TIME、LAST_UPDATE_TIME和LAST_ACCESSED的值由操作系统报告，而不是由NDB存储引擎提供。如果操作系统未提供值，则这些列显示NULL。

• TOTAL EXTENTS和FREE_EXTENTS列之间的差值是当前文件使用的区段数：

  SELECT TOTAL_EXTENTS - FREE_EXTENTS AS extents_used
      FROM INFORMATION_SCHEMA.FILES
      WHERE FILE_NAME = './myfile.dat';
  

  要近似计算文件使用的磁盘空间量，请将该差值乘以EXTENT_SIZE列的值，该值表示文件的一个区段的大小（以字节为单位）：

  SELECT (TOTAL_EXTENTS - FREE_EXTENTS) * EXTENT_SIZE AS bytes_used
      FROM INFORMATION_SCHEMA.FILES
      WHERE FILE_NAME = './myfile.dat';
  

  同样，可以通过将FREE_EXTENTS乘以EXTENT_SIZE来估算给定文件中剩余可用空间的量：

  SELECT FREE_EXTENTS * EXTENT_SIZE AS bytes_free
      FROM INFORMATION_SCHEMA.FILES
      WHERE FILE_NAME = './myfile.dat';
  

  重要提示

  前述查询产生的字节值仅为近似值，其精度与EXTENT_SIZE的值成反比。也就是说，EXTENT_SIZE越大，近似值的准确性就越低。

  还要记住，一旦使用了一个区段，就不能再次释放它，除非删除包含它的数据文件。这意味着从磁盘数据表中删除的数据不会释放磁盘空间。

  可以在CREATE TABLESPACE语句中设置区段大小。有关更多信息，请参见第 15.1.21 节，“CREATE TABLESPACE Statement”。

• 在 NDB 8.0.13 之前，在创建日志文件组后，FILES表中存在一个额外的行，FILE_NAME列中为NULL。在 NDB 8.0.13 及更高版本中，不再显示这一行—该行不对应任何文件，并且需要查询ndbinfo.logspaces表以获取撤销日志文件使用信息。有关更多信息，请参见此表的描述以及第 25.6.11.1 节，“NDB Cluster Disk Data Objects”。

  本项目中剩余的讨论仅适用于 NDB 8.0.12 及更早版本。对于FILE_NAME列中为NULL的行，FILE_ID列的值始终为0，FILE_TYPE列的值始终为UNDO LOG，STATUS列的值始终为NORMAL。ENGINE列的值始终为ndbcluster。

  在此行中，FREE_EXTENTS列显示给定日志文件组的所有撤销文件可用的总空闲区段数，其名称和编号分别显示在LOGFILE_GROUP_NAME和LOGFILE_GROUP_NUMBER列中。

  假设您的 NDB Cluster 上没有现有的日志文件组，并且使用以下语句创建一个：

  mysql> CREATE LOGFILE GROUP lg1
           ADD UNDOFILE 'undofile.dat'
           INITIAL_SIZE = 16M
           UNDO_BUFFER_SIZE = 1M
           ENGINE = NDB;
  

  当您查询 FILES 表时，现在可以看到这个NULL行：

  mysql> SELECT DISTINCT
           FILE_NAME AS File,
           FREE_EXTENTS AS Free,
           TOTAL_EXTENTS AS Total,
           EXTENT_SIZE AS Size,
           INITIAL_SIZE AS Initial
           FROM INFORMATION_SCHEMA.FILES;
  +--------------+---------+---------+------+----------+
  | File         | Free    | Total   | Size | Initial  |
  +--------------+---------+---------+------+----------+
  | undofile.dat |    NULL | 4194304 |    4 | 16777216 |
  | NULL         | 4184068 |    NULL |    4 |     NULL |
  +--------------+---------+---------+------+----------+
  

  用于撤消日志记录的可用自由扩展总数始终略少于日志文件组中所有撤消文件的TOTAL_EXTENTS列值之和，这是由于维护撤消文件所需的开销。可以通过向日志文件组添加第二个撤消文件，然后针对 FILES 表重复上一个查询来看到这一点：

  mysql> ALTER LOGFILE GROUP lg1
           ADD UNDOFILE 'undofile02.dat'
           INITIAL_SIZE = 4M
           ENGINE = NDB;
  
  mysql> SELECT DISTINCT
           FILE_NAME AS File,
           FREE_EXTENTS AS Free,
           TOTAL_EXTENTS AS Total,
           EXTENT_SIZE AS Size,
           INITIAL_SIZE AS Initial
           FROM INFORMATION_SCHEMA.FILES;
  +----------------+---------+---------+------+----------+
  | File           | Free    | Total   | Size | Initial  |
  +----------------+---------+---------+------+----------+
  | undofile.dat   |    NULL | 4194304 |    4 | 16777216 |
  | undofile02.dat |    NULL | 1048576 |    4 |  4194304 |
  | NULL           | 5223944 |    NULL |    4 |     NULL |
  +----------------+---------+---------+------+----------+
  

  通过将自由扩展的数量乘以初始大小来近似计算使用此日志文件组的磁盘数据表的撤消日志记录的可用空间的字节数：

  mysql> SELECT
           FREE_EXTENTS AS 'Free Extents',
           FREE_EXTENTS * EXTENT_SIZE AS 'Free Bytes'
           FROM INFORMATION_SCHEMA.FILES
           WHERE LOGFILE_GROUP_NAME = 'lg1'
           AND FILE_NAME IS NULL;
  +--------------+------------+
  | Free Extents | Free Bytes |
  +--------------+------------+
  |      5223944 |   20895776 |
  +--------------+------------+
  

  如果您创建了一个 NDB 集群磁盘数据表，并插入了一些行，您可以看到之后大约还有多少空间用于撤消日志记录，例如：

  mysql> CREATE TABLESPACE ts1
           ADD DATAFILE 'data1.dat'
           USE LOGFILE GROUP lg1
           INITIAL_SIZE 512M
           ENGINE = NDB;
  
  mysql> CREATE TABLE dd (
           c1 INT NOT NULL PRIMARY KEY,
           c2 INT,
           c3 DATE
           )
           TABLESPACE ts1 STORAGE DISK
           ENGINE = NDB;
  
  mysql> INSERT INTO dd VALUES
           (NULL, 1234567890, '2007-02-02'),
           (NULL, 1126789005, '2007-02-03'),
           (NULL, 1357924680, '2007-02-04'),
           (NULL, 1642097531, '2007-02-05');
  
  mysql> SELECT
           FREE_EXTENTS AS 'Free Extents',
           FREE_EXTENTS * EXTENT_SIZE AS 'Free Bytes'
           FROM INFORMATION_SCHEMA.FILES
           WHERE LOGFILE_GROUP_NAME = 'lg1'
           AND FILE_NAME IS NULL;
  +--------------+------------+
  | Free Extents | Free Bytes |
  +--------------+------------+
  |      5207565 |   20830260 |
  +--------------+------------+
  

• 在 NDB 8.0.13 之前，FILES 表中为每个 NDB 集群磁盘数据表空间存在额外的行。因为它不对应实际文件，所以在 NDB 8.0.13 中被移除。该行的FILE_NAME列值为NULL，FILE_ID列值始终为0，FILE_TYPE列值始终为TABLESPACE，STATUS列值始终为NORMAL，ENGINE列值始终为NDBCLUSTER。

  在 NDB 8.0.13 及更高版本中，您可以使用 ndb_desc 实用程序获取有关磁盘数据表空间的信息。有关更多信息，请参阅 第 25.6.11.1 节，“NDB 集群磁盘数据对象” 的描述，以及 ndb_desc 的说明。

• 有关更多信息以及有关创建、删除和获取有关 NDB 集群磁盘数据对象的示例，请参阅 第 25.6.11 节，“NDB 集群磁盘数据表”。

28.3.16 INFORMATION_SCHEMA KEY_COLUMN_USAGE 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-key-column-usage-table.html

KEY_COLUMN_USAGE 表描述了哪些关键列具有约束。该表不提供有关功能键部分的信息，因为它们是表达式，而该表仅提供有关列的信息。

KEY_COLUMN_USAGE 表具有以下列：

• CONSTRAINT_CATALOG

  约束所属的目录的名称。此值始终为def。

• CONSTRAINT_SCHEMA

  约束所属的模式（数据库）的名称。

• CONSTRAINT_NAME

  约束的名称。

• TABLE_CATALOG

  表所属的目录的名称。此值始终为def。

• TABLE_SCHEMA

  表所属的模式（数据库）的名称。

• TABLE_NAME

  具有约束的表的名称。

• COLUMN_NAME

  具有约束的列的名称。

  如果约束是外键，则这是外键的列，而不是外键引用的列。

• ORDINAL_POSITION

  列在约束中的位置，而不是表中的列位置。列位置从 1 开始编号。

• POSITION_IN_UNIQUE_CONSTRAINT

  对于唯一约束和主键约束为NULL。对于外键约束，此列是被引用的表中键的序数位置。

• REFERENCED_TABLE_SCHEMA

  约束引用的模式的名称。

• REFERENCED_TABLE_NAME

  约束引用的表的名称。

• REFERENCED_COLUMN_NAME

  约束引用的列的名称。

假设有两个名为t1和t3的表，其定义如下：

CREATE TABLE t1
(
    s1 INT,
    s2 INT,
    s3 INT,
    PRIMARY KEY(s3)
) ENGINE=InnoDB;

CREATE TABLE t3
(
    s1 INT,
    s2 INT,
    s3 INT,
    KEY(s1),
    CONSTRAINT CO FOREIGN KEY (s2) REFERENCES t1(s3)
) ENGINE=InnoDB;

对于这两个表，KEY_COLUMN_USAGE 表有两行：

• 具有CONSTRAINT_NAME = 'PRIMARY'、TABLE_NAME = 't1'、COLUMN_NAME = 's3'、ORDINAL_POSITION = 1、POSITION_IN_UNIQUE_CONSTRAINT = NULL的一行。

  对于NDB：此值始终为NULL。

• 具有CONSTRAINT_NAME = 'CO'、TABLE_NAME = 't3'、COLUMN_NAME = 's2'、ORDINAL_POSITION = 1、POSITION_IN_UNIQUE_CONSTRAINT = 1的一行。

28.3.17 INFORMATION_SCHEMA KEYWORDS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-keywords-table.html

KEYWORDS 表列出了 MySQL 认为是关键字的单词，并针对每个单词指示它是否是保留的。在某些情况下，保留关键字可能需要特殊处理，例如在用作标识符时需要特殊引用（参见第 11.3 节，“关键字和保留字”）。这个表为应用程序提供了 MySQL 关键字信息的运行时来源。

在 MySQL 8.0.13 之前，选择KEYWORDS表而没有选择默认数据库会产生错误。（Bug #90160, Bug #27729859）

KEYWORDS 表具有以下列：

• WORD

  关键字。

• RESERVED

  一个整数，指示关键字是保留的（1）还是非保留的（0）。

这些查询分别列出所有关键字、所有保留关键字和所有非保留关键字：

SELECT * FROM INFORMATION_SCHEMA.KEYWORDS;
SELECT WORD FROM INFORMATION_SCHEMA.KEYWORDS WHERE RESERVED = 1;
SELECT WORD FROM INFORMATION_SCHEMA.KEYWORDS WHERE RESERVED = 0;

后两个查询等同于：

SELECT WORD FROM INFORMATION_SCHEMA.KEYWORDS WHERE RESERVED;
SELECT WORD FROM INFORMATION_SCHEMA.KEYWORDS WHERE NOT RESERVED;

如果你从源代码构建 MySQL，构建过程会生成一个keyword_list.h头文件，其中包含关键字及其保留状态的数组。该文件可以在构建目录下的sql目录中找到。对于需要关键字列表的应用程序，这个文件可能很有用。

28.3.18 信息模式 ndb_transid_mysql_connection_map 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-ndb-transid-mysql-connection-map-table.html

ndb_transid_mysql_connection_map表提供了NDB事务、NDB事务协调器和连接到 NDB 集群作为 API 节点的 MySQL 服务器之间的映射。在填充server_operations和server_transactions表时，将使用此信息ndbinfo NDB 集群信息数据库。

INFORMATION_SCHEMA名称	SHOW名称	备注
mysql_connection_id		MySQL 服务器连接 ID
node_id		事务协调器节点 ID
ndb_transid		NDB事务 ID

mysql_connection_id与SHOW PROCESSLIST输出中显示的连接或会话 ID 相同。

与此表相关联的SHOW语句不存在。

这是一个非标准表，特定于 NDB 集群。它作为一个INFORMATION_SCHEMA插件实现；您可以通过检查SHOW PLUGINS的输出来验证它是否受支持。如果启用了ndb_transid_mysql_connection_map支持，此语句的输出将包括一个具有此名称的插件，类型为INFORMATION SCHEMA，并且状态为ACTIVE，如下所示（使用强调文本）：

mysql> SHOW PLUGINS;
+----------------------------------+--------+--------------------+---------+---------+
| Name                             | Status | Type               | Library | License |
+----------------------------------+--------+--------------------+---------+---------+
| binlog                           | ACTIVE | STORAGE ENGINE     | NULL    | GPL     |
| mysql_native_password            | ACTIVE | AUTHENTICATION     | NULL    | GPL     |
| sha256_password                  | ACTIVE | AUTHENTICATION     | NULL    | GPL     |
| caching_sha2_password            | ACTIVE | AUTHENTICATION     | NULL    | GPL     |
| sha2_cache_cleaner               | ACTIVE | AUDIT              | NULL    | GPL     |
| daemon_keyring_proxy_plugin      | ACTIVE | DAEMON             | NULL    | GPL     |
| CSV                              | ACTIVE | STORAGE ENGINE     | NULL    | GPL     |
| MEMORY                           | ACTIVE | STORAGE ENGINE     | NULL    | GPL     |
| InnoDB                           | ACTIVE | STORAGE ENGINE     | NULL    | GPL     |
| INNODB_TRX                       | ACTIVE | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_CMP                       | ACTIVE | INFORMATION SCHEMA | NULL    | GPL     |

...

| INNODB_SESSION_TEMP_TABLESPACES  | ACTIVE | INFORMATION SCHEMA | NULL    | GPL     |
| MyISAM                           | ACTIVE | STORAGE ENGINE     | NULL    | GPL     |
| MRG_MYISAM                       | ACTIVE | STORAGE ENGINE     | NULL    | GPL     |
| PERFORMANCE_SCHEMA               | ACTIVE | STORAGE ENGINE     | NULL    | GPL     |
| TempTable                        | ACTIVE | STORAGE ENGINE     | NULL    | GPL     |
| ARCHIVE                          | ACTIVE | STORAGE ENGINE     | NULL    | GPL     |
| BLACKHOLE                        | ACTIVE | STORAGE ENGINE     | NULL    | GPL     |
| ndbcluster                       | ACTIVE | STORAGE ENGINE     | NULL    | GPL     |
| ndbinfo                          | ACTIVE | STORAGE ENGINE     | NULL    | GPL     |
*| ndb_transid_mysql_connection_map | ACTIVE | INFORMATION SCHEMA | NULL    | GPL     |*
| ngram                            | ACTIVE | FTPARSER           | NULL    | GPL     |
| mysqlx_cache_cleaner             | ACTIVE | AUDIT              | NULL    | GPL     |
| mysqlx                           | ACTIVE | DAEMON             | NULL    | GPL     |
+----------------------------------+--------+--------------------+---------+---------+
47 rows in set (0.01 sec)

插件默认启用。您可以通过使用--ndb-transid-mysql-connection-map选项启动服务器来禁用它（或者强制服务器不运行，除非插件启动）。如果插件被禁用，状态将显示为SHOW PLUGINS中的DISABLED。插件无法在运行时启用或禁用。

尽管此表及其列的名称以小写显示，但在 SQL 语句中引用它们时，可以使用大写或小写。

要创建此表，MySQL 服务器必须是与 NDB 集群分发一起提供的二进制文件，或者是从启用了NDB存储引擎支持的 NDB 集群源代码构建的。它在标准 MySQL 8.0 服务器中不可用。

28.3.19 INFORMATION_SCHEMA OPTIMIZER_TRACE 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-optimizer-trace-table.html

OPTIMIZER_TRACE 表提供了由优化器追踪功能为被追踪语句生成的信息。要启用跟踪，请使用optimizer_trace 系统变量。有关详细信息，请参阅 MySQL 内部：跟踪优化器。

OPTIMIZER_TRACE 表包含以下列：

• QUERY

  被追踪语句的文本。

• TRACE

  追踪内容，以JSON格式。

• MISSING_BYTES_BEYOND_MAX_MEM_SIZE

  每个记忆的追踪都是一个字符串，随着优化的进行而扩展并向其附加数据。optimizer_trace_max_mem_size 变量设置了当前所有记忆追踪使用的内存总量的限制。如果达到此限制，当前追踪不会被扩展（因此是不完整的），MISSING_BYTES_BEYOND_MAX_MEM_SIZE列显示了追踪中缺少的字节数。

• INSUFFICIENT_PRIVILEGES

  如果被追踪的查询使用了具有SQL SECURITY值为DEFINER的视图或存储过程，可能会导致除定义者以外的用户无法查看查询的追踪。在这种情况下，追踪显示为空，INSUFFICIENT_PRIVILEGES的值为 1。否则，该值为 0。

28.3.20 INFORMATION_SCHEMA PARAMETERS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-parameters-table.html

PARAMETERS表提供有关存储例程（存储过程和存储函数）的参数以及存储函数的返回值的信息。PARAMETERS表不包括内置（本机）函数或可加载函数。

PARAMETERS表具有以下列：

• SPECIFIC_CATALOG

  包含参数的例程所属的目录的名称。该值始终为def。

• SPECIFIC_SCHEMA

  包含参数的例程所属的模式（数据库）的名称。

• SPECIFIC_NAME

  包含参数的例程名称。

• ORDINAL_POSITION

  对于存储过程或函数的连续参数，ORDINAL_POSITION值为 1、2、3 等。对于存储函数，还有一行适用于函数返回值（由RETURNS子句描述）。返回值不是真正的参数，因此描述它的行具有以下独特特征：

  • ORDINAL_POSITION值为 0。

  • PARAMETER_NAME和PARAMETER_MODE值为NULL，因为返回值没有名称，模式也不适用。

• PARAMETER_MODE

  参数的模式。该值为IN、OUT或INOUT之一。对于存储函数的返回值，该值为NULL。

• PARAMETER_NAME

  参数的名称。对于存储函数的返回值，该值为NULL。

• DATA_TYPE

  参数数据类型。

  DATA_TYPE值仅为类型名称，没有其他信息。DTD_IDENTIFIER值包含类型名称，可能还包含其他信息，如精度或长度。

• CHARACTER_MAXIMUM_LENGTH

  对于字符串参数，以字符为单位的最大长度。

• CHARACTER_OCTET_LENGTH

  对于字符串参数，以字节为单位的最大长度。

• NUMERIC_PRECISION

  对于数值参数，数值精度。

• NUMERIC_SCALE

  对于数值参数，数值刻度。

• DATETIME_PRECISION

  对于时间参数，分数秒精度。

• CHARACTER_SET_NAME

  对于字符串参数，字符集名称。

• COLLATION_NAME

  对于字符串参数，排序名称。

• DTD_IDENTIFIER

  参数数据类型。

  DATA_TYPE值仅为类型名称，没有其他信息。DTD_IDENTIFIER值包含类型名称，可能还包含其他信息，如精度或长度。

• ROUTINE_TYPE

  对于存储过程，PROCEDURE，对于存储函数，FUNCTION。

28.3.21 INFORMATION_SCHEMA PARTITIONS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-partitions-table.html

PARTITIONS 表提供有关表分区的信息。该表中的每一行对应��分区表的单个分区或子分区。有关分区表的更多信息，请参阅 第二十六章，“分区”。

PARTITIONS 表包含以下列：

• TABLE_CATALOG

  表所属的目录的名称。该值始终为 def。

• TABLE_SCHEMA

  表所属模式（数据库）的名称。

• TABLE_NAME

  包含分区的表的名称。

• PARTITION_NAME

  分区的名称。

• SUBPARTITION_NAME

  如果 PARTITIONS 表行表示子分区，则为子分区的名称；否则为 NULL。

  对于 NDB：该值始终为 NULL。

• PARTITION_ORDINAL_POSITION

  所有分区按照定义的顺序进行索引，其中 1 是分配给第一个分区的编号。随着分区的添加、删除和重新组织，索引可能会发生变化；此列中显示的编号反映了当前顺序，考虑到任何索引更改。

• SUBPARTITION_ORDINAL_POSITION

  在给定分区内的子分区也按照表内分区的方式进行索引和重新索引。

• PARTITION_METHOD

  值为 RANGE、LIST、HASH、LINEAR HASH、KEY 或 LINEAR KEY 中的一个；即 26.2 节，“分区类型” 中讨论的可用分区类型之一。

• SUBPARTITION_METHOD

  值为 HASH、LINEAR HASH、KEY 或 LINEAR KEY 中的一个；即 26.2.6 节，“子分区” 中讨论的可用子分区类型之一。

• PARTITION_EXPRESSION

  在创建表的 CREATE TABLE 或 ALTER TABLE 语句中使用的分区函数的表达式，该表达式创建了表的当前分区方案。

  例如，考虑在 test 数据库中使用以下语句创建的分区表：

  CREATE TABLE tp (
      c1 INT,
      c2 INT,
      c3 VARCHAR(25)
  )
  PARTITION BY HASH(c1 + c2)
  PARTITIONS 4;
  

  PARTITIONS 表中来自此表分区的 PARTITIONS 表行中的 PARTITION_EXPRESSION 列显示 c1 + c2，如下所示：

  mysql> SELECT DISTINCT PARTITION_EXPRESSION
         FROM INFORMATION_SCHEMA.PARTITIONS
         WHERE TABLE_NAME='tp' AND TABLE_SCHEMA='test';
  +----------------------+
  | PARTITION_EXPRESSION |
  +----------------------+
  | c1 + c2              |
  +----------------------+
  

  对于未明确分区的表，无论存储引擎如何，此列始终为 NULL。

• SUBPARTITION_EXPRESSION

  这与定义表的分区表达式的子分区表达式的工作方式相同，就像PARTITION_EXPRESSION为定义表的分区而使用的分区表达式一样。

  如果表没有子分区，这一列为NULL。

• PARTITION_DESCRIPTION

  此列用于RANGE和LIST分区。对于RANGE分区，它包含在分区的VALUES LESS THAN子句中设置的值，可以是整数或MAXVALUE。对于LIST分区，此列包含在分区的VALUES IN子句中定义的值，这是一个逗号分隔的整数值列表。

  对于PARTITION_METHOD不是RANGE或LIST的分区，此列始终为NULL。

• TABLE_ROWS

  分区中的表行数。

  对于分区的InnoDB表，TABLE_ROWS列中给出的行数仅是 SQL 优化中使用的估计值，可能并不总是准确。

  对于NDB表，您还可以使用ndb_desc实用程序获取此信息。

• AVG_ROW_LENGTH

  存储在此分区或子分区中的行的平均长度，以字节为单位。这与DATA_LENGTH除以TABLE_ROWS相同。

  对于NDB表，您还可以使用ndb_desc实用程序获取此信息。

• DATA_LENGTH

  存储在此分区或子分区中的所有行的总长度，以字节为单位；即存储在分区或子分区中的字节总数。

  对于NDB表，您还可以使用ndb_desc实用程序获取此信息。

• MAX_DATA_LENGTH

  可以存储在此分区或子分区中的最大字节数。

  对于NDB表，您还可以使用ndb_desc实用程序获取此信息。

• INDEX_LENGTH

  此分区或子分区的索引文件长度，以字节为单位。

  对于NDB表的分区，无论表是否使用隐式或显式分区，INDEX_LENGTH列的值始终为 0。但是，您可以使用ndb_desc实用程序获取等效信息。

• DATA_FREE

  分配给分区或子分区但未使用的字节数。

  对于NDB表，您还可以使用ndb_desc实用程序获取此信息。

• CREATE_TIME

  分区或子分区创建的时间。

• UPDATE_TIME

  分区或子分区上次修改的时间。

• CHECK_TIME

  此分区或子分区所属表上次检查的时间。

  对于分区的InnoDB表，该值始终为NULL。

• CHECKSUM

  校验和值（如果有）；否则为NULL。

• PARTITION_COMMENT

  如果分区有评论，则评论的文本。如果没有，则该值为空。

  分区评论的最大长度定义为 1024 个字符，PARTITION_COMMENT列的显示宽度也是 1024 个字符，以匹配此限制。

• NODEGROUP

  分区所属的节点组。对于 NDB 集群表，始终为default。对于使用除NDB之外的存储引擎的分区表，该值也为default。否则，此列为空。

• TABLESPACE_NAME

  分区所属表空间的名称。该值始终为DEFAULT，除非表使用NDB存储引擎（请参阅本节末尾的注释）。

注释

• PARTITIONS是一个非标准的INFORMATION_SCHEMA表。

• 使用除NDB之外的任何存储引擎并且未分区的表在PARTITIONS表中有一行。但是，PARTITION_NAME、SUBPARTITION_NAME、PARTITION_ORDINAL_POSITION、SUBPARTITION_ORDINAL_POSITION、PARTITION_METHOD、SUBPARTITION_METHOD、PARTITION_EXPRESSION、SUBPARTITION_EXPRESSION和PARTITION_DESCRIPTION列的值均为NULL。此外，在这种情况下，PARTITION_COMMENT列为空。

• 在NDB集群中，未明确分区的NDB表在PARTITIONS表中为每个数据节点有一行。对于每一行：

  • SUBPARTITION_NAME、SUBPARTITION_ORDINAL_POSITION、SUBPARTITION_METHOD、PARTITION_EXPRESSION、SUBPARTITION_EXPRESSION、CREATE_TIME、UPDATE_TIME、CHECK_TIME、CHECKSUM和TABLESPACE_NAME列均为NULL。

  • PARTITION_METHOD始终为AUTO。

  • NODEGROUP列为default。

  • PARTITION_COMMENT列为空。

28.3.22 INFORMATION_SCHEMA PLUGINS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-plugins-table.html

PLUGINS 表提供有关服务器插件的信息。

PLUGINS 表具有以下列：

• PLUGIN_NAME

  在诸如 INSTALL PLUGIN 和 UNINSTALL PLUGIN 等语句中用于引用插件的名称。

• PLUGIN_VERSION

  插件的一般类型描述符中的版本。

• PLUGIN_STATUS

  插件状态，为 ACTIVE、INACTIVE、DISABLED、DELETING 或 DELETED。

• PLUGIN_TYPE

  插件类型，如 STORAGE ENGINE、INFORMATION_SCHEMA 或 AUTHENTICATION。

• PLUGIN_TYPE_VERSION

  插件的特定类型描述符中的版本。

• PLUGIN_LIBRARY

  插件共享库文件的名称。这是在诸如 INSTALL PLUGIN 和 UNINSTALL PLUGIN 等语句中用于引用插件文件的名称。此文件位于由 plugin_dir 系统变量命名的目录中。如果库名称为 NULL，则插件已编译并且无法使用 UNINSTALL PLUGIN 卸载。

• PLUGIN_LIBRARY_VERSION

  插件 API 接口版本。

• PLUGIN_AUTHOR

  插件作者。

• PLUGIN_DESCRIPTION

  插件的简要描述。

• PLUGIN_LICENSE

  插件许可证（例如，GPL）。

• LOAD_OPTION

  插件加载方式。值为 OFF、ON、FORCE 或 FORCE_PLUS_PERMANENT。参见 Section 7.6.1, “Installing and Uninstalling Plugins”。

注意事项

• PLUGINS 是一个非标准的 INFORMATION_SCHEMA 表。

• 对于使用 INSTALL PLUGIN 安装的插件，PLUGIN_NAME 和 PLUGIN_LIBRARY 值也会在 mysql.plugin 表中注册。

• 有关构��� PLUGINS 表信息基础的插件数据结构，请参阅 MySQL 插件 API。

插件信息也可以通过 SHOW PLUGINS 语句获取。参见 Section 15.7.7.25, “SHOW PLUGINS Statement”。这些语句是等效的：

SELECT
  PLUGIN_NAME, PLUGIN_STATUS, PLUGIN_TYPE,
  PLUGIN_LIBRARY, PLUGIN_LICENSE
FROM INFORMATION_SCHEMA.PLUGINS;

SHOW PLUGINS;

28.3.23 信息模式 PROCESSLIST 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-processlist-table.html

重要

INFORMATION_SCHEMA.PROCESSLIST 已弃用，并将在未来的 MySQL 版本中移除。因此，使用此表的 SHOW PROCESSLIST 的实现也已弃用。建议改用性能模式实现的 PROCESSLIST。

MySQL 进程列表显示当前在服务器内执行的线程集合正在执行的操作。PROCESSLIST 表是进程信息的一个来源。要比较此表与其他来源，请参见 进程信息来源。

PROCESSLIST 表具有以下列：

• ID

  连接标识符。这是在 SHOW PROCESSLIST 语句中显示的相同值，在性能模式 threads 表中的 PROCESSLIST_ID 列中显示，并在线程内部由 CONNECTION_ID() 函数返回。

• USER

  发出语句的 MySQL 用户。system user 的值指代服务器生成的非客户端线程，用于内部处理任务，例如，延迟行处理程序线程或在副本主机上使用的 I/O 或 SQL 线程。对于 system user，在 Host 列中没有指定主机。unauthenticated user 指代已与客户端连接关联但尚未进行客户端用户认证的线程。event_scheduler 指代监视计划事件的线程（参见 第 27.4 节，“使用事件调度程序”）。

  注意

  USER 值为 system user 与 SYSTEM_USER 权限是不同的。前者指定内部线程。后者区分系统用户和常规用户账户类别（参见 第 8.2.11 节，“账户类别”）。

• HOST

  发出语句的客户端的主机名（对于system user，没有主机）。TCP/IP 连接的主机名以*host_name*:*client_port*的格式报告，以便更容易确定哪个客户端在执行什么操作。

• DB

  线程的默认数据库，如果没有选择任何数据库则为NULL。

• COMMAND

  线程代表客户端执行的命令类型，如果会话空闲则为Sleep。有关线程命令的描述，请参见 Section 10.14, “Examining Server Thread (Process) Information” Information")。此列的值对应于客户端/服务器协议的COM_*xxx*命令和Com_*xxx*状态变量。请参见 Section 7.1.10, “Server Status Variables”。

• TIME

  线程在当前状态下已经持续的秒数。对于复制 SQL 线程，该值是最后一个复制事件的时间戳与复制主机的实际时间之间的秒数。请参见 Section 19.2.3, “Replication Threads”。

• STATE

  表示线程正在执行的操作、事件或状态。有关STATE值的描述，请参见 Section 10.14, “Examining Server Thread (Process) Information” Information")。

  大多数状态对应于非常快速的操作。如果一个线程在给定状态停留了很多秒，可能存在需要调查的问题。

• INFO

  线程正在执行的语句，如果没有执行语句则为NULL。该语句可能是发送到服务器的语句，或者如果语句执行其他语句，则是最内层的语句。例如，如果一个CALL语句执行一个正在执行SELECT语句的存储过程，INFO值显示SELECT语句。

注释

• PROCESSLIST是一个非标准的INFORMATION_SCHEMA表。

• 类似于SHOW PROCESSLIST语句的输出，PROCESSLIST表提供了关于所有线程的信息，即使是属于其他用户的线程，如果你拥有PROCESS权限。否则（没有PROCESS权限），非匿名用户可以访问自己线程的信息，但不能访问其他用户的线程，匿名用户无法访问线程信息。

• 如果一个 SQL 语句引用了PROCESSLIST表，MySQL 会在语句执行开始时一次性填充整个表，因此在语句执行期间存在读一致性。对于多语句事务，不存在读一致性。

以下语句是等价的：

SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST

SHOW FULL PROCESSLIST

28.3.24 INFORMATION_SCHEMA PROFILING 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-profiling-table.html

PROFILING 表提供语句分析信息。其内容对应于 SHOW PROFILE 和 SHOW PROFILES 语句产生的信息（参见 Section 15.7.7.30, “SHOW PROFILE Statement”）。除非将 profiling 会话变量设置为 1，否则该表为空。

注意

该表已被弃用；预计在未来的 MySQL 版本中将被移除。请改用 Performance Schema；参见 Section 29.19.1, “Query Profiling Using Performance Schema”。

PROFILING 表具有以下列：

• QUERY_ID

  数字语句标识符。

• SEQ

  表示具有相同 QUERY_ID 值的行的显示顺序的序列号。

• STATE

  应用于行测量的受监视状态。

• DURATION

  语句执行在给定状态中保持的时间，以秒为单位。

• CPU_USER, CPU_SYSTEM

  用户和系统 CPU 使用时间，以秒为单位。

• CONTEXT_VOLUNTARY, CONTEXT_INVOLUNTARY

  发生了多少次自愿和非自愿的上下文切换。

• BLOCK_OPS_IN, BLOCK_OPS_OUT

  块输入和输出操作的数量。

• MESSAGES_SENT, MESSAGES_RECEIVED

  发送和接收的通信消息数量。

• PAGE_FAULTS_MAJOR, PAGE_FAULTS_MINOR

  主要和次要页面错误的数量。

• SWAPS

  发生了多少次交换。

• SOURCE_FUNCTION, SOURCE_FILE, 和 SOURCE_LINE

  表示在源代码中执行的受监视状态的位置。

注意

• PROFILING 是一个非标准的 INFORMATION_SCHEMA 表。

也可以从 SHOW PROFILE 和 SHOW PROFILES 语句中获取分析信息。参见 Section 15.7.7.30, “SHOW PROFILE Statement”。例如，以下查询是等效的：

SHOW PROFILE FOR QUERY 2;

SELECT STATE, FORMAT(DURATION, 6) AS DURATION
FROM INFORMATION_SCHEMA.PROFILING
WHERE QUERY_ID = 2 ORDER BY SEQ;

28.3.25 INFORMATION_SCHEMA REFERENTIAL_CONSTRAINTS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-referential-constraints-table.html

REFERENTIAL_CONSTRAINTS表提供有关外键的信息。

REFERENTIAL_CONSTRAINTS表具有以下列：

• CONSTRAINT_CATALOG

  约束所属的目录的名称。此值始终为def。

• CONSTRAINT_SCHEMA

  约束所属的模式（数据库）的名称。

• CONSTRAINT_NAME

  约束的名称。

• UNIQUE_CONSTRAINT_CATALOG

  包含约束引用的唯一约束的目录的名称。此值始终为def。

• UNIQUE_CONSTRAINT_SCHEMA

  包含约束引用的唯一约束的模式的名称。

• UNIQUE_CONSTRAINT_NAME

  约束引用的唯一约束的名称。

• MATCH_OPTION

  约束MATCH属性的值。目前唯一有效的值是NONE。

• UPDATE_RULE

  约束ON UPDATE属性的值。可能的值为CASCADE、SET NULL、SET DEFAULT、RESTRICT、NO ACTION。

• DELETE_RULE

  约束ON DELETE属性的值。可能的值为CASCADE、SET NULL、SET DEFAULT、RESTRICT、NO ACTION。

• TABLE_NAME

  表的名称。此值与TABLE_CONSTRAINTS表中的相同。

• REFERENCED_TABLE_NAME

  约束引用的表的名称。

28.3.26 INFORMATION_SCHEMA RESOURCE_GROUPS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-resource-groups-table.html

RESOURCE_GROUPS 表提供了关于资源组的信息。有关资源组功能的一般讨论，请参见 Section 7.1.16, “Resource Groups”。

您只能查看您拥有某些权限的列的信息。

RESOURCE_GROUPS 表具有以下列：

• RESOURCE_GROUP_NAME

  资源组的名称。

• RESOURCE_GROUP_TYPE

  资源组类型，可以是 SYSTEM 或 USER。

• RESOURCE_GROUP_ENABLED

  资源组是否启用（1）或禁用（0）；

• VCPU_IDS

  CPU 亲和性；即资源组可以使用的虚拟 CPU 集合。该值是逗号分隔的 CPU 编号或范围的列表。

• THREAD_PRIORITY

  分配给资源组的线程的优先级。优先级范围从 -20（最高优先级）到 19（最低优先级）。系统资源组的优先级范围从 -20 到 0。用户资源组的优先级范围从 0 到 19。

28.3.27 INFORMATION_SCHEMA ROLE_COLUMN_GRANTS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-role-column-grants-table.html

ROLE_COLUMN_GRANTS 表（自 MySQL 8.0.19 起可用）提供了关于当前启用角色可用或授予的列权限的信息。

ROLE_COLUMN_GRANTS 表具有以下列：

• GRANTOR

  授予角色的帐户的用户名部分。

• GRANTOR_HOST

  授予角色的帐户的主机名部分。

• GRANTEE

  授予角色的帐户的用户名部分。

• GRANTEE_HOST

  授予角色的帐户的主机名部分。

• TABLE_CATALOG

  适用于角色的目录名称。该值始终为 def。

• TABLE_SCHEMA

  适用于角色的模式（数据库）名称。

• TABLE_NAME

  适用于角色的表名。

• COLUMN_NAME

  适用于角色的列名。

• PRIVILEGE_TYPE

  授予的权限。该值可以是可以在列级别授予的任何权限；请参阅 Section 15.7.1.6, “GRANT Statement”。每行列出一个权限，因此每个受让人持有的列权限都有一行。

• IS_GRANTABLE

  YES 或 NO，取决于角色是否可授予给其他帐户。

28.3.28 INFORMATION_SCHEMA ROLE_ROUTINE_GRANTS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-role-routine-grants-table.html

ROLE_ROUTINE_GRANTS 表（自 MySQL 8.0.19 起可用）提供有关当前启用角色可用或授予的角色例程特权的信息。

ROLE_ROUTINE_GRANTS 表具有以下列：

• GRANTOR

  授予该角色的帐户的用户名部分。

• GRANTOR_HOST

  授予该角色的帐户的主机名部分。

• GRANTEE

  授予该角色的帐户的用户名部分。

• GRANTEE_HOST

  授予该角色的帐户的主机名部分。

• SPECIFIC_CATALOG

  例程所属的目录名称。该值始终为 def。

• SPECIFIC_SCHEMA

  例程所属的模式（数据库）的名称。

• SPECIFIC_NAME

  例程的名称。

• ROUTINE_CATALOG

  例程所属的目录名称。该值始终为 def。

• ROUTINE_SCHEMA

  例程所属的模式（数据库）的名称。

• ROUTINE_NAME

  例程的名称。

• PRIVILEGE_TYPE

  授予的特权。该值可以是在例程级别授予的任何特权；请参阅第 15.7.1.6 节，“GRANT 语句”。每行列出一个特权，因此每个受让人持有的列特权都有一行。

• IS_GRANTABLE

  YES 或 NO，取决于该角色是否可授予其他帐户。

28.3.29 INFORMATION_SCHEMA ROLE_TABLE_GRANTS 表

dev.mysql.com/doc/refman/8.0/en/information-schema-role-table-grants-table.html

ROLE_TABLE_GRANTS 表（自 MySQL 8.0.19 起可用）提供有关当前启用角色可用或授予的角色的表权限的信息。

ROLE_TABLE_GRANTS 表包含以下列：

• GRANTOR

  授予角色的帐户的用户名部分。

• GRANTOR_HOST

  授予角色的帐户的主机名部分。

• GRANTEE

  授予角色的帐户的用户名部分。

• GRANTEE_HOST

  授予角色的帐户的主机名部分。

• TABLE_CATALOG

  角色适用的目录名称。该值始终为def。

• TABLE_SCHEMA

  角色适用的模式（数据库）的名称。

• TABLE_NAME

  角色适用的表的名称。

• PRIVILEGE_TYPE

  授予的权限。该值可以是在表级别授予的任何权限；请参阅 Section 15.7.1.6, “GRANT Statement”。每行列出一个权限，因此每个被授予者持有的列权限都有一行。

• IS_GRANTABLE

  YES 或 NO，取决于角色是否可授予其他帐户。

28.3.30 INFORMATION_SCHEMA ROUTINES 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-routines-table.html

ROUTINES 表提供有关存储例程（存储过程和存储函数）的信息。ROUTINES 表不包括内置（本地）函数或可加载函数。

ROUTINES 表包含以下列：

• SPECIFIC_NAME

  例程的名称。

• ROUTINE_CATALOG

  例程所属的目录名称。该值始终为def。

• ROUTINE_SCHEMA

  例程所属的模式（数据库）的名称。

• ROUTINE_NAME

  例程的名称。

• ROUTINE_TYPE

  对于存储过程，PROCEDURE；对于存储函数，FUNCTION。

• DATA_TYPE

  如果例程是存储函数，则返回值数据类型。如果例程是存储过程，则该值为空。

  DATA_TYPE 值仅为类型名称，没有其他信息。DTD_IDENTIFIER 值包含类型名称和可能的其他信息，如精度或长度。

• CHARACTER_MAXIMUM_LENGTH

  对于存储函数的字符串返回值，最大长度（以字符计）。如果例程是存储过程，则该值为NULL。

• CHARACTER_OCTET_LENGTH

  对于存储函数的字符串返回值，最大长度（以字节计）。如果例程是存储过程，则该值为NULL。

• NUMERIC_PRECISION

  对于存储函数的数值返回值，数值精度。如果例程是存储过程，则该值为NULL。

• NUMERIC_SCALE

  对于存储函数的数值返回值，数值精度。如果例程是存储过程，则该值为NULL。

• DATETIME_PRECISION

  对于存储函数的时间返回值，小数秒精度。如果例程是存储过程，则该值为NULL。

• CHARACTER_SET_NAME

  对于存储函数的字符字符串返回值，字符集名称。如果例程是存储过程，则该值为NULL。

• COLLATION_NAME

  对于存储函数的字符字符串返回值，排序规则名称。如果例程是存储过程，则该值为NULL。

• DTD_IDENTIFIER

  如果例程是存储函数，则返回值数据类型。如果例程是存储过程，则该值为空。

  DATA_TYPE 值仅为类型名称，没有其他信息。DTD_IDENTIFIER 值包含类型名称和可能的其他信息，如精度或长度。

• ROUTINE_BODY

  用于例程定义的语言。该值始终为SQL。

• ROUTINE_DEFINITION

  例程执行的 SQL 语句文本。

• EXTERNAL_NAME

  该值始终为NULL。

• EXTERNAL_LANGUAGE

  存储例程的语言。该值从mysql.routines数据字典表的external_language列中读取。

• PARAMETER_STYLE

  此值始终为SQL。

• IS_DETERMINISTIC

  根据例程是否定义了DETERMINISTIC特性，为YES或NO。

• SQL_DATA_ACCESS

  例程的数据访问特性。该值为CONTAINS SQL、NO SQL、READS SQL DATA或MODIFIES SQL DATA之一。

• SQL_PATH

  此值始终为NULL。

• SECURITY_TYPE

  例程的SQL SECURITY特性。该值为DEFINER或INVOKER之一。

• CREATED

  创建例程的日期和时间。这是一个TIMESTAMP值。

• LAST_ALTERED

  上次修改例程的日期和时间。这是一个TIMESTAMP值。如果自创建以来未修改例程，则此值与CREATED值相同。

• SQL_MODE

  创建或更改例程时生效的 SQL 模式，以及例程执行时的模式。有关允许的值，请参见第 7.1.11 节，“服务器 SQL 模式”。

• ROUTINE_COMMENT

  如果例程有注释，则为注释的文本。如果没有，则此值为空。

• DEFINER

  DEFINER子句中命名的帐户（通常是创建例程的用户），格式为'*user_name*'@'*host_name*'。

• CHARACTER_SET_CLIENT

  创建例程时的character_set_client系统变量的会话值。

• COLLATION_CONNECTION

  创建例程时的collation_connection系统变量的会话值。

• DATABASE_COLLATION

  与例程关联的数据库的排序规则。

注意事项

• 要查看有关例程的信息，您必须是例程DEFINER命名的用户，具有SHOW_ROUTINE权限，在全局级别具有SELECT权限，或者在包括例程的范围内被授予CREATE ROUTINE、ALTER ROUTINE或EXECUTE权限。如果您只有CREATE ROUTINE、ALTER ROUTINE或EXECUTE权限，则ROUTINE_DEFINITION列为NULL。

• 存储函数返回值的信息也可以在PARAMETERS表中找到。存储函数的返回值行可以通过具有ORDINAL_POSITION值为 0 的行来识别。

28.3.31 The INFORMATION_SCHEMA SCHEMATA Table

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-schemata-table.html

一个模式是一个数据库，因此SCHEMATA表提供关于数据库的信息。

SCHEMATA表具有以下列：

• CATALOG_NAME

  模式所属目录的名称。此值始终为def。

• SCHEMA_NAME

  模式的名称。

• DEFAULT_CHARACTER_SET_NAME

  模式默认字符集。

• DEFAULT_COLLATION_NAME

  模式默认排序规则。

• SQL_PATH

  此值始终为NULL。

• DEFAULT_ENCRYPTION

  模式默认加密。此列在 MySQL 8.0.16 中添加。

模式名称也可以从SHOW DATABASES语句中获取。参见 Section 15.7.7.14, “SHOW DATABASES Statement”。以下语句是等效的：

SELECT SCHEMA_NAME AS `Database`
  FROM INFORMATION_SCHEMA.SCHEMATA
  [WHERE SCHEMA_NAME LIKE '*wild*']

SHOW DATABASES
  [LIKE '*wild*']

除非具有全局SHOW DATABASES权限，否则只能看到具有某种特权的数据库。

注意

因为任何静态全局特权都被视为对所有数据库的特权，任何静态全局特权都使用户能够使用SHOW DATABASES或通过检查INFORMATION_SCHEMA的SCHEMATA表来查看所有数据库名称，除了在数据库级别通过部分撤销限制的数据库。

注意

• SCHEMATA_EXTENSIONS表通过提供有关模式选项的信息来扩展SCHEMATA表。

28.3.32 INFORMATION_SCHEMA SCHEMATA_EXTENSIONS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-schemata-extensions-table.html

SCHEMATA_EXTENSIONS 表（自 MySQL 8.0.22 起可用）通过提供有关模式选项的信息来扩充 SCHEMATA 表。

SCHEMATA_EXTENSIONS 表包含以下列：

• CATALOG_NAME

  模式所属的目录名称。该值始终为def。

• SCHEMA_NAME

  模式的名称。

• OPTIONS

  模式的选项。如果模式是只读的，则值包含READ ONLY=1。如果模式不是只读的，则不会出现READ ONLY选项。

示例

mysql> ALTER SCHEMA mydb READ ONLY = 1;
mysql> SELECT * FROM INFORMATION_SCHEMA.SCHEMATA_EXTENSIONS
       WHERE SCHEMA_NAME = 'mydb';
+--------------+-------------+-------------+
| CATALOG_NAME | SCHEMA_NAME | OPTIONS     |
+--------------+-------------+-------------+
| def          | mydb        | READ ONLY=1 |
+--------------+-------------+-------------+

mysql> ALTER SCHEMA mydb READ ONLY = 0;
mysql> SELECT * FROM INFORMATION_SCHEMA.SCHEMATA_EXTENSIONS
       WHERE SCHEMA_NAME = 'mydb';
+--------------+-------------+---------+
| CATALOG_NAME | SCHEMA_NAME | OPTIONS |
+--------------+-------------+---------+
| def          | mydb        |         |
+--------------+-------------+---------+

注意事项

• SCHEMATA_EXTENSIONS 是一个非标准的INFORMATION_SCHEMA表。

28.3.33 The INFORMATION_SCHEMA SCHEMA_PRIVILEGES Table

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-schema-privileges-table.html

SCHEMA_PRIVILEGES表提供有关模式（数据库）权限的信息。它从mysql.db系统表中获取其值。

SCHEMA_PRIVILEGES表具有以下列：

• GRANTEE

  授予权限的帐户名称，格式为'*user_name*'@'*host_name*'。

• TABLE_CATALOG

  模式所属的目录名称。该值始终为def。

• TABLE_SCHEMA

  模式的名称。

• PRIVILEGE_TYPE

  授予的权限。该值可以是在模式级别授予的任何权限；请参阅第 15.7.1.6 节，“GRANT 语句”。每行列出一个权限，因此每个受让人持有的模式权限都有一行。

• IS_GRANTABLE

  如果用户拥有GRANT OPTION权限，则为YES，否则为NO。输出不会将GRANT OPTION列为PRIVILEGE_TYPE='GRANT OPTION'的单独行。

注意

• SCHEMA_PRIVILEGES是一个非标准的INFORMATION_SCHEMA表。

以下语句不等价：

SELECT ... FROM INFORMATION_SCHEMA.SCHEMA_PRIVILEGES

SHOW GRANTS ...

28.3.34 The INFORMATION_SCHEMA STATISTICS Table

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-statistics-table.html

STATISTICS表提供有关表索引的信息。

STATISTICS中表示表统计信息的列保存了缓存值。information_schema_stats_expiry系统变量定义了缓存表统计信息过期之前的时间段。默认值为 86400 秒（24 小时）。如果没有缓存的统计信息或统计信息已过期，则在查询表统计信息列时从存储引擎中检索统计信息。要随时更新给定表的缓存值，请使用ANALYZE TABLE。要始终直接从存储引擎中检索最新的统计信息，请设置information_schema_stats_expiry=0。有关更多信息，请参见 Section 10.2.3，“优化 INFORMATION_SCHEMA 查询”。

注意

如果启用了innodb_read_only系统变量，则可能因为无法更新使用InnoDB的数据字典中的统计信息表而导致ANALYZE TABLE失败。即使操作更新了表本身（例如，如果是MyISAM表），对更新键分布的ANALYZE TABLE操作也可能导致失败。要获取更新后的分布统计信息，请设置information_schema_stats_expiry=0。

STATISTICS表具有以下列：

• TABLE_CATALOG

  包含索引的表所属的目录的名称。此值始终为def。

• TABLE_SCHEMA

  包含索引的表所属的模式（数据库）的名称。

• TABLE_NAME

  包含索引的表的名称。

• NON_UNIQUE

  如果索引不能包含重复项，则为 0，如果可以则为 1。

• INDEX_SCHEMA

  索引所属的模式（数据库）的名称。

• INDEX_NAME

  索引的名称。如果索引是主键，则名称始终为PRIMARY。

• SEQ_IN_INDEX

  索引中的列序号，从 1 开始。

• COLUMN_NAME

  列名。另请参阅EXPRESSION列的描述。

• COLLATION

  列在索引中的排序方式。这可以是A（升序），D（降序）或NULL（未排序）。

• CARDINALITY

  索引中唯一值的估计数量。要更新此数字，请运行ANALYZE TABLE或（对于MyISAM表）myisamchk -a。

  CARDINALITY是基于存储为整数的统计数据计算的，因此即使对于小表，该值也不一定是精确的。基数越高，MySQL 在执行连接时使用索引的可能性就越大。

• SUB_PART

  索引前缀。也就是，如果列仅部分索引，则索引字符数，如果整个列被索引，则为NULL。

  注意

  前缀限制以字节为单位。但是，在CREATE TABLE，ALTER TABLE和CREATE INDEX语句中的索引规范中，对于非二进制字符串类型（CHAR，VARCHAR，TEXT），前缀长度被解释为多字节字符集的字符数，对于二进制字符串类型（BINARY，VARBINARY，BLOB），前缀长度以字节为单位。在为使用多字节字符集的非二进制字符串列指定前缀长度时，请考虑这一点。

  有关索引前缀的其他信息，请参见第 10.3.5 节，“列索引”和第 15.1.15 节，“CREATE INDEX Statement”。

• PACKED

  指示键如何打包。如果不是，则为NULL。

• NULLABLE

  包含YES，如果列可能包含NULL值，''如果不包含。

• INDEX_TYPE

  使用的索引方法（BTREE，FULLTEXT，HASH，RTREE）。

• COMMENT

  关于索引的信息，未在其自己的列中描述，例如如果索引已禁用，则为disabled。

• INDEX_COMMENT

  创建索引时使用COMMENT属性提供的索引的任何注释。

• IS_VISIBLE

  索引是否对优化器可见。请参见第 10.3.12 节，“不可见索引”。

• EXPRESSION

  MySQL 8.0.13 及更高版本支持功能键部分（参见功能键部分），这影响COLUMN_NAME和EXPRESSION列：

  • 对于非功能键部分，COLUMN_NAME指示由键部分索引的列，EXPRESSION为NULL。

  • 对于功能键部分，COLUMN_NAME列为NULL，而EXPRESSION表示键部分的表达式。

注意

• 没有用于索引的标准INFORMATION_SCHEMA表。MySQL 列列表类似于 SQL Server 2000 返回的sp_statistics，只是QUALIFIER和OWNER分别替换为CATALOG和SCHEMA。

表索引的信息也可以从SHOW INDEX语句中获取。请参见第 15.7.7.22 节，“SHOW INDEX Statement”。以下语句是等效的：

SELECT * FROM INFORMATION_SCHEMA.STATISTICS
  WHERE table_name = '*tbl_name*'
  AND table_schema = '*db_name*'

SHOW INDEX
  FROM *tbl_name*
  FROM *db_name*

在 MySQL 8.0.30 及更高版本中，默认情况下，此表中显示有关生成的不可见主键列的信息。您可以通过设置show_gipk_in_create_table_and_information_schema = OFF来隐藏此类信息。有关更多信息，请参见第 15.1.20.11 节，“生成的不可见主键”。

28.3.35 INFORMATION_SCHEMA ST_GEOMETRY_COLUMNS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-st-geometry-columns-table.html

ST_GEOMETRY_COLUMNS 表提供关于存储空间数据的表列的信息。此表基于 SQL/MM（ISO/IEC 13249-3）标准，并带有如下扩展。MySQL 将ST_GEOMETRY_COLUMNS 实现为INFORMATION_SCHEMA COLUMNS 表上的视图。

ST_GEOMETRY_COLUMNS 表包含以下列：

• TABLE_CATALOG

  包含列的表所属的目录的名称。此值始终为def。

• TABLE_SCHEMA

  包含列的表所属的模式（数据库）的名称。

• TABLE_NAME

  包含列的表的名称。

• COLUMN_NAME

  列的名称。

• SRS_NAME

  空间参考系统（SRS）名称。

• SRS_ID

  空间参考系统 ID（SRID）。

• GEOMETRY_TYPE_NAME

  列数据类型。允许的值为：geometry、point、linestring、polygon、multipoint、multilinestring、multipolygon、geometrycollection。此列是 MySQL 对标准的扩展。

28.3.36 INFORMATION_SCHEMA ST_SPATIAL_REFERENCE_SYSTEMS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-st-spatial-reference-systems-table.html

ST_SPATIAL_REFERENCE_SYSTEMS 表提供有关可用空间数据的空间参考系统（SRS）的信息。此表基于 SQL/MM（ISO/IEC 13249-3）标准。

ST_SPATIAL_REFERENCE_SYSTEMS 表中的条目基于 European Petroleum Survey Group（EPSG）数据集，除了对应于 MySQL 中使用的特殊 SRS 的 SRID 0，该 SRS 表示一个无限的平坦笛卡尔平面，其轴没有分配单位。有关 SRS 的其他信息，请参见 Section 13.4.5, “Spatial Reference System Support”。

ST_SPATIAL_REFERENCE_SYSTEMS 表具有以下列：

• SRS_NAME

  空间参考系统名称。此值是唯一的。

• SRS_ID

  空间参考系统数值 ID。此值是唯一的。

  SRS_ID 值代表与几何值的 SRID 相同类型的值，或作为空间函数的 SRID 参数传递。SRID 0（无单位的笛卡尔平面）是特殊的。它始终是合法的空间参考系统 ID，并可用于依赖于 SRID 值的空间数据的任何计算中。

• ORGANIZATION

  定义了空间参考系统基础坐标系的组织名称。

• ORGANIZATION_COORDSYS_ID

  组织定义的空间参考系统的数值 ID。

• DEFINITION

  空间参考系统定义。DEFINITION 值是 WKT 值，表示如 Open Geospatial Consortium 文档 OGC 12-063r5 中指定的。

  当 GIS 函数需要定义时，会按需解析 SRS 定义。解析的定义存储在数据字典缓存中，以便重用并避免为每个需要 SRS 信息的语句产生解析开销。

• DESCRIPTION

  空间参考系统描述。

注意

• SRS_NAME、ORGANIZATION、ORGANIZATION_COORDSYS_ID 和 DESCRIPTION 列包含可能对用户感兴趣的信息，但它们不被 MySQL 使用。

示例

mysql> SELECT * FROM ST_SPATIAL_REFERENCE_SYSTEMS
       WHERE SRS_ID = 4326\G
*************************** 1\. row ***************************
                SRS_NAME: WGS 84
                  SRS_ID: 4326
            ORGANIZATION: EPSG
ORGANIZATION_COORDSYS_ID: 4326
              DEFINITION: GEOGCS["WGS 84",DATUM["World Geodetic System 1984",
                          SPHEROID["WGS 84",6378137,298.257223563,
                          AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],
                          PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],
                          UNIT["degree",0.017453292519943278,
                          AUTHORITY["EPSG","9122"]],
                          AXIS["Lat",NORTH],AXIS["Long",EAST],
                          AUTHORITY["EPSG","4326"]]
             DESCRIPTION:

本条目描述了用于 GPS 系统的 SRS。它具有名称（SRS_NAME）为 WGS 84 和 ID（SRS_ID）为 4326，这是欧洲石油调查组（EPSG）使用的 ID。

投影和地理 SRS 的DEFINITION值分别以PROJCS和GEOGCS开头。SRID 0 的定义是特殊的，并且具有空的DEFINITION值。以下查询根据DEFINITION值确定ST_SPATIAL_REFERENCE_SYSTEMS表中有多少条目对应于投影、地理和其他 SRS：

mysql> SELECT
         COUNT(*),
         CASE LEFT(DEFINITION, 6)
           WHEN 'PROJCS' THEN 'Projected'
           WHEN 'GEOGCS' THEN 'Geographic'
           ELSE 'Other'
         END AS SRS_TYPE
       FROM INFORMATION_SCHEMA.ST_SPATIAL_REFERENCE_SYSTEMS
       GROUP BY SRS_TYPE;
+----------+------------+
| COUNT(*) | SRS_TYPE   |
+----------+------------+
|        1 | Other      |
|     4668 | Projected  |
|      483 | Geographic |
+----------+------------+

为了使存储在数据字典中的 SRS 条目可以进行操作，MySQL 提供了以下 SQL 语句：

• 创建空间参考系统：参见第 15.1.19 节，“创建空间参考系统语句”。该语句的描述包括有关 SRS 组件的附加信息。

• 删除空间参考系统：参见第 15.1.31 节，“删除空间参考系统语句”。

28.3.37 信息模式 ST_UNITS_OF_MEASURE 表

dev.mysql.com/doc/refman/8.0/en/information-schema-st-units-of-measure-table.html

ST_UNITS_OF_MEASURE 表（自 MySQL 8.0.14 起可用）提供了关于 ST_Distance() 函数可接受单位的信息。

ST_UNITS_OF_MEASURE 表包含以下列：

• UNIT_NAME

  单位的名称。

• UNIT_TYPE

  单位类型（例如，线性）。

• CONVERSION_FACTOR

  用于内部计算的转换因子。

• DESCRIPTION

  单位的描述。

28.3.38 The INFORMATION_SCHEMA TABLES Table

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-tables-table.html

TABLES表提供有关��据库中表的信息。

TABLES中表示表统计信息的列保存了缓存值。information_schema_stats_expiry系统变量定义了缓存表统计信息过期之前的时间段。默认值为 86400 秒（24 小时）。如果没有缓存统计信息或统计信息已过期，在查询表统计信息列时，将从存储引擎中检索统计信息。要随时更新给定表的缓存值，请使用ANALYZE TABLE语句。要始终直接从存储引擎中检索最新统计信息，请将information_schema_stats_expiry设置为0。更多信息，请参见Section 10.2.3, “Optimizing INFORMATION_SCHEMA Queries”。

注意

如果启用了innodb_read_only系统变量，则ANALYZE TABLE可能会失败，因为它无法更新使用InnoDB的数据字典中的统计表。对于更新键分布的ANALYZE TABLE操作，即使操作更新了表本身（例如，如果它是MyISAM表），也可能会发生失败。要获取更新后的分布统计信息，请将information_schema_stats_expiry=0。

TABLES表具有以下列：

• TABLE_CATALOG

  表所属的目录名称。该值始终为def。

• TABLE_SCHEMA

  表所属的模式（数据库）的名称。

• TABLE_NAME

  表的名称。

• TABLE_TYPE

  表的BASE TABLE，视图的VIEW，或INFORMATION_SCHEMA表的SYSTEM VIEW。

  TABLES表不列出TEMPORARY表。

• ENGINE

  表的存储引擎。请参阅Chapter 17, The InnoDB Storage Engine，以及Chapter 18, Alternative Storage Engines。

  对于分区表，ENGINE显示所有分区使用的存储引擎的名称。

• VERSION

  此列未使用。随着 MySQL 8.0 中.frm文件的移除，此列现在报告一个硬编码值10，这是 MySQL 5.7 中使用的最后一个.frm文件版本。

• ROW_FORMAT

  行存储格式（Fixed，Dynamic，Compressed，Redundant，Compact）。对于MyISAM表，Dynamic对应于myisamchk -dvv报告的Packed。

• TABLE_ROWS

  行数。一些存储引擎，如MyISAM，存储确切的计数。对于其他存储引擎，如InnoDB，这个值是一个近似值，可能与实际值相差 40%至 50%。在这种情况下，使用SELECT COUNT(*)来获得准确的计数。

  对于INFORMATION_SCHEMA表，TABLE_ROWS为NULL。

  对于InnoDB表，行计数仅是 SQL 优化中使用的粗略估计。（如果InnoDB表被分区，这也是正确的。）

• AVG_ROW_LENGTH

  平均行长度。

• DATA_LENGTH

  对于MyISAM，DATA_LENGTH是数据文件的长度，以字节为单位。

  对于InnoDB，DATA_LENGTH是近似为聚簇索引分配的空间量，以字节为单位。具体来说，它是聚簇索引大小（以页为单位）乘以InnoDB页大小。

  有关其他存储引擎的信息，请参考本节末尾的注释。

• MAX_DATA_LENGTH

  对于MyISAM，MAX_DATA_LENGTH是数据文件的最大长度。这是可以存储在表中的数据字节数总数，考虑到使用的数据指针大小。

  对于InnoDB未使用。

  有关其他存储引擎的信息，请参考本节末尾的注释。

• INDEX_LENGTH

  对于MyISAM，INDEX_LENGTH是索引文件的长度，以字节为单位。

  对于InnoDB，INDEX_LENGTH是非聚簇索引分配的空间量的近似值，以字节为单位。具体来说，它是非聚簇索引大小（以页为单位）的总和，乘以InnoDB页大小。

  有关其他存储引擎的信息，请参考本节末尾的注释。

• DATA_FREE

  已分配但未使用字节的数量。

  InnoDB表报告表所属表空间的空闲空间。对于位于共享表空间中的表，这是共享表空间的空闲空间。如果您使用多个表空间并且表有自己的表空间，则空闲空间仅适用于该表。空闲空间表示完全空闲范围中的字节数减去安全边界。即使空闲空间显示为 0，也可能可以插入行，只要不需要分配新的范围。

  对于 NDB Cluster，DATA_FREE显示在磁盘上为磁盘数据表或片段分配但未使用的空间。（内存数据资源使用由DATA_LENGTH列报告。）

  对于分区表，此值仅为估计值，可能不完全正确。在这种情况下，获取此信息的更准确方法是查询INFORMATION_SCHEMA PARTITIONS表，如下例所示：

  SELECT SUM(DATA_FREE)
      FROM  INFORMATION_SCHEMA.PARTITIONS
      WHERE TABLE_SCHEMA = 'mydb'
      AND   TABLE_NAME   = 'mytable';
  

  更多信息，请参见 Section 28.3.21, “The INFORMATION_SCHEMA PARTITIONS Table”。

• AUTO_INCREMENT

  下一个AUTO_INCREMENT值。

• CREATE_TIME

  表创建的时间。

• UPDATE_TIME

  表上次更新的时间。对于某些存储引擎，此值为NULL。即使使用每个InnoDB表在单独的.ibd文件中的 file-per-table 模式，change buffering 也可能延迟对数据文件的写入，因此文件修改时间与最后插入、更新或删除的时间不同。对于MyISAM，使用数据文件时间戳；但在 Windows 上，时间戳不会被更新，因此值不准确。

  UPDATE_TIME显示了对未分区的InnoDB表执行的最后一次UPDATE、INSERT或DELETE的时间戳值。对于 MVCC，时间戳值反映了COMMIT时间，被视为最后更新时间。当服务器重新启动或表从InnoDB数据字典缓存中删除时，时间戳不会被持久化。

• CHECK_TIME

  上次检查表的时间。并非所有存储引擎都会更新此时间，如果不更新，则值始终为NULL。

  对于分区的InnoDB表，CHECK_TIME始终为NULL。

• TABLE_COLLATION

  表的默认排序规则。输出中没有明确列出表的默认字符集，但排序规则名称以字符集名称开头。

• CHECKSUM

  活动校验和值（如果有）。

• CREATE_OPTIONS

  与CREATE TABLE一起使用的额外选项。

  CREATE_OPTIONS显示为分区表。

  在 MySQL 8.0.16 之前，CREATE_OPTIONS 显示了为在每个文件表空间中创建的表指定的 ENCRYPTION 子句。从 MySQL 8.0.16 开始，如果表已加密或指定的加密与模式加密不同，则显示每个文件表空间的加密子句。对于在一般表空间中创建的表，不显示加密子句。要识别加密的每个文件表空间和一般表空间，请查询 INNODB_TABLESPACES 的 ENCRYPTION 列。

  在创建表时禁用 严格模式，如果指定的行格式不受支持，则使用存储引擎的默认行格式。表的实际行格式在 ROW_FORMAT 列中报告。CREATE_OPTIONS 显示在 CREATE TABLE 语句中指定的行格式。

  当更改表的存储引擎时，不适用于新存储引擎的表选项保留在表定义中，以便在必要时将具有先前定义选项的表还原为原始存储引擎。CREATE_OPTIONS 列可能显示保留的选项。

• TABLE_COMMENT

  创建表时使用的注释（或者为什么 MySQL 无法访问表信息的信息）。

注意

• 对于 NDB 表，此语句的输出显示 AVG_ROW_LENGTH 和 DATA_LENGTH 列的适当值，但不考虑 BLOB 列。

• 对于 NDB 表，DATA_LENGTH 仅包括存储在主内存中的数据；MAX_DATA_LENGTH 和 DATA_FREE 列适用于磁盘数据。

• 对于 NDB 集群磁盘数据表，MAX_DATA_LENGTH 显示为磁盘数据表或片段的磁盘部分分配的空间。（内存数据资源使用由 DATA_LENGTH 列报告。）

• 对于 MEMORY 表，DATA_LENGTH、MAX_DATA_LENGTH 和 INDEX_LENGTH 的值近似于实际分配的内存量。分配算法会大量保留内存以减少分配操作的数量。

• 对于视图，大多数 TABLES 列为 0 或 NULL，除了 TABLE_NAME 指示视图名称，CREATE_TIME 指示创建时间，TABLE_COMMENT 显示 VIEW。

表信息也可以通过SHOW TABLE STATUS和SHOW TABLES语句获取。请参阅 Section 15.7.7.38, “SHOW TABLE STATUS Statement”和 Section 15.7.7.39, “SHOW TABLES Statement”。以下语句是等效的：

SELECT
    TABLE_NAME, ENGINE, VERSION, ROW_FORMAT, TABLE_ROWS, AVG_ROW_LENGTH,
    DATA_LENGTH, MAX_DATA_LENGTH, INDEX_LENGTH, DATA_FREE, AUTO_INCREMENT,
    CREATE_TIME, UPDATE_TIME, CHECK_TIME, TABLE_COLLATION, CHECKSUM,
    CREATE_OPTIONS, TABLE_COMMENT
  FROM INFORMATION_SCHEMA.TABLES
  WHERE table_schema = '*db_name*'
  [AND table_name LIKE '*wild*']

SHOW TABLE STATUS
  FROM *db_name*
  [LIKE '*wild*']

以下语句是等效的：

SELECT
  TABLE_NAME, TABLE_TYPE
  FROM INFORMATION_SCHEMA.TABLES
  WHERE table_schema = '*db_name*'
  [AND table_name LIKE '*wild*']

SHOW FULL TABLES
  FROM *db_name*
  [LIKE '*wild*']

28.3.39 INFORMATION_SCHEMA TABLES_EXTENSIONS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-tables-extensions-table.html

TABLES_EXTENSIONS 表（自 MySQL 8.0.21 起可用）提供有关为主要和次要存储引擎定义的表属性的信息。

注意

TABLES_EXTENSIONS 表保留供将来使用。

TABLES_EXTENSIONS 表具有以下列：

• TABLE_CATALOG

  表所属目录的名称。此值始终为def。

• TABLE_SCHEMA

  表所属模式（数据库）的名称。

• TABLE_NAME

  表的名称。

• ENGINE_ATTRIBUTE

  为主要存储引擎定义的表属性。保留供将来使用。

• SECONDARY_ENGINE_ATTRIBUTE

  为次要存储引擎定义的表属性。保留供将来使用。

28.3.40 INFORMATION_SCHEMA TABLESPACES表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-tablespaces-table.html

此表未被使用。它已被弃用；预计在未来的 MySQL 版本中将被移除。其他INFORMATION_SCHEMA表可能提供相关信息：

• 对于NDB，INFORMATION_SCHEMA中的FILES表提供与表空间相关的信息。

• 对于InnoDB，INFORMATION_SCHEMA中的INNODB_TABLESPACES和INNODB_DATAFILES表提供表空间元数据。

28.3.41 The INFORMATION_SCHEMA TABLESPACES_EXTENSIONS Table

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-tablespaces-extensions-table.html

TABLESPACES_EXTENSIONS 表（自 MySQL 8.0.21 起可用）提供了关于为主要存储引擎定义的表空间属性的信息。

注意

TABLESPACES_EXTENSIONS 表保留供将来使用。

TABLESPACES_EXTENSIONS 表具有以下列：

• TABLESPACE_NAME

  表空间的名称。

• ENGINE_ATTRIBUTE

  为主要存储引擎定义的表空间属性。保留供将来使用。

28.3.42 信息模式表约束表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-table-constraints-table.html

TABLE_CONSTRAINTS表描述了哪些表具有约束。

TABLE_CONSTRAINTS表具有以下列：

• CONSTRAINT_CATALOG

  约束所属的目录的名称。此值始终为def。

• CONSTRAINT_SCHEMA

  约束所属的模式（数据库）的名称。

• CONSTRAINT_NAME

  约束的名称。

• TABLE_SCHEMA

  表所属的模式（数据库）的名称。

• TABLE_NAME

  表的名称。

• CONSTRAINT_TYPE

  约束的类型。该值可以是UNIQUE、PRIMARY KEY、FOREIGN KEY，或者（从 MySQL 8.0.16 开始）CHECK。这是一个CHAR（而不是ENUM输出的Key_name列中获得的信息大致相同，当Non_unique列为0时。

• ENFORCED

  对于CHECK约束，该值为YES或NO，表示约束是否被强制执行。对于其他约束，该值始终为YES。

  此列在 MySQL 8.0.16 中添加。

28.3.43 INFORMATION_SCHEMA TABLE_CONSTRAINTS_EXTENSIONS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-table-constraints-extensions-table.html

TABLE_CONSTRAINTS_EXTENSIONS 表（自 MySQL 8.0.21 起可用）提供有关为主要和辅助存储引擎定义的表约束属性的信息。

注意

TABLE_CONSTRAINTS_EXTENSIONS 表保留供将来使用。

TABLE_CONSTRAINTS_EXTENSIONS 表包含以下列：

• CONSTRAINT_CATALOG

  表所属目录的名称。

• CONSTRAINT_SCHEMA

  表所属模式（数据库）的名称。

• CONSTRAINT_NAME

  约束的名称。

• TABLE_NAME

  表的名称。

• ENGINE_ATTRIBUTE

  为主要存储引擎定义的约束属性。保留供将来使用。

• SECONDARY_ENGINE_ATTRIBUTE

  为辅助存储引擎定义的约束属性。保留供将来使用。

28.3.44 The INFORMATION_SCHEMA TABLE_PRIVILEGES Table

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-table-privileges-table.html

TABLE_PRIVILEGES表提供有关表特权的信息。它从mysql.tables_priv系统表中获取其值。

TABLE_PRIVILEGES表具有以下列：

• GRANTEE

  授予特权的帐户名称，格式为'*user_name*'@'*host_name*'。

• TABLE_CATALOG

  表所属目录的名称。该值始终为def。

• TABLE_SCHEMA

  表所属模式（数据库）的名称。

• TABLE_NAME

  表的名称。

• PRIVILEGE_TYPE

  授予的特权。该值可以是可以在表级别授予的任何特权；参见第 15.7.1.6 节，“GRANT 语句”。每行列出一个特权，因此每个受让人持有的表特权都有一行。

• IS_GRANTABLE

  如果用户具有GRANT OPTION特权，则为YES，否则为NO。输出不会将GRANT OPTION列为具有PRIVILEGE_TYPE='GRANT OPTION'的单独行。

注意事项

• TABLE_PRIVILEGES是一个非标准的INFORMATION_SCHEMA表。

以下语句不等价：

SELECT ... FROM INFORMATION_SCHEMA.TABLE_PRIVILEGES

SHOW GRANTS ...

28.3.45 信息模式 TRIGGERS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-triggers-table.html

TRIGGERS表提供有关触发器的信息。要查看有关表格触发器的信息，您必须对表格具有TRIGGER权限。

TRIGGERS表具有以下列：

• TRIGGER_CATALOG

  触发器所属的目录名称。此值始终为def。

• TRIGGER_SCHEMA

  触发器所属的模式（数据库）的名称。

• TRIGGER_NAME

  触发器的名称。

• EVENT_MANIPULATION

  触发器事件。这是触发器激活的相关表格上的操作类型。值为INSERT（插入了一行），DELETE（删除了一行）或UPDATE（修改了一行）。

• EVENT_OBJECT_CATALOG，EVENT_OBJECT_SCHEMA和EVENT_OBJECT_TABLE

  如第 27.3 节，“使用触发器”中所述，每个触发器都与一个表格关联。这些列指示此表格所在的目录和模式（数据库），以及表格名称。EVENT_OBJECT_CATALOG值始终为def。

• ACTION_ORDER

  触发器动作在相同表格上具有相同EVENT_MANIPULATION和ACTION_TIMING值的触发器列表中的序数位置。

• ACTION_CONDITION

  此值始终为NULL。

• ACTION_STATEMENT

  触发器主体；即触发器激活时执行的语句。此文本使用 UTF-8 编码。

• ACTION_ORIENTATION

  此值始终为ROW。

• ACTION_TIMING

  触发器在触发事件之前或之后激活。值为BEFORE或AFTER。

• ACTION_REFERENCE_OLD_TABLE

  此值始终为NULL。

• ACTION_REFERENCE_NEW_TABLE

  此值始终为NULL。

• ACTION_REFERENCE_OLD_ROW和ACTION_REFERENCE_NEW_ROW

  旧列标识符和新列标识符。ACTION_REFERENCE_OLD_ROW值始终为OLD，ACTION_REFERENCE_NEW_ROW值始终为NEW。

• CREATED

  触发器创建时的日期和时间。这是一个TIMESTAMP(2)值（带有百分之一秒的小数部分）。

• SQL_MODE

  触发器创建时生效的 SQL 模式，以及触发器执行的模式。有关允许的值，请参见第 7.1.11 节，“服务器 SQL 模式”。

• DEFINER

  DEFINER子句中命名的帐户（通常是创建触发器的用户），格式为'*user_name*'@'*host_name*'。

• CHARACTER_SET_CLIENT

  触发器创建时的character_set_client系统变量的会话值。

• COLLATION_CONNECTION

  触发器创建时collation_connection系统变量的会话值。

• DATABASE_COLLATION

  触发器关联的数据库的排序规则。

示例

以下示例使用了 Section 27.3, “Using Triggers”中定义的ins_sum触发器：

mysql> SELECT * FROM INFORMATION_SCHEMA.TRIGGERS
       WHERE TRIGGER_SCHEMA='test' AND TRIGGER_NAME='ins_sum'\G
*************************** 1\. row ***************************
           TRIGGER_CATALOG: def
            TRIGGER_SCHEMA: test
              TRIGGER_NAME: ins_sum
        EVENT_MANIPULATION: INSERT
      EVENT_OBJECT_CATALOG: def
       EVENT_OBJECT_SCHEMA: test
        EVENT_OBJECT_TABLE: account
              ACTION_ORDER: 1
          ACTION_CONDITION: NULL
          ACTION_STATEMENT: SET @sum = @sum + NEW.amount
        ACTION_ORIENTATION: ROW
             ACTION_TIMING: BEFORE
ACTION_REFERENCE_OLD_TABLE: NULL
ACTION_REFERENCE_NEW_TABLE: NULL
  ACTION_REFERENCE_OLD_ROW: OLD
  ACTION_REFERENCE_NEW_ROW: NEW
                   CREATED: 2018-08-08 10:10:12.61
                  SQL_MODE: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,
                            NO_ZERO_IN_DATE,NO_ZERO_DATE,
                            ERROR_FOR_DIVISION_BY_ZERO,
                            NO_ENGINE_SUBSTITUTION
                   DEFINER: me@localhost
      CHARACTER_SET_CLIENT: utf8mb4
      COLLATION_CONNECTION: utf8mb4_0900_ai_ci
        DATABASE_COLLATION: utf8mb4_0900_ai_ci

触发器信息也可以通过SHOW TRIGGERS语句获取。请参阅 Section 15.7.7.40, “SHOW TRIGGERS Statement”。

28.3.46 INFORMATION_SCHEMA USER_ATTRIBUTES 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-user-attributes-table.html

USER_ATTRIBUTES表（自 MySQL 8.0.21 起可用）提供有关用户评论和用户属性的信息。它从mysql.user系统表中获取其值。

USER_ATTRIBUTES表具有以下列：

• USER

  适用于ATTRIBUTE列值的帐户的用户名部分。

• HOST

  适用于ATTRIBUTE列值的帐户的主机名部分。

• ATTRIBUTE

  属于由USER和HOST列指定的帐户的用户评论、用户属性或两者。该值以 JSON 对象表示。属性的显示方式与使用带有ATTRIBUTE或COMMENT选项的CREATE USER和ALTER USER语句设置的方式完全相同。评论显示为具有comment作为键的键值对。有关更多信息和示例，请参阅CREATE USER Comment and Attribute Options。

注意

• USER_ATTRIBUTES 是一个非标准的INFORMATION_SCHEMA表。

• 要仅获取给定用户的用户评论作为未引用字符串，您可以使用以下查询：

  mysql> SELECT ATTRIBUTE->>"$.comment" AS Comment
   ->     FROM INFORMATION_SCHEMA.USER_ATTRIBUTES
   ->     WHERE USER='bill' AND HOST='localhost';
  +-----------+
  | Comment   |
  +-----------+
  | A comment |
  +-----------+
  

  同样，您可以使用其键获取给定用户属性的未引用值。

• 在 MySQL 8.0.22 之前，任何人都可以访问USER_ATTRIBUTES的内容。从 MySQL 8.0.22 开始，可以按以下方式访问USER_ATTRIBUTES的内容：

  • 如果：

    • 当前线程是一个复制线程。

    • 访问控制系统尚未初始化（例如，服务器是使用--skip-grant-tables选项启动的）。

    • 当前经过身份验证的帐户具有对mysql.user系统表的UPDATE或SELECT权限。

    • 当前经过身份验证的帐户具有CREATE USER和SYSTEM_USER权限。

  • 否则，当前经过身份验证的账户可以看到该账户的行。此外，如果该账户具有CREATE USER权限但没有SYSTEM_USER权限，它可以看到所有其他没有SYSTEM_USER权限的账户的行。

有关指定账户注释和属性的更多信息，请参阅第 15.7.1.3 节，“CREATE USER Statement”。

28.3.47 INFORMATION_SCHEMA USER_PRIVILEGES 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-user-privileges-table.html

USER_PRIVILEGES 表提供有关全局权限的信息。它的值来自于 mysql.user 系统表。

USER_PRIVILEGES 表包含以下列：

• GRANTEE

  被授予权限的帐户名称，格式为 '*user_name*'@'*host_name*'。

• TABLE_CATALOG

  目录的名称。该值始终为 def。

• PRIVILEGE_TYPE

  授予的权限。该值可以是在全局级别授予的任何权限；请参阅 Section 15.7.1.6, “GRANT Statement”。每行列出一个权限，因此每个被授予权限的受让人都有一行。

• IS_GRANTABLE

  如果用户具有 GRANT OPTION 权限，则为 YES，否则为 NO。输出不会将 GRANT OPTION 列为具有 PRIVILEGE_TYPE='GRANT OPTION' 的单独行。

注意

• USER_PRIVILEGES 是一个非标准的 INFORMATION_SCHEMA 表。

以下语句不等价：

SELECT ... FROM INFORMATION_SCHEMA.USER_PRIVILEGES

SHOW GRANTS ...

28.3.48 The INFORMATION_SCHEMA VIEWS Table

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-views-table.html

VIEWS 表提供有关数据库中视图的信息。您必须具有 SHOW VIEW 权限才能访问此表。

VIEWS 表包含以下列：

• TABLE_CATALOG

  视图所属目录的名称。该值始终为 def。

• TABLE_SCHEMA

  视图所属模式（数据库）的名称。

• TABLE_NAME

  视图的名称。

• VIEW_DEFINITION

  提供视图定义的 SELECT 语句。该列包含 SHOW CREATE VIEW 生成的 Create Table 列中的大部分内容。跳过 SELECT 前的单词和跳过 WITH CHECK OPTION 前的单词。假设原始语句为：

  CREATE VIEW v AS
    SELECT s2,s1 FROM t
    WHERE s1 > 5
    ORDER BY s1
    WITH CHECK OPTION;
  

  然后视图定义如下：

  SELECT s2,s1 FROM t WHERE s1 > 5 ORDER BY s1
  

• CHECK_OPTION

  CHECK_OPTION 属性的值。该值为 NONE、CASCADE 或 LOCAL 中的一个。

• IS_UPDATABLE

  MySQL 在 CREATE VIEW 时设置一个标志，称为视图可更新性标志。如果视图可以进行 UPDATE 和 DELETE（以及类似操作），则该标志设置为 YES（true）。否则，该标志设置为 NO（false）。VIEWS 表中的 IS_UPDATABLE 列显示了该标志的状态。这意味着服务器始终知道视图是否可更新。

  如果视图不可更新，则诸如 UPDATE、DELETE 和 INSERT 等语句是非法的并将被拒绝。（即使视图是可更新的，也可能无法向其插入数据；有关详细信息，请参阅 Section 27.5.3, “Updatable and Insertable Views”。）

• DEFINER

  创建视图的用户帐户，格式为 '*user_name*'@'*host_name*'。

• SECURITY_TYPE

  视图的 SQL SECURITY 特性。该值为 DEFINER 或 INVOKER 中的一个。

• CHARACTER_SET_CLIENT

  视图创建时 character_set_client 系统变量的会话值。

• COLLATION_CONNECTION

  视图创建时 collation_connection 系统变量的会话值。

注意事项

MySQL 允许不同的sql_mode设置告诉服务器支持的 SQL 语法类型。例如，您可以使用ANSI SQL 模式来确保 MySQL 正确解释标准 SQL 连接运算符，双竖线(||)，在您的查询中。如果您创建一个连接项目的视图，您可能担心将sql_mode设置更改为与ANSI不同的值会导致视图无效。但事实并非如此。无论您如何编写视图定义，MySQL 始终以相同的方式存储它，即规范形式。以下是一个示例，显示服务器如何将双竖线连接运算符更改为CONCAT()函数：

mysql> SET sql_mode = 'ANSI';
Query OK, 0 rows affected (0.00 sec)

mysql> CREATE VIEW test.v AS SELECT 'a' || 'b' as col1;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT VIEW_DEFINITION FROM INFORMATION_SCHEMA.VIEWS
       WHERE TABLE_SCHEMA = 'test' AND TABLE_NAME = 'v';
+----------------------------------+
| VIEW_DEFINITION                  |
+----------------------------------+
| select concat('a','b') AS `col1` |
+----------------------------------+
1 row in set (0.00 sec)

将视图定义存储为规范形式的优势在于，稍后对sql_mode值的更改不会影响视图的结果。然而，另一个结果是，服务器会剥离SELECT之前的注释。

28.3.49 The INFORMATION_SCHEMA VIEW_ROUTINE_USAGE Table

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-view-routine-usage-table.html

VIEW_ROUTINE_USAGE 表（自 MySQL 8.0.13 起可用）提供有关视图定义中使用的存储函数的信息。该表不列出有关内置（本机）函数或在定义中使用的可加载函数的信息。

您只能查看您拥有某些权限的视图信息，以及您拥有某些权限的函数信息。

VIEW_ROUTINE_USAGE 表具有以下列：

• TABLE_CATALOG

  视图所属的目录的名称。此值始终为def。

• TABLE_SCHEMA

  视图所属的模式（数据库）的名称。

• TABLE_NAME

  视图的名称。

• SPECIFIC_CATALOG

  视图定义中使用的函数所属的目录名称。此值始终为def。

• SPECIFIC_SCHEMA

  视图定义中使用的函数所属的模式（数据库）的名称。

• SPECIFIC_NAME

  视图定义中使用的函数的名称。

28.3.50 信息模式 VIEW_TABLE_USAGE 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-view-table-usage-table.html

VIEW_TABLE_USAGE 表（自 MySQL 8.0.13 起可用）提供了关于视图定义中使用的表和视图的信息。

您只能查看您拥有某些权限的视图信息，以及您拥有某些权限的表信息。

VIEW_TABLE_USAGE 表包含以下列：

• VIEW_CATALOG

  视图所属的目录的名称。该值始终为def。

• VIEW_SCHEMA

  视图所属的模式（数据库）的名称。

• VIEW_NAME

  视图的名称。

• TABLE_CATALOG

  视图定义中使用的表或视图所属的目录名称。该值始终为def。

• TABLE_SCHEMA

  视图定义中使用的表或视图所属的模式（数据库）的名称。

• TABLE_NAME

  视图定义中使用的表或视图的名称。

28.4 INFORMATION_SCHEMA InnoDB 表

原文：dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-tables.html

28.4.1 INFORMATION_SCHEMA InnoDB 表参考

28.4.2 INFORMATION_SCHEMA INNODB_BUFFER_PAGE 表

28.4.3 INFORMATION_SCHEMA INNODB_BUFFER_PAGE_LRU 表

28.4.4 INFORMATION_SCHEMA INNODB_BUFFER_POOL_STATS 表

28.4.5 INFORMATION_SCHEMA INNODB_CACHED_INDEXES 表

28.4.6 INFORMATION_SCHEMA INNODB_CMP 和 INNODB_CMP_RESET 表

28.4.7 INFORMATION_SCHEMA INNODB_CMPMEM 和 INNODB_CMPMEM_RESET 表

28.4.8 INFORMATION_SCHEMA INNODB_CMP_PER_INDEX 和 INNODB_CMP_PER_INDEX_RESET 表

28.4.9 INFORMATION_SCHEMA INNODB_COLUMNS 表

28.4.10 INFORMATION_SCHEMA INNODB_DATAFILES 表

28.4.11 INFORMATION_SCHEMA INNODB_FIELDS 表

28.4.12 INFORMATION_SCHEMA INNODB_FOREIGN 表

28.4.13 INFORMATION_SCHEMA INNODB_FOREIGN_COLS 表

28.4.14 INFORMATION_SCHEMA INNODB_FT_BEING_DELETED 表

28.4.15 INFORMATION_SCHEMA INNODB_FT_CONFIG 表

28.4.16 INFORMATION_SCHEMA INNODB_FT_DEFAULT_STOPWORD 表

28.4.17 INFORMATION_SCHEMA INNODB_FT_DELETED 表

28.4.18 INFORMATION_SCHEMA INNODB_FT_INDEX_CACHE 表

28.4.19 INFORMATION_SCHEMA INNODB_FT_INDEX_TABLE 表

28.4.20 INFORMATION_SCHEMA INNODB_INDEXES 表

28.4.21 INFORMATION_SCHEMA INNODB_METRICS 表

28.4.22 INFORMATION_SCHEMA INNODB_SESSION_TEMP_TABLESPACES 表

28.4.23 INFORMATION_SCHEMA INNODB_TABLES 表

28.4.24 INFORMATION_SCHEMA INNODB_TABLESPACES 表

28.4.25 INFORMATION_SCHEMA INNODB_TABLESPACES_BRIEF 表

28.4.26 INFORMATION_SCHEMA INNODB_TABLESTATS 视图

28.4.27 INFORMATION_SCHEMA INNODB_TEMP_TABLE_INFO 表

28.4.28 INFORMATION_SCHEMA INNODB_TRX 表

28.4.29 INFORMATION_SCHEMA INNODB_VIRTUAL 表

本节提供了 INFORMATION_SCHEMA InnoDB 表的表定义。有关相关信息和示例，请参见 第 17.15 节，“InnoDB INFORMATION_SCHEMA 表”。

INFORMATION_SCHEMA InnoDB 表可用于监控正在进行的 InnoDB 活动，以便在问题出现之前检测效率低下的情况，或者解决性能和容量问题。随着数据库变得越来越大和繁忙，达到硬件容量的极限时，您需要监控和调整这些方面，以确保数据库正常运行。

28.4.1 INFORMATION_SCHEMA InnoDB 表参考

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-table-reference.html

以下表格总结了 INFORMATION_SCHEMA 中的 InnoDB 表。更详细的信息，请参阅各个表的描述。

表 28.3 INFORMATION_SCHEMA InnoDB 表

表名	描述	引入版本
INNODB_BUFFER_PAGE	InnoDB 缓冲池中的页面
INNODB_BUFFER_PAGE_LRU	InnoDB 缓冲池中页面的 LRU 排序
INNODB_BUFFER_POOL_STATS	InnoDB 缓冲池统计信息
INNODB_CACHED_INDEXES	InnoDB 缓冲池中每个索引缓存的索引页数
INNODB_CMP	与压缩的 InnoDB 表相关的操作状态
INNODB_CMP_PER_INDEX	与压缩的 InnoDB 表和索引相关的操作状态
INNODB_CMP_PER_INDEX_RESET	与压缩的 InnoDB 表和索引相关的操作状态
INNODB_CMP_RESET	与压缩的 InnoDB 表相关的操作状态
INNODB_CMPMEM	InnoDB 缓冲池内压缩页面的状态
INNODB_CMPMEM_RESET	InnoDB 缓冲池内压缩页面的状态
INNODB_COLUMNS	每个 InnoDB 表中的列
INNODB_DATAFILES	InnoDB 文件表和通用表空间的数据文件路径信息
INNODB_FIELDS	InnoDB 索引的关键列
INNODB_FOREIGN	InnoDB 外键元数据
INNODB_FOREIGN_COLS	InnoDB 外键列状态信息
INNODB_FT_BEING_DELETED	INNODB_FT_DELETED 表的快照
INNODB_FT_CONFIG	InnoDB 表全文索引和相关处理的元数据
INNODB_FT_DEFAULT_STOPWORD	InnoDB 全文索引的默认停用词列表
INNODB_FT_DELETED	从 InnoDB 表全文索引中删除的行
INNODB_FT_INDEX_CACHE	InnoDB 全文索引中新插入行的标记信息
INNODB_FT_INDEX_TABLE	用于处理针对 InnoDB 表全文索引的文本搜索的倒排索引信息
INNODB_INDEXES	InnoDB 索引元数据
INNODB_METRICS	InnoDB 性能信息
INNODB_SESSION_TEMP_TABLESPACES	会话临时表空间元数据	8.0.13
INNODB_TABLES	InnoDB 表元数据
INNODB_TABLESPACES	InnoDB 按表存储、通用和撤销表空间元数据
INNODB_TABLESPACES_BRIEF	简要��按表存储、通用、撤销和系统表空间元数据
INNODB_TABLESTATS	InnoDB 表低级状态信息
INNODB_TEMP_TABLE_INFO	关于活跃的用户创建的 InnoDB 临时表的信息
INNODB_TRX	活跃的 InnoDB 事务信息
INNODB_VIRTUAL	InnoDB 虚拟生成列元数据
表名	描述	引入版本

28.4.2 INFORMATION_SCHEMA INNODB_BUFFER_PAGE 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-buffer-page-table.html

INNODB_BUFFER_PAGE表提供了关于InnoDB缓冲池中每个页面的信息。

有关相关用法信息和示例，请参见第 17.15.5 节，“InnoDB INFORMATION_SCHEMA 缓冲池表”。

警告

查询INNODB_BUFFER_PAGE表可能会影响性能。除非您了解性能影响并确定其可接受，否则不要在生产系统上查询此表。为避免影响生产系统性能，请在测试实例上重现要调查的问题并查询缓冲池统计信息。

INNODB_BUFFER_PAGE表具有以下列：

• POOL_ID

  缓冲池 ID。这是一个标识符，用于区分多个缓冲池实例。

• 块 ID

  缓冲池块 ID。

• 空间

  表空间 ID；与INNODB_TABLES.SPACE相同。

• PAGE_NUMBER

  页码。

• PAGE_TYPE

  页面类型。以下表显示了允许的值。

  表 28.4 INNODB_BUFFER_PAGE.PAGE_TYPE 值

  页面类型	描述
  ALLOCATED	新分配的页面
  BLOB	未压缩的 BLOB 页面
  COMPRESSED_BLOB2	后续压缩 BLOB 页面
  COMPRESSED_BLOB	第一个压缩的 BLOB 页面
  ENCRYPTED_RTREE	加密的 R 树
  EXTENT_DESCRIPTOR	扩展描述符页面
  FILE_SPACE_HEADER	文件空间头
  FIL_PAGE_TYPE_UNUSED	未使用
  IBUF_BITMAP	插入缓冲位图
  IBUF_FREE_LIST	插入缓冲区空闲列表
  IBUF_INDEX	插入缓冲索引
  INDEX	B 树节点
  INODE	索引节点
  LOB_DATA	未压缩的 LOB 数据
  LOB_FIRST	未压缩 LOB 的第一页
  LOB_INDEX	未压缩的 LOB 索引
  PAGE_IO_COMPRESSED	压缩页面
  PAGE_IO_COMPRESSED_ENCRYPTED	压缩和加密页面
  PAGE_IO_ENCRYPTED	加密页面
  RSEG_ARRAY	回滚段数组
  RTREE_INDEX	R 树索引
  SDI_BLOB	未压缩的 SDI BLOB
  SDI_COMPRESSED_BLOB	压缩的 SDI BLOB
  SDI_INDEX	SDI 索引
  SYSTEM	系统页面
  TRX_SYSTEM	事务系统数据
  UNDO_LOG	撤销日志页面
  UNKNOWN	未知
  ZLOB_DATA	压缩的 LOB 数据
  ZLOB_FIRST	压缩 LOB 的第一页
  ZLOB_FRAG	压缩 LOB 片段
  ZLOB_FRAG_ENTRY	压缩 LOB 片段索引
  ZLOB_INDEX	压缩 LOB 索引
  页面类型	描述

• FLUSH_TYPE

  刷新类型。

• FIX_COUNT

  在缓冲池中使用此块的线程数。当为零时，该块有资格被驱逐。

• IS_HASHED

  是否在此页面上构建了哈希索引。

• NEWEST_MODIFICATION

  最新修改的日志序列号。

• OLDEST_MODIFICATION

  最旧修改的日志序列号。

• ACCESS_TIME

  用于判断页面首次访问时间的抽象数字。

• TABLE_NAME

  页面所属的表的名称。此列仅适用于PAGE_TYPE值为INDEX的页面。如果服务器尚未访问表，则该列为NULL。

• INDEX_NAME

  页面所属的索引的名称。这可以是聚簇索引或二级索引的名称。此列仅适用于PAGE_TYPE值为INDEX的页面。

• NUMBER_RECORDS

  页面内记录的数量。

• DATA_SIZE

  记录大小的总和。此列仅适用于PAGE_TYPE值为INDEX的页面。

• COMPRESSED_SIZE

  压缩页面大小。对于未压缩的页面，为NULL。

• PAGE_STATE

  页面状态。下表显示了允许的值。

  表 28.5 INNODB_BUFFER_PAGE.PAGE_STATE 值

  页面状态	描述
  FILE_PAGE	缓冲文件页面
  MEMORY	包含主内存对象
  NOT_USED	在空闲列表中
  NULL	清洁的压缩页面，刷新列表中的压缩页面，用作缓冲池监视哨的页面
  READY_FOR_USE	空闲页面
  REMOVE_HASH	在放入空闲列表之前应删除哈希索引

• IO_FIX

  此页面是否有任何 I/O 挂起：IO_NONE = 没有挂起的 I/O，IO_READ = 读挂起，IO_WRITE = 写挂起，IO_PIN = 禁止重新定位和从刷新中移除。

• IS_OLD

  块是否在 LRU 列表中旧块的子列表中。

• FREE_PAGE_CLOCK

  当块最后放置在 LRU 列表头部时，freed_page_clock计数器的值。freed_page_clock计数器跟踪从 LRU 列表末尾移除的块数。

• IS_STALE

  页面是否过时。在 MySQL 8.0.24 中添加。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_BUFFER_PAGE LIMIT 1\G
*************************** 1\. row ***************************
            POOL_ID: 0
           BLOCK_ID: 0
              SPACE: 97
        PAGE_NUMBER: 2473
          PAGE_TYPE: INDEX
         FLUSH_TYPE: 1
          FIX_COUNT: 0
          IS_HASHED: YES
NEWEST_MODIFICATION: 733855581
OLDEST_MODIFICATION: 0
        ACCESS_TIME: 3378385672
         TABLE_NAME: `employees`.`salaries`
         INDEX_NAME: PRIMARY
     NUMBER_RECORDS: 468
          DATA_SIZE: 14976
    COMPRESSED_SIZE: 0
         PAGE_STATE: FILE_PAGE
             IO_FIX: IO_NONE
             IS_OLD: YES
    FREE_PAGE_CLOCK: 66
           IS_STALE: NO

注意

• 此表主要用于专家级性能监控，或者在为 MySQL 开发与性能相关的扩展时使用。

• 您必须具有PROCESS权限才能查询此表。

• 使用INFORMATION_SCHEMA COLUMNS表或SHOW COLUMNS语句查看有关此表列的其他信息，包括数据类型和默认值。

• 当删除表、表行、分区或索引时，相关页面会保留在缓冲池中，直到需要空间存储其他数据。INNODB_BUFFER_PAGE 表报告这些页面的信息，直到它们从缓冲池中被驱逐。有关InnoDB如何管理缓冲池数据的更多信息，请参见第 17.5.1 节，“缓冲池”。

28.4.3 INFORMATION_SCHEMA INNODB_BUFFER_PAGE_LRU 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-buffer-page-lru-table.html

INNODB_BUFFER_PAGE_LRU 表提供了关于 InnoDB 缓冲池 中页面的信息；特别是它们在 LRU 列表中的顺序，该列表确定了缓冲池在变满时要从中驱逐的页面。

INNODB_BUFFER_PAGE_LRU 表与 INNODB_BUFFER_PAGE 表具有相同的列，但有一些例外。它具有 LRU_POSITION 和 COMPRESSED 列，而不是 BLOCK_ID 和 PAGE_STATE 列，并且不包括 IS_STALE 列。

有关使用信息和示例，请参见第 17.15.5 节，“InnoDB INFORMATION_SCHEMA Buffer Pool Tables”。

警告

查询 INNODB_BUFFER_PAGE_LRU 表可能会影响性能。除非您了解性能影响并确定其可接受，否则不要在生产系统上查询此表。为避免在生产系统上影响性能，请在测试实例上重现您想要调查的问题，并查询缓冲池统计信息。

INNODB_BUFFER_PAGE_LRU 表具有以下列：

• POOL_ID

  缓冲池 ID。这是一个标识符，用于区分多个缓冲池实例。

• LRU_POSITION

  页在 LRU 列表中的位置。

• SPACE

  表空间 ID；与 INNODB_TABLES.SPACE 相同的值。

• PAGE_NUMBER

  页号。

• PAGE_TYPE

  页类型。下表显示了允许的值。

  表 28.6 INNODB_BUFFER_PAGE_LRU.PAGE_TYPE 值

  页类型	描述
  ALLOCATED	新分配的页面
  BLOB	未压缩的 BLOB 页面
  COMPRESSED_BLOB2	后续压缩 BLOB 页面
  COMPRESSED_BLOB	第一��压缩的 BLOB 页面
  ENCRYPTED_RTREE	加密的 R 树
  EXTENT_DESCRIPTOR	扩展描述符页面
  FILE_SPACE_HEADER	文件空间头
  FIL_PAGE_TYPE_UNUSED	未使用
  IBUF_BITMAP	插入缓冲位图
  IBUF_FREE_LIST	插入缓冲空闲列表
  IBUF_INDEX	插入缓冲索引
  INDEX	B 树节点
  INODE	索引节点
  LOB_DATA	未压缩的 LOB 数据
  LOB_FIRST	未压缩 LOB 的第一页
  LOB_INDEX	未压缩 LOB 索引
  PAGE_IO_COMPRESSED	压缩页面
  PAGE_IO_COMPRESSED_ENCRYPTED	压缩且加密的页面
  PAGE_IO_ENCRYPTED	加密页面
  RSEG_ARRAY	回滚段数组
  RTREE_INDEX	R 树索引
  SDI_BLOB	未压缩的 SDI BLOB
  SDI_COMPRESSED_BLOB	压缩的 SDI BLOB
  SDI_INDEX	SDI 索引
  SYSTEM	系统页
  TRX_SYSTEM	事务系统数据
  UNDO_LOG	撤销日志页
  UNKNOWN	未知
  ZLOB_DATA	压缩 LOB 数据
  ZLOB_FIRST	压缩 LOB 的第一页
  ZLOB_FRAG	压缩 LOB 片段
  ZLOB_FRAG_ENTRY	压缩 LOB 片段索引
  ZLOB_INDEX	压缩 LOB 索引
  页面类型	描述

• FLUSH_TYPE

  刷新类型。

• FIX_COUNT

  在缓冲池中使用此块的线程数。当为零时，该块有资格被驱逐。

• IS_HASHED

  是否在此页面上构建了哈希索引。

• NEWEST_MODIFICATION

  最新修改的日志序列号。

• OLDEST_MODIFICATION

  最旧修改的日志序列号。

• ACCESS_TIME

  用于判断页面首次访问时间的抽象数字。

• TABLE_NAME

  页面所属表的名称。此列仅适用于PAGE_TYPE值为INDEX的页面。如果服务器尚未访问表，则列为NULL。

• INDEX_NAME

  页面所属索引的名称。这可以是聚簇索引或二级索引的名称。此列仅适用于PAGE_TYPE值为INDEX的页面。

• NUMBER_RECORDS

  页面内记录的数量。

• DATA_SIZE

  记录大小的总和。此列仅适用于PAGE_TYPE值为INDEX的页面。

• COMPRESSED_SIZE

  压缩页面大小。对于未压缩的页面，为NULL。

• COMPRESSED

  页面是否被压缩。

• IO_FIX

  是否有任何 I/O 挂起在此页面：IO_NONE = 没有挂起的 I/O，IO_READ = 读取挂起，IO_WRITE = 写入挂起。

• IS_OLD

  块是否在 LRU 列表中旧块的子列表中。

• FREE_PAGE_CLOCK

  当块最后放置在 LRU 列表头部时，freed_page_clock计数器的值。freed_page_clock计数器跟踪从 LRU 列表末尾移除的块数。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_BUFFER_PAGE_LRU LIMIT 1\G
*************************** 1\. row ***************************
            POOL_ID: 0
       LRU_POSITION: 0
              SPACE: 97
        PAGE_NUMBER: 1984
          PAGE_TYPE: INDEX
         FLUSH_TYPE: 1
          FIX_COUNT: 0
          IS_HASHED: YES
NEWEST_MODIFICATION: 719490396
OLDEST_MODIFICATION: 0
        ACCESS_TIME: 3378383796
         TABLE_NAME: `employees`.`salaries`
         INDEX_NAME: PRIMARY
     NUMBER_RECORDS: 468
          DATA_SIZE: 14976
    COMPRESSED_SIZE: 0
         COMPRESSED: NO
             IO_FIX: IO_NONE
             IS_OLD: YES
    FREE_PAGE_CLOCK: 0

注意

• 此表主要用于专家级性能监控，或者在为 MySQL 开发与性能相关的扩展时使用。

• 您必须具有PROCESS权限才能查询此表。

• 使用INFORMATION_SCHEMA COLUMNS表或SHOW COLUMNS语句查看有关此表的列的其他信息，包括数据类型和默认值。

• 查询此表可能需要 MySQL 分配一个大块连续内存，超过缓冲池中活动页面数量的 64 字节倍。这种分配可能会导致内存不足错误，特别是对于具有多千兆字节缓冲池的系统。

• 查询此表需要 MySQL 在遍历 LRU 列表时锁定表示缓冲池的数据结构，这可能会降低并发性，特别是对于具有多千兆字节缓冲池的系统。

• 当删除表、表行、分区或索引时，相关页面会保留在缓冲池中，直到为其他数据需要空间。INNODB_BUFFER_PAGE_LRU表报告有关这些页面的信息，直到它们从缓冲池中被驱逐。有关InnoDB如何管理缓冲池数据的更多信息，请参见 Section 17.5.1, “Buffer Pool”。