MySQL8-中文参考-一百零二-

布客飞龙
187 阅读1小时+

MySQL8 中文参考（一百零二）

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

27.4.3 事件语法

原文：dev.mysql.com/doc/refman/8.0/en/events-syntax.html

MySQL 提供了几个用于处理计划事件的 SQL 语句：

  • 使用CREATE EVENT语句定义新事件。参见 Section 15.1.13, “CREATE EVENT Statement”。

  • 通过ALTER EVENT语句可以更改现有事件的定义。参见 Section 15.1.3, “ALTER EVENT Statement”。

  • 当不再需要或不再需要计划事件时，可以由其定义者使用DROP EVENT语句从服务器中删除。参见 Section 15.1.25, “DROP EVENT Statement”。事件是否在其计划结束后继续存在还取决于其ON COMPLETION子句，如果有的话。参见 Section 15.1.13, “CREATE EVENT Statement”。

    任何具有数据库上定义事件的EVENT权限的用户都可以删除事件。参见 Section 27.4.6, “The Event Scheduler and MySQL Privileges”。

27.4.4 事件元数据

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

要获取有关事件的元数据：

  • 查询INFORMATION_SCHEMA数据库的EVENTS表。参见 Section 28.3.14, “The INFORMATION_SCHEMA EVENTS Table”。

  • 使用SHOW CREATE EVENT语句。参见 Section 15.7.7.7, “SHOW CREATE EVENT Statement”。

  • 使用SHOW EVENTS语句。参见 Section 15.7.7.18, “SHOW EVENTS Statement”。

事件调度器时间表示

MySQL 中的每个会话都有一个会话时区（STZ）。这是会话time_zone值，当会话开始时从服务器的全局time_zone值初始化，但在会话期间可能会更改。

当CREATE EVENT或ALTER EVENT语句执行时，使用当前会话时区来解释事件定义中指定的时间。这成为事件时区（ETZ）；也就是用于事件调度并在事件执行时生效的时区。

为了在数据字典中表示事件信息，execute_at、starts和ends时间被转换为 UTC 并与事件时区一起存储。这使得事件执行可以按照定义进行，而不受服务器时区或夏令时效果的影响。last_executed时间也以 UTC 存储。

事件时间可以通过从信息模式EVENTS表或SHOW EVENTS中选择来获取，但它们以 ETZ 或 STZ 值报告。以下表总结了事件时间的表示。

值EVENTS 表SHOW EVENTS
执行时间ETZETZ
开始时间ETZETZ
结束时间ETZETZ
上次执行时间ETZn/a
创建时间STZn/a
上次修改时间STZn/a

27.4.5 事件调度程序状态

原文：dev.mysql.com/doc/refman/8.0/en/events-status-info.html

事件调度程序会将执行过程中出现错误或警告的事件信息写入 MySQL 服务器的错误日志。参见第 27.4.6 节，“事件调度程序和 MySQL 权限”中的示例。

为了获取有关事件调度程序状态的信息，以进行调试和故障排除，运行mysqladmin debug（参见第 6.5.2 节，“mysqladmin — 一个 MySQL 服务器管理程序”）；运行此命令后，服务器的错误日志将包含与事件调度程序相关的输出，类似于这里显示的内容：

Events status:
LLA = Last Locked At  LUA = Last Unlocked At
WOC = Waiting On Condition  DL = Data Locked

Event scheduler status:
State      : INITIALIZED
Thread id  : 0
LLA        : n/a:0
LUA        : n/a:0
WOC        : NO
Workers    : 0
Executed   : 0
Data locked: NO

Event queue status:
Element count   : 0
Data locked     : NO
Attempting lock : NO
LLA             : init_queue:95
LUA             : init_queue:103
WOC             : NO
Next activation : never

在事件调度程序执行的语句中，诊断消息（不仅限于错误，还包括警告）会被写入错误日志，并且在 Windows 上也会写入应用程序事件日志。对于频繁执行的事件，可能会导致许多日志消息。例如，对于SELECT ... INTO *var_list*语句，如果查询没有返回任何行，会出现带有错误代码 1329 的警告（没有数据），并且变量值保持不变。如果查询返回多行，会出现错误 1172（结果包含多于一行）。对于任一条件，您可以通过声明条件处理程序来避免警告被记录；参见第 15.6.7.2 节，“DECLARE ... HANDLER 语句”。对于可能检索多行的语句，另一种策略是使用LIMIT 1将结果集限制为单行。

27.4.6 事件调度程序和 MySQL 权限

原文：dev.mysql.com/doc/refman/8.0/en/events-privileges.html

要启用或禁用计划事件的执行，需要设置全局event_scheduler系统变量的值。这需要足够的权限来设置全局系统变量。参见第 7.1.9.1 节，“系统变量权限”。

EVENT权限管理事件的创建、修改和删除。可以使用GRANT授予此权限。例如，此GRANT语句将在用户jon@ghidora上为名为myschema的模式授予EVENT权限：

GRANT EVENT ON myschema.* TO jon@ghidora;

（我们假设该用户帐户已经存在，并且我们希望其保持不变。）

