MySQL8-中文参考-四十六-
MySQL8 中文参考(四十六)
27.5.5 视图元数据
要获取有关视图的元数据:
-
查询
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 视图的限制
在视图定义中引用的表的最大数量为 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 表
目录
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
选项启动的)。 -
当前经过身份验证的帐户具有
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”。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步