要授予同一用户在所有模式上的EVENT权限，请使用以下语句：

GRANT EVENT ON *.* TO jon@ghidora;

EVENT权限具有全局或模式级别范围。因此，尝试在单个表上授予它会导致错误，如下所示：

mysql> GRANT EVENT ON myschema.mytable TO jon@ghidora;
ERROR 1144 (42000): Illegal GRANT/REVOKE command; please
consult the manual to see which privileges can be used

重要的是要理解事件是以其定义者的权限执行的，并且它不能执行其定义者没有所需权限的任何操作。例如，假设jon@ghidora对myschema具有EVENT权限。还假设该用户对myschema具有SELECT权限，但对该模式没有其他权限。jon@ghidora可以创建一个新事件，如下所示：

CREATE EVENT e_store_ts
    ON SCHEDULE
      EVERY 10 SECOND
    DO
      INSERT INTO myschema.mytable VALUES (UNIX_TIMESTAMP());

用户等待一分钟左右，然后执行SELECT * FROM mytable;查询，期望在表中看到几行新数据。然而，表是空的。由于用户没有表的INSERT权限，因此事件没有效果。

如果检查 MySQL 错误日志（*hostname*.err），您会看到事件正在执行，但它尝试执行的操作失败：

2013-09-24T12:41:31.261992Z 25 [ERROR] Event Scheduler:
[jon@ghidora][cookbook.e_store_ts] INSERT command denied to user
'jon'@'ghidora' for table 'mytable'
2013-09-24T12:41:31.262022Z 25 [Note] Event Scheduler:
[jon@ghidora].[myschema.e_store_ts] event execution failed.
2013-09-24T12:41:41.271796Z 26 [ERROR] Event Scheduler:
[jon@ghidora][cookbook.e_store_ts] INSERT command denied to user
'jon'@'ghidora' for table 'mytable'
2013-09-24T12:41:41.272761Z 26 [Note] Event Scheduler:
[jon@ghidora].[myschema.e_store_ts] event execution failed.

由于这个用户很可能无法访问错误日志，可以通过直接执行事件的操作语句来验证该事件是否有效：

mysql> INSERT INTO myschema.mytable VALUES (UNIX_TIMESTAMP());
ERROR 1142 (42000): INSERT command denied to user
'jon'@'ghidora' for table 'mytable'

检查信息模式EVENTS表显示e_store_ts存在且已启用，但其LAST_EXECUTED列为NULL：

mysql> SELECT * FROM INFORMATION_SCHEMA.EVENTS
     >     WHERE EVENT_NAME='e_store_ts'
     >     AND EVENT_SCHEMA='myschema'\G
*************************** 1\. row ***************************
   EVENT_CATALOG: NULL
    EVENT_SCHEMA: myschema
      EVENT_NAME: e_store_ts
         DEFINER: jon@ghidora
      EVENT_BODY: SQL
EVENT_DEFINITION: INSERT INTO myschema.mytable VALUES (UNIX_TIMESTAMP())
      EVENT_TYPE: RECURRING
      EXECUTE_AT: NULL
  INTERVAL_VALUE: 5
  INTERVAL_FIELD: SECOND
        SQL_MODE: NULL
          STARTS: 0000-00-00 00:00:00
            ENDS: 0000-00-00 00:00:00
          STATUS: ENABLED
   ON_COMPLETION: NOT PRESERVE
         CREATED: 2006-02-09 22:36:06
    LAST_ALTERED: 2006-02-09 22:36:06
   LAST_EXECUTED: NULL
   EVENT_COMMENT: 1 row in set (0.00 sec)

要撤销EVENT权限，请使用REVOKE语句。在此示例中，从jon@ghidora用户账户中移除了模式myschema上的EVENT权限：

REVOKE EVENT ON myschema.* FROM jon@ghidora;

重要提示

从用户那里撤销EVENT权限不会删除或禁用该用户可能创建的任何事件。

事件不会因为创建它的用户被重命名或删除而迁移或删除。

假设用户jon@ghidora已被授予myschema模式上的EVENT和INSERT权限。然后该用户创建了以下事件：

CREATE EVENT e_insert
    ON SCHEDULE
      EVERY 7 SECOND
    DO
      INSERT INTO myschema.mytable;

创建了这个事件后，root撤销了jon@ghidora的EVENT权限。然而，e_insert继续执行，每七秒插入一行到mytable中。如果root发出了以下任一语句，情况也是如此：

  • DROP USER jon@ghidora;

  • RENAME USER jon@ghidora TO someotherguy@ghidora;

您可以通过在发出DROP USER或RENAME USER语句之前和之后检查信息模式EVENTS表来验证这一点。

事件定义存储在数据字典中。要删除由另一个用户账户创建的事件，您必须是 MySQL root用户或具有必要权限的其他用户。

用户的EVENT权限存储在mysql.user和mysql.db表的Event_priv列中。在这两种情况下，该列保存值'Y'或'N'中的一个。'N'是默认值。对于给定用户，只有当该用户具有全局EVENT权限（即，如果使用GRANT EVENT ON *.*授予了权限）时，mysql.user.Event_priv才设置为'Y'。对于模式级别的EVENT权限，GRANT在mysql.db中创建一行，并将该行的Db列设置为模式名称，User列设置为用户名称，Event_priv列设置为'Y'。永远不应该直接操作这些表，因为GRANT EVENT和REVOKE EVENT语句会在其上执行所需的操作。

五个状态变量提供了与事件相关操作的计数（但不包括事件执行的语句；请参阅第 27.8 节，“存储程序的限制”）。这些是：

  • Com_create_event: 自上次服务器重启以来执行的CREATE EVENT语句的次数。

  • Com_alter_event: 自上次服务器重启以来执行的ALTER EVENT语句的次数。

  • Com_drop_event: 自上次服务器重启以来执行的DROP EVENT语句的次数。

  • Com_show_create_event: 自上次服务器重启以来执行的SHOW CREATE EVENT语句的次数。

  • Com_show_events: 自上次服务器重启以来执行的SHOW EVENTS语句的次数。

通过运行语句SHOW STATUS LIKE '%event%';，您可以一次查看所有这些的当前值。

27.5 使用视图

原文：dev.mysql.com/doc/refman/8.0/en/views.html

27.5.1 视图语法

27.5.2 视图处理算法

27.5.3 可更新和可插入视图

27.5.4 带有 CHECK OPTION 子句的视图

27.5.5 视图元数据

MySQL 支持视图，包括可更新的视图。视图是存储的查询，当调用时产生一个结果集。视图充当虚拟表。

以下讨论描述了创建和删除视图的语法，并展示了如何使用它们的一些示例。

其他资源

  • 在处理视图时，您可能会发现MySQL 用户论坛很有帮助。

  • 关于 MySQL 中视图的一些常见问题的答案，请参见第 A.6 节，“MySQL 8.0 FAQ：视图”。

  • 使用视图时有一些限制；参见第 27.9 节，“视图限制”。

27.5.1 视图语法

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

CREATE VIEW语句创建一个新视图（参见 Section 15.1.23, “CREATE VIEW Statement”）。要修改视图的定义或删除视图，请使用ALTER VIEW（参见 Section 15.1.11, “ALTER VIEW Statement”）或DROP VIEW（参见 Section 15.1.35, “DROP VIEW Statement”）。

视图可以从多种类型的SELECT语句创建。它可以引用基本表或其他视图。它可以使用连接、UNION和子查询。SELECT甚至不需要引用任何表。以下示例定义了一个视图，从另一个表中选择了两列，以及从这些列计算出的表达式：

mysql> CREATE TABLE t (qty INT, price INT);
mysql> INSERT INTO t VALUES(3, 50), (5, 60);
mysql> CREATE VIEW v AS SELECT qty, price, qty*price AS value FROM t;
mysql> SELECT * FROM v;
+------+-------+-------+
| qty  | price | value |
+------+-------+-------+
|    3 |    50 |   150 |
|    5 |    60 |   300 |
+------+-------+-------+
mysql> SELECT * FROM v WHERE qty = 5;
+------+-------+-------+
| qty  | price | value |
+------+-------+-------+
|    5 |    60 |   300 |
+------+-------+-------+

27.5.2 视图处理算法

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

CREATE VIEW 或 ALTER VIEW 的可选 ALGORITHM 子句是 MySQL 对标准 SQL 的扩展。它影响 MySQL 处理视图的方式。ALGORITHM 有三个值：MERGE、TEMPTABLE 或 UNDEFINED。

  • 对于 MERGE，引用视图的语句文本和视图定义被合并，以便视图定义的部分替换语句的相应部分。

  • 对于 TEMPTABLE，视图的结果被检索到一个临时表中，然后用于执行语句。

  • 对于 UNDEFINED，MySQL 会选择使用哪种算法。如果可能的话，它会优先选择 MERGE 而不是 TEMPTABLE，因为 MERGE 通常更有效率，而且如果使用临时表，则视图无法更新。

  • 如果没有 ALGORITHM 子句，则默认算法由 optimizer_switch 系统变量的 derived_merge 标志的值确定。有关更多讨论，请参见 Section 10.2.2.4, “Optimizing Derived Tables, View References, and Common Table Expressions with Merging or Materialization”。

明确指定 TEMPTABLE 的一个原因是，在创建临时表后并在用于完成语句处理之前，可以释放对基础表的锁。这可能导致比 MERGE 算法更快地释放锁，以便使用视图的其他客户端不会被阻塞太久。

视图算法可能为 UNDEFINED 有三个原因：

  • CREATE VIEW 语句中没有 ALGORITHM 子句。

  • CREATE VIEW 语句具有显式的 ALGORITHM = UNDEFINED 子句。

  • 为只能使用临时表处理的视图指定了 ALGORITHM = MERGE。在这种情况下，MySQL 会生成警告并将算法设置为 UNDEFINED。

如前所述，MERGE 是通过将视图定义的相应部分合并到引用该视图的语句中来处理的。以下示例简要说明了 MERGE 算法的工作原理。这些示例假设存在一个具有以下定义的视图 v_merge：

CREATE ALGORITHM = MERGE VIEW v_merge (vc1, vc2) AS
SELECT c1, c2 FROM t WHERE c3 > 100;

示例 1：假设我们发出以下语句：

SELECT * FROM v_merge;

MySQL 处理该语句如下：

  • v_merge 变为 t

  • * 变为 vc1, vc2，对应于 c1, c2

  • 视图 WHERE 子句被添加

要执行的结果语句变为：

SELECT c1, c2 FROM t WHERE c3 > 100;

示例 2：假设我们发出以下语句：

SELECT * FROM v_merge WHERE vc1 < 100;

这个语句的处理方式与前一个类似，只是vc1 < 100变成了c1 < 100，并且视图的WHERE子句被添加到语句的WHERE子句中，使用AND连接词（并且添加括号以确保子句的部分以正确的优先级执行）。最终要执行的语句变为：

SELECT c1, c2 FROM t WHERE (c3 > 100) AND (c1 < 100);

实际上，要执行的语句具有以下形式的WHERE子句：

WHERE (select WHERE) AND (view WHERE)

如果无法使用MERGE算法，则必须使用临时表。阻止合并的结构与阻止派生表和公共表达式合并的结构相同。例如，在子查询中使用SELECT DISTINCT或LIMIT。有关详细信息，请参见 Section 10.2.2.4，“使用合并或实体化优化派生表、视图引用和公共表达式”。

27.5.3 可更新和可插入视图

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

一些视图是可更新的，并且对它们的引用可以用于指定在数据更改语句中要更新的表。也就是说，您可以在UPDATE、DELETE或INSERT等语句中使用它们来更新基础表的内容。派生表和公共表达式也可以在多表UPDATE和DELETE语句中指定，但只能用于读取数据以指定要更新或删除的行。通常，视图引用必须是可更新的，这意味着它们可以合并而不是实体化。复合视图有更复杂的规则。

要使视图可更新，视图中的行与基础表中的行之间必须是一对一的关系。还有一些其他构造使视图不可更新。更具体地说，如果视图包含以下任何内容，则视图不可更新：

  • 聚合函数或窗口函数（SUM()、MIN()、MAX()、COUNT()等）

  • DISTINCT

  • GROUP BY

  • HAVING

  • UNION或UNION ALL

  • 在选择列表中的子查询

    在选择列表中，非依赖子查询对于INSERT失败，但对于UPDATE和DELETE可行。对于选择列表中的依赖子查询，不允许数据更改语句。

  • 某些连接（请参阅本节后面的其他连接讨论）

  • 在FROM子句中引用不可更新的视图

  • 在FROM子句中引用WHERE子句中的子查询

  • 仅引用文字值（在这种情况下，没有要更新的基础表）

  • ALGORITHM = TEMPTABLE（始终使用临时表会使视图不可更新）

  • 对基表的任何列的多次引用（对于INSERT失败，对于UPDATE和DELETE可行）

视图中的生成列被视为可更新，因为可以对其进行赋值。但是，如果显式更新此类列，则唯一允许的值是DEFAULT。有关生成列的信息，请参见第 15.1.20.8 节，“CREATE TABLE and Generated Columns”。

有时，多表视图可能是可更新的，假设它可以使用MERGE算法处理。为使其工作，视图必须使用内连接（而不是外连接或UNION）。此外，视图定义中只能更新一个表，因此SET子句必须仅命名视图中一个表的列。即使理论上可更新，也不允许使用UNION ALL的视图。

就插入性（使用INSERT语句可更新）而言，如果可更新视图还满足视图列的以下附加要求，则可插入：

  • 视图列名称不能重复。

  • 视图必须包含基表中没有默认值的所有列。

  • 视图列必须是简单的列引用。不能是表达式，比如这些：

    3.14159
col1 + 3
UPPER(col2)
col3 / col4
(*subquery*)

MySQL 在CREATE VIEW时设置一个称为视图可更新性标志的标志。如果视图对UPDATE和DELETE（以及类似操作）是合法的，则将该标志设置为YES（true）。否则，将该标志设置为NO（false）。信息模式VIEWS表中的IS_UPDATABLE列显示此标志的状态。这意味着服务器始终知道视图是否可更新。

如果视图不可更新，则UPDATE、DELETE和INSERT等语句是非法的并将被拒绝。（即使视图是可更新的，也可能无法插入，如本节其他地方所述。）

视图的可更新性可能会受到updatable_views_with_limit系统变量值的影响。请参阅第 7.1.8 节，“服务器系统变量”。

对于以下讨论，假设存在这些表和视图：

CREATE TABLE t1 (x INTEGER);
CREATE TABLE t2 (c INTEGER);
CREATE VIEW vmat AS SELECT SUM(x) AS s FROM t1;
CREATE VIEW vup AS SELECT * FROM t2;
CREATE VIEW vjoin AS SELECT * FROM vmat JOIN vup ON vmat.s=vup.c;

允许INSERT、UPDATE和DELETE语句如下：

  • INSERT：INSERT语句的插入表可以是一个合并的视图引用。如果视图是一个连接视图，则视图的所有组件必须是可更新的（非物化的）。对于多表可更新视图，如果插入到单个表，则INSERT可以工作。

    该语句无效，因为连接视图的一个组件是不可更新的：

    INSERT INTO vjoin (c) VALUES (1);

    这个语句是有效的；视图不包含实体组件：

    INSERT INTO vup (c) VALUES (1);

  • UPDATE：在UPDATE语句中要更新的表或表可以是合并的视图引用。如果一个视图是连接视图，视图的至少一个组件必须是可更新的（这与INSERT不同）。

    在多表UPDATE语句中，语句的更新表引用必须是基本表或可更新的视图引用。未更新的表引用可以是物化视图或派生表。

    这个语句是有效的；列c来自连接视图的可更新部分：

    UPDATE vjoin SET c=c+1;

    这个语句是无效的；列x来自不可更新的部分：

    UPDATE vjoin SET x=x+1;

    这个语句是有效的；多表UPDATE的更新表引用是一个可更新的视图（vup）：

    UPDATE vup JOIN (SELECT SUM(x) AS s FROM t1) AS dt ON ...
SET c=c+1;

    这个语句是无效的；它试图更新一个实体派生表：

    UPDATE vup JOIN (SELECT SUM(x) AS s FROM t1) AS dt ON ...
SET s=s+1;

  • DELETE：在DELETE语句中要从中删除的表或表必须是合并视图。不允许连接视图（这与INSERT和UPDATE不同）。

    这个语句是无效的，因为视图是一个连接视图：

    DELETE vjoin WHERE ...;

    这个语句是有效的，因为视图是一个合并的（可更新的）视图：

    DELETE vup WHERE ...;

    这个语句是有效的，因为它从一个合并的（可更新的）视图中删除：

    DELETE vup FROM vup JOIN (SELECT SUM(x) AS s FROM t1) AS dt ON ...;

附加讨论和示例如下。

本节早期讨论指出，如果视图不是所有列都是简单列引用（例如，如果包含表达式或复合表达式的列），则视图是不可插入的。尽管这样的视图不可插入，但如果只更新非表达式列，则可以更新。考虑这个视图：

CREATE VIEW v AS SELECT col1, 1 AS col2 FROM t;

这个视图不可插入，因为col2是一个表达式。但如果更新不尝试更新col2，则可以更新。这个更新是允许的：

UPDATE v SET col1 = 0;

此更新不允许，因为它试图更新一个表达式列：

UPDATE v SET col2 = 0;

如果表包含一个AUTO_INCREMENT列，在对不包括AUTO_INCREMENT列的表上插入可插入视图时，不会改变LAST_INSERT_ID()的值，因为插入默认值到视图中不是可见的列的副作用不应该可见。

27.5.4 视图 WITH CHECK OPTION 子句

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

可以为可更新视图提供WITH CHECK OPTION子句，以防止插入到select_statement中WHERE子句不为真的行。它还防止更新使WHERE子句为真但更新会导致其不为真的行（换句话说，它防止可见行被更新为不可见行）。

在可更新视图的WITH CHECK OPTION子句中，LOCAL和CASCADED关键字确定了在视图以另一个视图的形式定义时进行检查测试的范围。当没有给出关键字时，默认为CASCADED。

WITH CHECK OPTION测试符合标准：

  • 使用LOCAL，视图WHERE子句会被检查，然后检查递归到底层视图并应用相同的规则。

  • 使用CASCADED，视图WHERE子句会被检查，然后检查递归到底层视图，为它们添加WITH CASCADED CHECK OPTION（用于检查目的；它们的定义保持不变），并应用相同的规则。

  • 没有检查选项时，视图WHERE子句不会被检查，然后检查会递归到底层视图，并应用相同的规则。

考虑以下表和一组视图的定义：

CREATE TABLE t1 (a INT);
CREATE VIEW v1 AS SELECT * FROM t1 WHERE a < 2
WITH CHECK OPTION;
CREATE VIEW v2 AS SELECT * FROM v1 WHERE a > 0
WITH LOCAL CHECK OPTION;
CREATE VIEW v3 AS SELECT * FROM v1 WHERE a > 0
WITH CASCADED CHECK OPTION;

这里的v2和v3视图是以另一个视图v1的形式定义的。

对于v2的插入会根据其LOCAL检查选项进行检查，然后检查递归到v1并再次应用规则。v1的规则导致检查失败。v3的检查也失败：

mysql> INSERT INTO v2 VALUES (2);
ERROR 1369 (HY000): CHECK OPTION failed 'test.v2'
mysql> INSERT INTO v3 VALUES (2);
ERROR 1369 (HY000): CHECK OPTION failed 'test.v3'

27.5.5 视图元数据

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

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

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

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

27.6 存储对象访问控制

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

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

  • DEFINER 属性

  • SQL 安全特性

  • 示例

  • 孤立存储对象

  • 风险最小化指南

DEFINER 属性

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

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

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

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

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

SQL 安全特性

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

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

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

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

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

例子

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

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

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

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

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

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

孤立的存储对象

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

风险最小化准则

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    mysql> SET GLOBAL log_bin_trust_function_creators = 1;

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

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

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

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

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

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

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

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

    CREATE FUNCTION f1(a INT) RETURNS INT
BEGIN
  IF (a < 3) THEN
    INSERT INTO t2 VALUES (a);
  END IF;
  RETURN 0;
END;

CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (1),(2),(3);

SELECT f1(a) FROM t1;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      NAME_CONST(*var_name*, *var_value*)

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

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

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

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

      CREATE TABLE t1 SELECT myvar;

      重写如下：

      CREATE TABLE t1 SELECT NAME_CONST(myvar, 1);

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

      CREATE TABLE t1 SELECT myvar AS myvar;

      重写后的语句如下：

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

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

      SET @my_var = *value*;

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

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

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

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

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

27.8 存储程序的限制

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

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

  • 存储函数的限制

  • 触发器的限制

  • 存储过程中的名称冲突

  • 复制注意事项

  • 调试注意事项

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

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

  • 事件调度程序的限制

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

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

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

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

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

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

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

  • 锁定语句LOCK TABLES和UNLOCK TABLES。

  • ALTER VIEW。

  • LOAD DATA 和 LOAD XML。

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

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

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

存储函数的限制

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

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

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

  • FLUSH语句。

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

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

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

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

`### 触发器的限制

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

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

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

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

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

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

存储例程内的名称冲突

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

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

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

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

  • 例程参数优先于表列。

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

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

复制考虑事项

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

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

调试考虑事项

没有存储例程调试设施。

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

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

  • UNDO 处理程序

  • FOR 循环

存储例程并发考虑事项

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

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

事件调度程序限制

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

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

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

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

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

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

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

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

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

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

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

警告

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

27.9 视图的限制

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

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

视图处理未经优化：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第二十八章 INFORMATION_SCHEMA 表

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

目录

28.1 简介

28.2 INFORMATION_SCHEMA 表参考

28.3 INFORMATION_SCHEMA 通用表

28.3.1 INFORMATION_SCHEMA 通用表参考

28.3.2 INFORMATION_SCHEMA ADMINISTRABLE_ROLE_AUTHORIZATIONS 表

28.3.3 INFORMATION_SCHEMA APPLICABLE_ROLES 表

28.3.4 INFORMATION_SCHEMA CHARACTER_SETS 表

28.3.5 INFORMATION_SCHEMA CHECK_CONSTRAINTS 表

28.3.6 INFORMATION_SCHEMA COLLATIONS 表

28.3.7 INFORMATION_SCHEMA COLLATION_CHARACTER_SET_APPLICABILITY 表

28.3.8 INFORMATION_SCHEMA COLUMNS 表

28.3.9 INFORMATION_SCHEMA COLUMNS_EXTENSIONS 表

28.3.10 INFORMATION_SCHEMA COLUMN_PRIVILEGES 表

28.3.11 INFORMATION_SCHEMA COLUMN_STATISTICS 表

28.3.12 INFORMATION_SCHEMA ENABLED_ROLES 表

28.3.13 INFORMATION_SCHEMA ENGINES 表

28.3.14 INFORMATION_SCHEMA EVENTS 表

28.3.15 INFORMATION_SCHEMA FILES ��

28.3.16 INFORMATION_SCHEMA KEY_COLUMN_USAGE 表

28.3.17 INFORMATION_SCHEMA KEYWORDS 表

28.3.18 INFORMATION_SCHEMA ndb_transid_mysql_connection_map 表

28.3.19 INFORMATION_SCHEMA OPTIMIZER_TRACE 表

28.3.20 INFORMATION_SCHEMA PARAMETERS 表

28.3.21 INFORMATION_SCHEMA PARTITIONS 表

28.3.22 INFORMATION_SCHEMA PLUGINS 表

28.3.23 INFORMATION_SCHEMA PROCESSLIST 表

28.3.24 INFORMATION_SCHEMA PROFILING 表

28.3.25 INFORMATION_SCHEMA REFERENTIAL_CONSTRAINTS 表

28.3.26 INFORMATION_SCHEMA RESOURCE_GROUPS 表

28.3.27 INFORMATION_SCHEMA ROLE_COLUMN_GRANTS 表

28.3.28 INFORMATION_SCHEMA ROLE_ROUTINE_GRANTS 表

28.3.29 INFORMATION_SCHEMA ROLE_TABLE_GRANTS 表

28.3.30 INFORMATION_SCHEMA ROUTINES 表

28.3.31 INFORMATION_SCHEMA SCHEMATA 表

28.3.32 INFORMATION_SCHEMA SCHEMATA_EXTENSIONS 表

28.3.33 INFORMATION_SCHEMA SCHEMA_PRIVILEGES 表

28.3.34 INFORMATION_SCHEMA STATISTICS 表

28.3.35 INFORMATION_SCHEMA ST_GEOMETRY_COLUMNS 表

28.3.36 INFORMATION_SCHEMA ST_SPATIAL_REFERENCE_SYSTEMS 表

28.3.37 INFORMATION_SCHEMA ST_UNITS_OF_MEASURE 表

28.3.38 INFORMATION_SCHEMA TABLES 表

28.3.39 INFORMATION_SCHEMA TABLES_EXTENSIONS 表

28.3.40 INFORMATION_SCHEMA TABLESPACES 表

28.3.41 INFORMATION_SCHEMA TABLESPACES_EXTENSIONS 表

28.3.42 INFORMATION_SCHEMA TABLE_CONSTRAINTS 表

28.3.43 INFORMATION_SCHEMA TABLE_CONSTRAINTS_EXTENSIONS 表

28.3.44 INFORMATION_SCHEMA TABLE_PRIVILEGES 表

28.3.45 INFORMATION_SCHEMA TRIGGERS 表

28.3.46 INFORMATION_SCHEMA USER_ATTRIBUTES 表

28.3.47 INFORMATION_SCHEMA USER_PRIVILEGES 表

28.3.48 INFORMATION_SCHEMA VIEWS 表

28.3.49 INFORMATION_SCHEMA VIEW_ROUTINE_USAGE 表

28.3.50 INFORMATION_SCHEMA VIEW_TABLE_USAGE 表

28.4 INFORMATION_SCHEMA InnoDB 表

28.4.1 INFORMATION_SCHEMA InnoDB 表参考

28.4.2 INFORMATION_SCHEMA INNODB_BUFFER_PAGE 表

28.4.3 INFORMATION_SCHEMA INNODB_BUFFER_PAGE_LRU 表

28.4.4 INFORMATION_SCHEMA INNODB_BUFFER_POOL_STATS 表

28.4.5 INFORMATION_SCHEMA INNODB_CACHED_INDEXES 表

28.4.6 INFORMATION_SCHEMA INNODB_CMP 和 INNODB_CMP_RESET 表

28.4.7 INFORMATION_SCHEMA INNODB_CMPMEM 和 INNODB_CMPMEM_RESET 表

28.4.8 INFORMATION_SCHEMA INNODB_CMP_PER_INDEX 和 INNODB_CMP_PER_INDEX_RESET 表

28.4.9 INFORMATION_SCHEMA INNODB_COLUMNS 表

28.4.10 INFORMATION_SCHEMA INNODB_DATAFILES 表

28.4.11 INFORMATION_SCHEMA INNODB_FIELDS 表

28.4.12 INFORMATION_SCHEMA INNODB_FOREIGN 表

28.4.13 INFORMATION_SCHEMA INNODB_FOREIGN_COLS 表

28.4.14 INFORMATION_SCHEMA INNODB_FT_BEING_DELETED 表

28.4.15 INFORMATION_SCHEMA INNODB_FT_CONFIG 表

28.4.16 INFORMATION_SCHEMA INNODB_FT_DEFAULT_STOPWORD 表

28.4.17 INFORMATION_SCHEMA INNODB_FT_DELETED 表

28.4.18 INFORMATION_SCHEMA INNODB_FT_INDEX_CACHE 表

28.4.19 INFORMATION_SCHEMA INNODB_FT_INDEX_TABLE 表

28.4.20 INFORMATION_SCHEMA INNODB_INDEXES 表

28.4.21 INFORMATION_SCHEMA INNODB_METRICS 表

28.4.22 INFORMATION_SCHEMA INNODB_SESSION_TEMP_TABLESPACES 表

28.4.23 INFORMATION_SCHEMA INNODB_TABLES 表

28.4.24 INFORMATION_SCHEMA INNODB_TABLESPACES 表

28.4.25 INFORMATION_SCHEMA INNODB_TABLESPACES_BRIEF 表

28.4.26 INFORMATION_SCHEMA INNODB_TABLESTATS 视图

28.4.27 INFORMATION_SCHEMA INNODB_TEMP_TABLE_INFO 表

28.4.28 INFORMATION_SCHEMA INNODB_TRX 表

28.4.29 INFORMATION_SCHEMA INNODB_VIRTUAL 表

28.5 INFORMATION_SCHEMA 线程池表

28.5.1 INFORMATION_SCHEMA 线程池表参考

28.5.2 INFORMATION_SCHEMA TP_THREAD_GROUP_STATE 表

28.5.3 INFORMATION_SCHEMA TP_THREAD_GROUP_STATS 表

28.5.4 INFORMATION_SCHEMA TP_THREAD_STATE 表

28.6 INFORMATION_SCHEMA 连接控制表

28.6.1 INFORMATION_SCHEMA 连接控制表参考

28.6.2 INFORMATION_SCHEMA CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS 表

28.7 INFORMATION_SCHEMA MySQL 企业防火墙表

28.7.1 INFORMATION_SCHEMA 防火墙表参考

28.7.2 INFORMATION_SCHEMA MYSQL_FIREWALL_USERS 表

28.7.3 INFORMATION_SCHEMA MYSQL_FIREWALL_WHITELIST 表

28.8 SHOW 语句的扩展

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

28.1 介绍

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

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

  • INFORMATION_SCHEMA 使用注意事项

  • 字符集考虑

  • INFORMATION_SCHEMA 作为 SHOW 语句的替代

  • INFORMATION_SCHEMA 和权限

  • 性能考虑

  • 标准考虑

  • INFORMATION_SCHEMA 参考部分中的约定

  • 相关信息

INFORMATION_SCHEMA 使用注意事项

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

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

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

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

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

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

字符集考虑

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

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

INFORMATION_SCHEMA 作为 SHOW 语句的替代

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

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

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

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

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

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

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

INFORMATION_SCHEMA 和权限

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

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

性能考虑

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

标准考虑

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

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

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

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

INFORMATION_SCHEMA 参考部分的约定

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

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

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

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

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

相关信息

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

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

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

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

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

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

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

28.2 INFORMATION_SCHEMA 表参考

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

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

表 28.1 INFORMATION_SCHEMA 表

表名描述引入版本废弃版本
ADMINISTRABLE_ROLE_AUTHORIZATIONS当前用户或角色可授权的用户或角色8.0.19
APPLICABLE_ROLES当前用户适用的角色8.0.19
CHARACTER_SETS可用字符集
CHECK_CONSTRAINTS表和列的检查约束8.0.16
COLLATION_CHARACTER_SET_APPLICABILITY每个排序规则适用的字符集
COLLATIONS每个字符集的排序规则
COLUMN_PRIVILEGES列上定义的权限
COLUMN_STATISTICS列值的直方图统计
COLUMNS每个表中的列
COLUMNS_EXTENSIONS主要和次要存储引擎的列属性8.0.21
CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS每个账户连续失败连接尝试的当前次数
ENABLED_ROLES当前会话中启用的角色8.0.19
ENGINES存储引擎属性
EVENTS事件管理器事件
FILES存储表空间数据的文件
INNODB_BUFFER_PAGEInnoDB 缓冲池中的页面
INNODB_BUFFER_PAGE_LRUInnoDB 缓冲池中页面的 LRU 排序
INNODB_BUFFER_POOL_STATSInnoDB 缓冲池统计信息
INNODB_CACHED_INDEXESInnoDB 缓冲池中每个索引缓存的索引页数
INNODB_CMP与压缩的 InnoDB 表相关的操作状态
INNODB_CMP_PER_INDEX与压缩的 InnoDB 表和索引相关的操作状态
INNODB_CMP_PER_INDEX_RESET与压缩的 InnoDB 表和索引相关的操作状态
INNODB_CMP_RESET与压缩的 InnoDB 表相关的操作状态
INNODB_CMPMEMInnoDB 缓冲池中压缩页面的状态
INNODB_CMPMEM_RESETInnoDB 缓冲池中压缩页面的状态
INNODB_COLUMNS每个 InnoDB 表中的列
INNODB_DATAFILESInnoDB 每表一个文件和通用表空间的数据文件路径信息
INNODB_FIELDSInnoDB 索引的关键列
INNODB_FOREIGNInnoDB 外键元数据
INNODB_FOREIGN_COLSInnoDB 外键列状态信息
INNODB_FT_BEING_DELETEDINNODB_FT_DELETED 表的快照
INNODB_FT_CONFIGInnoDB 表全文索引和相关处理的元数据
INNODB_FT_DEFAULT_STOPWORDInnoDB 全文索引的默认停用词列表
INNODB_FT_DELETED从 InnoDB 表全文索引中删除的行
INNODB_FT_INDEX_CACHEInnoDB 全文索引中新插入行的标记信息
INNODB_FT_INDEX_TABLE用于处理针对 InnoDB 表全文索引的文本搜索的倒排索引信息
INNODB_INDEXESInnoDB 索引元数据
INNODB_METRICSInnoDB 性能信息
INNODB_SESSION_TEMP_TABLESPACES会话临时表空间元数据8.0.13
INNODB_TABLESInnoDB 表元数据
INNODB_TABLESPACESInnoDB 每表文件、通用和撤销表空间元数据
INNODB_TABLESPACES_BRIEF简要的文件、通用、撤销和系统表空间元��据
INNODB_TABLESTATSInnoDB 表低级状态信息
INNODB_TEMP_TABLE_INFO关于活动用户创建的 InnoDB 临时表的信息
INNODB_TRX活动的 InnoDB 事务信息
INNODB_VIRTUALInnoDB 虚拟生成列元数据
KEY_COLUMN_USAGE具有约束的关键列
KEYWORDSMySQL 关键字
MYSQL_FIREWALL_USERS账户配置的防火墙内存数据8.0.26
MYSQL_FIREWALL_WHITELIST账户配置的防火墙内存数据允许列表8.0.26
ndb_transid_mysql_connection_mapNDB 事务信息
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_MEASUREST_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具有约束的关键列
KEYWORDSMySQL 关键词
ndb_transid_mysql_connection_mapNDB 事务信息
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_MEASUREST_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 语句显示的前两列。

avatar
文章
阅读
粉丝