【MySQL内置数据库】 mysql

1	columns_priv	存储列级别的权限信息
2	component
3	db
4	default_roles
5	engine_cost
6	func	用于存储自定义函数
7	general_log	存储一般查询日志
8	global_grants
9	gtid_executed	用于存储全局事务标识符（GTID）
10	help_category
11	help_keyword
12	help_relation
13	help_topic
14	innodb_index_stats	存储了innodb索引的统计信息
15	innodb_table_stats
16	ndb_binlog_index
17	password_history
18	plugin	存储MySQL服务器插件的信息
19	procs_priv
20	proxies_priv
21	replication_asynchronous_connection_failover	用于存储异步连接故障转移的配置信息
22	replication_asynchronous_connection_failover_managed	用于存储异步连接故障转移的配置信息
23	replication_group_configuration_version	用于显示复制组成员操作配置的版本信息
24	replication_group_member_actions	配置和管理组复制成员的动作
25	role_edges
26	server_cost	包含了一般服务器操作的优化器成本估算
27	servers
28	slave_master_info	用于存储slave对master的信息
29	slave_relay_log_info	记录slave的sql线程的位置信息
30	slave_worker_info	记录slave服务器上并行复制工作线程的信息
31	slow_log	存储慢查询日志
32	tables_priv
33	time_zone
34	time_zone_leap_second
35	time_zone_name
36	time_zone_transition
37	time_zone_transition_type
38	user	存储数据库用户的账号信息和权限

columns_priv

columns_priv 表是 MySQL 的系统表之一，位于 mysql 数据库中，用于存储列级别的权限信息。这意味着它可以控制用户对特定表中特定列的访问权限。以下是 columns_priv 表的一些关键字段及其描述：

Host: 记录用户从哪个主机进行连接，通常是一个 IP 地址或者域名。
Db: 数据库的名称。
User: 用户名。
Table_name: 表的名称。
Column_name: 列的名称。
Timestamp: 记录权限被授权或更改的时间戳。
Column_priv: 列权限集合，包括但不限于 SELECT、INSERT、UPDATE 和 REFERENCES 权限。

例如，如果你想要授予用户 username 对数据库 database_name 中的 table_name 表的 column_name 列的 SELECT 权限，你可以使用以下 SQL 命令：

GRANT SELECT (column_name) ON database_name.table_name TO 'username'@'host';

反之，如果你想要撤销这个权限，可以使用 REVOKE 命令：

REVOKE SELECT (column_name) ON database_name.table_name FROM 'username'@'host';

columns_priv 表通常与 db 表和 tables_priv 表一起使用，以实现更细粒度的权限控制。db 表控制数据库级别的权限，而 tables_priv 表控制表级别的权限。当使用 REVOKE 命令时，必须指定与被授权列相同的列名，这是因为列级别的权限是针对单个列的。

要查看 columns_priv 表的内容，你可以使用以下 SQL 查询：

SELECT * FROM mysql.columns_priv WHERE Db = 'database_name' AND Table_name = 'table_name';

这将返回指定数据库和表的所有列权限信息。

component

在MySQL数据库中，"component"一词通常指的是服务器的组件化架构，这是MySQL 8.0版本引入的一个新特性。这种架构允许通过安装和卸载组件来扩展服务器的功能。每个组件都提供服务器和其他组件可以使用的服务。组件之间仅通过它们提供的服务进行交互。

组件可以用于多种用途，例如配置错误日志记录、密码验证、提供安全存储敏感信息的密钥环、将应用程序的消息事件添加到审计日志、实现用于访问查询属性的可加载函数等。

要获取有关当前加载的组件的信息，可以查询mysql.component系统表。例如，以下SQL语句可以列出所有已加载的组件：

SELECT * FROM mysql.component;

此外，组件的安装和卸载可以通过INSTALL COMPONENT和UNINSTALL COMPONENT语句来完成。例如，要安装一个密码验证组件，可以使用以下命令：

INSTALL COMPONENT 'file://component_validate_password';

要卸载该组件，可以使用：

UNINSTALL COMPONENT 'file://component_validate_password';

组件的引入为MySQL数据库提供了更高的灵活性和扩展性，使得用户可以根据自己的需要来定制数据库服务器的功能。

component_id 是该组件的唯一标识符。
component_group_id 可能表示该组件所属的组或类别。
component_urn 是一个统一资源名称（Uniform Resource Name），通常用于标识资源的位置，这里是一个文件路径，可能指向一个用于验证密码的组件或服务。

db

在 MySQL 中，db 表是 mysql 数据库中的一个系统表，它存储了数据库级别的权限信息。这个表允许你查看和管理系统级别的权限，这些权限决定了哪些用户可以从哪些主机访问哪些数据库。

以下是 db 表中的一些关键列：

Host: 指定允许连接的主机名或 IP 地址。使用通配符（如 %）可以表示任意主机。
Db: 数据库的名称，如果数据库名是 %，则表示该权限适用于所有数据库。
User: 用户名，与 Host 列结合使用，以确定特定主机上的特定用户。
Select_priv: 是否允许用户执行 SELECT 语句。
Insert_priv: 是否允许用户执行 INSERT 语句。
Update_priv: 是否允许用户执行 UPDATE 语句。
Delete_priv: 是否允许用户执行 DELETE 语句。
Create_priv: 是否允许用户创建新的数据库和表。
Drop_priv: 是否允许用户删除数据库和表。
Grant_priv: 是否允许用户授予或撤销权限。
References_priv: 是否允许用户创建外键。
Index_priv: 是否允许用户创建或删除索引。
Alter_priv: 是否允许用户修改表结构。
Create_tmp_table_priv: 是否允许用户创建临时表。
Lock_tables_priv: 是否允许用户锁定表。
Create_view_priv: 是否允许用户创建视图。
Show_view_priv: 是否允许用户查看视图的定义。
Create_routine_priv: 是否允许用户创建存储过程和函数。
Alter_routine_priv: 是否允许用户修改存储过程和函数。
Execute_priv: 是否允许用户执行存储过程和函数。

这些权限可以单独设置，以提供精细的访问控制。例如，你可以允许某个用户从特定主机访问特定数据库，但不允许他们创建或删除表。

要查看 db 表中的权限信息，你可以使用以下 SQL 语句：

SELECT * FROM mysql.db WHERE Db = 'your_database_name';

将 your_database_name 替换为你想要查询的数据库名称。这将返回指定数据库的权限信息。

db 表是 MySQL 权限系统的核心组成部分，它与 user 表（全局权限）和 tables_priv 表（表级权限）一起使用，为 MySQL 数据库提供强大的访问控制机制。

default_roles

default_roles 表是 MySQL mysql 数据库中的一个系统表，它用于存储用户账户的默认角色信息。在 MySQL 8.0 及更高版本中，角色（Role）是权限的集合，可以授予用户以简化权限管理。默认角色是在用户登录时自动激活的角色。

以下是 default_roles 表中的一些关键列：

Host: 用户账户的主机部分。
User: 用户账户的用户名。
Default_role: 用户的默认角色名称，可以在登录时自动激活。

默认角色的概念是在 MySQL 8.0 中引入的，它允许管理员为用户设置一组默认激活的角色，这样在用户登录时，这些角色的权限就会自动应用到用户会话中。这有助于简化权限管理，因为管理员可以集中管理角色的权限，而不是单独为每个用户分配权限。

要设置用户的默认角色，可以使用 SET DEFAULT ROLE 语句，例如：

SET DEFAULT ROLE 'role_name' FOR 'user_name'@'host_name';

或者在创建用户或修改用户时使用 ALTER USER 语句：

ALTER USER 'user_name'@'host_name' DEFAULT ROLE 'role_name';

用户登录时，可以通过 CURRENT_ROLE() 函数查看当前会话中激活的角色。如果需要，用户可以在会话中使用 SET ROLE 语句来更改激活的角色列表。

需要注意的是，default_roles 表通常由 MySQL 服务器内部维护，不建议直接修改这个表，而是应该使用 MySQL 提供的账户管理语句来管理角色和权限。

engine_cost

在 MySQL 中，engine_cost 表是 mysql 系统数据库的一部分，它用于存储与特定存储引擎相关的成本常数。这些成本常数代表了不同存储引擎操作的成本，优化器在生成执行计划时会使用这些成本来决定最佳的执行策略。

以下是 engine_cost 表中可能包含的一些关键列：

engine_name: 存储引擎的名称，如 InnoDB。如果值为 default，则表示该成本适用于所有没有特定条目的存储引擎。
device_type: 表示存储设备的类型，目前这个字段的值通常是 0，因为 MySQL 尚未区分不同类型的存储设备（如 HDD 和 SSD）的成本。
cost_name: 成本常数的名称，如 io_block_read_cost。
cost_value: 成本常数的值。如果这个字段的值为 NULL，则表示优化器将使用默认的成本值。
last_update: 最后一次更新成本常数的时间。
comment: 对该成本常数的描述或注释。

engine_cost 表中存储的成本常数包括但不限于：

io_block_read_cost: 从磁盘读取一个块的成本。
memory_block_read_cost: 从内存读取一个块的成本。

管理员可以通过更新 engine_cost 表中的 cost_value 来调整成本常数，以影响优化器的决策。例如，增加 io_block_read_cost 的值可能会使优化器更倾向于使用索引而不是执行全表扫描。

要使对 engine_cost 表的更改生效，需要执行 FLUSH OPTIMIZER_COSTS; 命令，这样优化器就会重新读取成本表并更新其内部的成本估算。

例如，如果你想要增加 InnoDB 存储引擎的磁盘读取成本，可以这样做：

UPDATE mysql.engine_cost
SET cost_value = 2.0
WHERE engine_name = 'InnoDB' AND cost_name = 'io_block_read_cost';
FLUSH OPTIMIZER_COSTS;

请注意，这些更改应该谨慎进行，因为不恰当的成本调整可能会导致优化器生成非最优的执行计划。通常建议在充分测试和监控的基础上进行调整。

func

在 MySQL 中，func 表是 mysql 数据库中的一个系统表，用于存储用户定义的函数（User-Defined Functions，UDF）。这些函数是用 C 或 C++ 编写的，可以被加载到 MySQL 服务器中，以便在 SQL 语句中使用。

以下是 func 表中的一些关键列：

name: 函数的名称。
ret: 函数返回值的类型。
dl: 包含该函数的动态链接库（Dynamic Link Library，DLL）或共享对象（Shared Object，SO）的文件名。
type: 函数的类型，例如 function 或 aggregate（聚合函数）。
flags: 函数的标志，用于指示函数的特性。

用户定义的函数可以用于执行各种操作，如字符串处理、数学计算、数据转换等。这些函数在 SQL 语句中被调用时，会由 MySQL 服务器动态加载并执行。

要创建用户定义的函数，可以使用 CREATE FUNCTION 语句，例如：

CREATE FUNCTION my_add_func RETURNS INTEGER SONAME 'my_udf_library.so';

这个语句创建了一个名为 my_add_func 的函数，它返回一个整数类型的值，并且由 my_udf_library.so 共享库提供实现。

要查看系统中定义的所有用户定义函数，可以查询 func 表：

SELECT * FROM mysql.func;

这将返回所有用户定义函数的详细信息。需要注意的是，创建和删除用户定义函数需要相应的权限。

用户定义函数可以提高 SQL 语句的复用性和灵活性，但同时也需要注意安全性和性能影响，因为它们是服务器端的扩展功能。

general_log

MySQL中的general_log是一个用于记录所有到达MySQL服务器的SQL语句的日志系统。默认情况下，general_log是关闭的，因为它可能会产生大量的日志数据，从而对服务器性能产生影响。当需要对数据库进行故障排查时，可以临时开启general_log。

如何开启和配置general_log:

开启general_log:

- 通过设置系统变量：SET GLOBAL general_log = ON;
- 修改配置文件（如my.cnf或my.ini），在[mysqld]部分添加general_log = 1，然后重启MySQL服务。

设置日志文件路径:

- 通过设置系统变量：SET GLOBAL general_log_file = 'path/to/your/logfile.log';
- 在配置文件中指定日志文件路径。

查看日志状态:

- 使用命令：SHOW VARIABLES LIKE 'general_log%';

日志文件内容:
general_log文件记录了包括客户端连接和断开、执行的SQL语句等信息。每条记录通常包含时间戳、线程ID、服务器ID、命令类型和参数（即完整的SQL语句）。

日志输出位置:

默认情况下，日志文件存储在MySQL数据目录中，文件名为hostname.log，其中hostname是主机名。
可以通过general_log_file变量指定日志文件的名称和路径。

日志存储方式:

log_output变量控制日志的存储方式，可以是FILE或TABLE。默认情况下，日志存储在文件中。
如果设置为TABLE，则日志信息会被写入到mysql.general_log表中。

注意事项:

开启general_log可能会对性能有较大影响，因此建议仅在必要时开启，并在完成后及时关闭。
如果需要清空日志文件，可以关闭日志记录，然后重命名或删除日志文件，并重新开启日志记录。

更多详细信息可以参考MySQL官方文档。

global_grants

global_grants 表是 MySQL mysql 数据库中的一个系统表，用于存储动态全局权限。这些权限是全局的，意味着它们适用于整个 MySQL 服务器的所有数据库。动态权限是在运行时定义的，与静态权限（如 SELECT、INSERT 等）相对。

以下是 global_grants 表中的一些关键列：

USER: 用户名，这里是 root。
HOST: 用户连接的主机名或 IP 地址。% 表示任何主机，localhost 表示本地主机。
PRIV: 授予的动态权限名称，例如 BACKUP_ADMIN、SYSTEM_USER、APPLICATION_PASSWORD_ADMIN 等。
WITH_GRANT_OPTION: 表示是否授予了 GRANT OPTION，即是否允许该用户将权限授予其他用户。Y 表示是，N 表示否。

动态权限通常与特定的 MySQL 功能或组件相关联，例如复制、审计、加密等。它们可以在运行时通过 GRANT 和 REVOKE 语句进行管理。

要查看 global_grants 表中的权限信息，你可以使用以下 SQL 语句：

SELECT * FROM mysql.global_grants;

这将返回所有动态全局权限的列表。需要注意的是，查询这个表通常需要有 PROCESS 权限。

global_grants 表是 MySQL 权限系统的重要组成部分，它允许管理员灵活地控制用户权限，特别是在需要精细控制特定功能或组件的访问时。

gtid_executed

gtid_executed 表是 MySQL mysql 数据库中的一个系统表，用于存储全局事务标识符（GTID）的执行信息。这个表有三个主要字段：

source_uuid: 表示生成这些 GTID 的 MySQL 服务器实例的 UUID。
interval_start: GTID 的开始间隔。
interval_end: GTID 的结束间隔。

这个表在 MySQL 启动阶段会读取，以获取 gtid_executed 变量的值，该变量存储在内存中，用于记录 MySQL 数据库已经执行了哪些 GTID 事务。gtid_executed 变量是实时更新的，无论主库和从库都会更新这个变量。

在 MySQL 5.7 及更高版本中，GTID 事务是唯一标识每个事务的全局标识符，格式为 UUID:NUMBER。例如，服务器 UUID 为 3E11FA47-71CA-11E1-9E33-C80AA9429562 的第一个事务的 GTID 是 3E11FA47-71CA-11E1-9E33-C80AA9429562:1。

gtid_executed 表的作用包括：

确保数据一致性：同一个 GTID 的事务不会在一个服务器上执行两次。
故障恢复：在主从复制中，如果一台服务器宕机，可以通过 GTID 来确定哪些事务需要执行，以保证数据的一致性。
简化复制配置：使用 GTID 复制时，可以通过 CHANGE MASTER TO MASTER_AUTO_POSITION=1 来简化从库的配置。

在 MySQL 8.0 版本中，gtid_executed 表还支持压缩，可以通过 gtid_executed_compression_period 系统变量来控制压缩周期。表中的 GTID 信息会定期被压缩，以节省空间。

要查看 gtid_executed 表中的 GTID 信息，可以使用以下 SQL 语句：

SELECT * FROM mysql.gtid_executed;

这将返回所有已经执行的 GTID 事务的信息。如果需要检查数据一致性，可以比较不同服务器上的 gtid_executed 表的内容，确保它们之间没有数据分叉或冲突。

需要注意的是，gtid_executed 表是 MySQL 服务器内部使用的，通常情况下不需要手动干预或修改。如果需要手动设置 GTID 信息，可以使用 RESET MASTER 或 RESET SLAVE 命令，或者通过设置 gtid_purged 变量来提示 MySQL 服务器哪些 GTID 事务已经执行过了。

更多详细信息可以参考 MySQL 官方文档。

help_category

help_category 表是 MySQL mysql 数据库中的一个系统表，它存储了 MySQL 帮助命令（HELP）使用的帮助主题类别信息。这些类别对应于 MySQL 参考手册中不同的部分，使得用户可以通过 HELP 命令查找相关主题的帮助信息。

以下是 help_category 表中的一些关键字段：

help_category_id: 帮助类别的唯一标识符。
name: 帮助类别的名称，例如 "Data Definition"、"Data Manipulation"、"Functions" 等。
parent_category_id: 父类别的标识符，用于表示类别之间的层级关系。
url: 对应的帮助主题在 MySQL 官方文档中的 URL 地址。

当用户执行 HELP 命令时，MySQL 会搜索这些表以提供相关的帮助信息。例如，用户可以执行 HELP 'functions' 来获取有关 MySQL 函数的相关信息。

这些帮助表在数据库初始化时通过加载 fill_help_tables.sql 文件创建，并且通常在 MySQL 安装过程的一部分执行。如果需要更新帮助表，可以手动加载这个文件。

要查看 help_category 表中的类别信息，可以使用以下 SQL 语句：

SELECT * FROM mysql.help_category;

这将返回所有帮助主题类别的列表。用户可以根据返回的类别名称来进一步查询特定类别下的关键字或主题。

更多详细信息可以参考 MySQL 官方文档。

help_keyword

help_keyword 表是 MySQL mysql 数据库中的一个系统表，它是服务器端帮助系统的一部分。这个表存储了与帮助主题相关的关键字信息，这些关键字用于 HELP 命令在 MySQL 命令行客户端中搜索帮助信息时使用。

以下是 help_keyword 表中的一些关键字段：

help_keyword_id: 帮助关键字的唯一标识符。
name: 关键字的名称，这个名称对应于用户可能搜索的帮助主题的关键字。

当用户在 MySQL 命令行客户端中执行 HELP 命令时，系统会使用这些关键字来搜索相关的帮助主题。例如，用户可以执行 HELP 'SELECT'; 来获取有关 SELECT 语句的帮助信息。

help_keyword 表通常与 help_category、help_relation 和 help_topic 表一起使用，以提供完整的帮助信息检索功能。这些表共同构成了 MySQL 服务器的帮助系统，允许用户快速查找和浏览 MySQL 的各种命令、功能和主题的文档。

要查看 help_keyword 表中的关键字列表，可以使用以下 SQL 语句：

SELECT * FROM mysql.help_keyword;

这将返回所有帮助关键字的列表。需要注意的是，查询这个表通常需要有相应的权限。

更多详细信息可以参考 MySQL 官方文档。

help_relation

help_relation 表是 MySQL mysql 数据库中的一个系统表，它是服务器端帮助系统的一部分。这个表存储了帮助主题（help_topic）和帮助关键字（help_keyword）之间的关系，使得用户可以通过 HELP 命令搜索相关的帮助信息。

以下是 help_relation 表中的一些关键字段：

help_topic_id: 帮助主题的唯一标识符。
help_keyword_id: 与帮助主题相关联的关键字的唯一标识符。

这个表通常与 help_category、help_topic 和 help_keyword 表一起使用，以提供完整的帮助信息检索功能。当用户执行 HELP 命令时，系统会使用这些表来搜索相关的帮助主题和信息。

要查看 help_relation 表中的信息，可以使用以下 SQL 语句：

SELECT * FROM mysql.help_relation;

这将返回所有帮助主题和关键字之间的关系列表。需要注意的是，查询这个表通常需要有相应的权限。

更多详细信息可以参考 MySQL 官方文档。

help_topic

help_topic 表是 MySQL mysql 数据库中的一个系统表，它存储了 MySQL 帮助主题的详细信息。这个表是 MySQL 帮助系统的一部分，包含了关于 MySQL 命令、函数、对象的描述和用法的信息。

以下是 help_topic 表中的一些关键字段：

help_topic_id: 帮助主题的唯一标识符。
name: 帮助主题的名称或标识符。
help_category_id: 帮助主题所属的分类ID。
description: 提供关于帮助主题的简短描述。
help_text: 包含关于帮助主题的详细描述或说明。
example: 提供帮助主题的使用示例。
url: 指向 MySQL 官方文档中相应帮助主题的 URL 地址。

通过查询 help_topic 表，用户可以获取有关 MySQL 各种特性和命令的帮助信息。例如，如果你想获取关于 JOIN 语句的帮助信息，可以使用以下 SQL 查询：

SELECT help_text FROM mysql.help_topic WHERE name = 'JOIN';

这将返回有关 JOIN 语句的详细帮助文本。

help_topic 表通常与 help_category、help_keyword 和 help_relation 表一起使用，以提供完整的帮助信息检索功能。这些表共同构成了 MySQL 的帮助系统，允许用户通过 HELP 命令在 MySQL 命令行客户端中搜索帮助信息。

要查看 help_topic 表中的所有帮助主题，可以使用以下 SQL 语句：

SELECT * FROM mysql.help_topic;

这将返回所有帮助主题的详细信息列表。

更多详细信息可以参考 MySQL 官方文档。

innodb_index_stats

innodb_index_stats 表是 MySQL mysql 数据库中的一个系统表，它存储了 InnoDB 存储引擎索引的统计信息。这些统计信息对于 MySQL 查询优化器来说非常重要，因为它们帮助优化器确定索引对于给定查询计划的有效性。

以下是 innodb_index_stats 表中的一些关键字段：

database_name: 索引所属的数据库名称。
table_name: 索引所属的表名称。
index_name: 索引的名称。
last_update: 最后一次更新统计信息的时间。
stat_name: 统计项的名称，如 n_leaf_pages（叶子页数）、size（索引大小）等。
stat_value: 统计项的值。
sample_size: 用于统计的采样页面数量。
stat_description: 对统计项的描述。

例如，n_diff_pfx01 可能表示某一列的不同前缀数量，n_diff_pfx02 可能表示前两列组合的不同前缀数量。n_leaf_pages 表示索引叶子节点的页数，size 表示索引占用的总页数。

统计信息的准确性对于查询性能至关重要。如果统计信息过时或不准确，优化器可能会做出错误的决策，导致查询性能下降。因此，定期更新统计信息是数据库维护的重要部分。

要查看特定索引的统计信息，可以使用以下 SQL 语句：

SELECT * FROM mysql.innodb_index_stats
WHERE database_name = 'your_database_name' AND table_name = 'your_table_name' AND index_name = 'your_index_name';

将 your_database_name、your_table_name 和 your_index_name 替换为你要查询的数据库名称、表名称和索引名称。

MySQL 提供了 ANALYZE TABLE 命令来手动更新统计信息，也可以通过设置 innodb_stats_auto_recalc 系统变量为 ON 来自动更新统计信息。

更多详细信息可以参考 MySQL 官方文档。

GEN_CLUST_INDEX 是隐藏的主键索引

innodb_table_stats

mysql.innodb_table_stats 是 MySQL 数据库中的一个重要表，它存储了与 InnoDB 存储引擎表统计信息相关的数据。这些统计信息对于 MySQL 的查询优化器（Optimizer）来说至关重要，因为它们帮助优化器决定执行查询时使用哪个索引。

以下是 mysql.innodb_table_stats 表中一些关键字段的说明：

database_name: 数据库名称。
table_name: 表名、分区名或子分区名。
last_update: 一个时间戳，指示该行最后一次更新的时间。
n_rows: 表中的行数。
clustered_index_size: 主索引的大小（以页为单位）。
sum_of_other_index_sizes: 非主索引的总大小（以页为单位）。

这些统计数据可以是持久化的，也可以是非持久化的。持久化统计数据在服务器重启后依然存在，而非持久化统计数据则在服务器关闭时会被清除。系统变量 innodb_stats_persistent 控制是否使用持久化统计数据，默认情况下这个变量是开启的（ON），这意味着统计数据默认会被存储到磁盘上。

统计数据的更新可以通过 ANALYZE TABLE 语句来手动触发，也可以通过系统变量 innodb_stats_auto_recalc 来自动更新。当表中的数据发生变化，且变化的行数超过了表大小的一定比例（默认是10%），MySQL 会自动重新计算统计数据。

此外，mysql.innodb_table_stats 表和 mysql.innodb_index_stats 表可以手动更新，以便在不修改数据库的情况下强制或测试不同的查询优化计划。手动更新统计信息后，需要使用 FLUSH TABLE 语句来加载更新后的统计信息。

需要注意的是，mysql.innodb_table_stats 表不会被复制，即它不参与 MySQL 的复制过程，但它对于查询优化器的性能至关重要。

ndb_binlog_index

mysql.ndb_binlog_index 表是 MySQL NDB Cluster 版本特有的系统表，用于存储 NDB Cluster 复制的二进制日志信息。这个表对于 NDB Cluster 复制机制来说非常重要，因为它提供了关于二进制日志事件的索引数据，这些数据可以用来追踪和定位复制过程中的事件。

以下是 ndb_binlog_index 表的一些关键字段：

Position: 二进制日志中的位置。
File: 二进制日志文件的名称。
epoch: 一个时间戳，表示该条记录的创建时间。
inserts, updates, deletes: 分别表示该日志条目中的插入、更新和删除操作的数量。
schemaops: 模式操作的数量。
orig_server_id: 原始服务器的 ID。
orig_epoch: 原始服务器上事件发生的时代。
gci: 全局事务标识符，用于在复制过程中标识事务。
next_position: 下一个二进制日志事件的位置。
next_file: 下一个二进制日志文件的名称。

这个表通常是由 MySQL 服务器自动维护的，不需要用户手动干预。它使用 InnoDB 存储引擎，并且每个 MySQL 服务器实例上都会有这样一个本地表。在 NDB Cluster 复制中，这个表对于确定副本上最高应用纪元的二进制日志位置非常有用，特别是在多源复制设置中。

在某些情况下，为了提高性能，可能需要对这个表的某些列添加索引，例如 orig_server_id 和 orig_epoch，以便快速查找特定源服务器的事件。这是因为在多源复制环境中，这些列没有索引可能会导致性能问题，因为查询必须执行表扫描来查找相关的二进制日志位置。

此外，ndb_binlog_index 表的大小取决于每个二进制日志文件的纪元数和二进制日志文件的数量。如果 NDB Cluster 非常繁忙，它可能会比安静的集群更频繁地写入二进制日志，并且可能会更快地轮换二进制日志文件。

password_history

mysql.password_history 是 MySQL 8.0 及以上版本中引入的系统表，用于实现密码重用策略。当用户更改密码时，这个表会记录用户之前使用过的密码及其更改时间，以防止用户重复使用旧密码。

以下是 mysql.password_history 表中一些关键字段的说明：

Host: 用户所属的主机。
User: 用户名。
Password_timestamp: 密码更改的时间戳。
Password: 存储的密码哈希值。

通过设置 password_history 系统变量，可以定义用户在设置新密码时不能使用最近多少次更改过的密码。例如，如果 password_history 设置为 5，则用户在更改密码时，不能使用最近 5 次更改过的密码。

此外，还有一个相关的系统变量 password_reuse_interval，它定义了密码重用的时间间隔。如果设置了这个变量，用户在指定的时间内不能重复使用旧密码。

这些功能有助于提高数据库的安全性，通过防止用户重复使用旧密码，可以减少密码被破解的风险。管理员可以通过查看 mysql.password_history 表来审计用户的密码更改历史。

需要注意的是，这些密码策略功能仅适用于使用 MySQL 内置身份验证插件（如 mysql_native_password、sha256_password 或 caching_sha2_password）的帐户。如果帐户使用外部身份验证系统进行身份验证，则密码管理也必须针对该系统在外部进行处理。

plugin

mysql.plugin 是 MySQL 数据库中的一个系统表，用于存储和管理 MySQL 服务器插件的信息。插件可以是存储引擎、身份验证插件或其他类型的服务器扩展。该表在 MySQL 5.7 及更高版本中可用，并且它在 MySQL 安装过程中被创建。

以下是 mysql.plugin 表的一些关键字段：

name: 插件的名称。
dl: 插件库文件的名称，通常是一个 .so 文件（在类 Unix 系统中）或 .dll 文件（在 Windows 系统中）。
load_option: 插件加载选项，例如 FORCE、ON、OFF 等。

该表通常由以下 MySQL 语句管理：

INSTALL PLUGIN: 安装插件并将插件信息注册到 mysql.plugin 表中。
UNINSTALL PLUGIN: 从 mysql.plugin 表中移除插件信息并卸载插件。

mysql.plugin 表不包含内置插件的信息，因为内置插件不需要注册。它只包含通过 INSTALL PLUGIN 语句安装的插件信息。当服务器启动时，它会检查 mysql.plugin 表，并根据表中的内容加载插件。

如果 mysql.plugin 表不存在，可能是因为 MySQL 没有正确安装或初始化，或者该表被意外删除。在这种情况下，可能需要重新安装 MySQL 或修复数据库。

此外，可以通过 SHOW PLUGINS 语句或查询 INFORMATION_SCHEMA.PLUGINS 表来查看服务器上所有插件的信息，包括那些内置插件。

procs_priv

mysql.procs_priv 表用于存储 MySQL 数据库中关于存储过程和存储函数的权限信息。这个表在 MySQL 5.7 及更高版本中可用，并且在 MySQL 实例启动时会将这些权限信息加载到内存中。

以下是 mysql.procs_priv 表中的一些关键字段：

Host: 指出可以执行存储过程的主机。
Db: 指出存储过程所在的数据库。
User: 指出具有执行存储过程权限的用户名。
Routine_name: 存储过程或函数的名称。
Routine_type: 指出是存储过程 (PROCEDURE) 还是函数 (FUNCTION)。
Proc_priv: 指出授予的权限集合，可能包括执行 (Execute)、修改 (Alter Routine) 和授权 (Grant) 等权限。
Timestamp: 记录这条权限记录被修改的时间。
Grantor: 指出授予这些权限的用户。

例如，如果要给用户 'bob'@'localhost' 授予对存储过程 'myproc' 的执行权限，可以在 procs_priv 表中插入一条记录，包含 'localhost'，'bob'，'mydb'（假设存储过程在 'mydb' 数据库中），'myproc'，'PROCEDURE'，以及相应的权限集。

当涉及存储过程和函数的权限请求时，MySQL 服务器会查询 procs_priv 表来验证权限。这个表允许管理员对数据库中的存储过程和函数进行细粒度的权限控制。

proxies_priv

mysql.proxies_priv 表在 MySQL 数据库中用于存储代理用户（Proxy Users）的权限信息。代理用户是一种特殊的用户，它可以代表其他用户执行操作。这种机制可以用于实现类似用户组的管理，即多个用户可以拥有相同的权限集，而不需要为每个用户单独授予权限。

以下是 mysql.proxies_priv 表中的一些关键字段：

Host: 代理用户的主机名。
User: 代理用户的用户名。
Proxied_host: 被代理用户的主机名。
Proxied_user: 被代理的用户名。
With_grant: 一个布尔值，表示代理用户是否有权限将 PROXY 特权授予其他用户。
Grantor: 授予代理权限的用户。
Timestamp: 代理权限记录的更新时间戳。

例如，如果用户 A 想要代理用户 B 执行某些操作，可以在 proxies_priv 表中插入一条记录，指定 Host、User 为 A 的信息，Proxied_host、Proxied_user 为 B 的信息，并且设置 With_grant 来决定 A 是否可以将代理权限授予其他用户。

需要注意的是，proxies_priv 表的 Grantor 和 Timestamp 字段通常不使用。此外，为了使用代理功能，需要在 MySQL 配置中启用 check_proxy_users 变量。

在实际使用中，可以通过 GRANT 语句来授予代理权限，例如：

GRANT PROXY ON 'username'@'host' TO 'proxyuser'@'proxyhost';

这条命令允许 proxyuser@'proxyhost' 代理 username@'host' 的权限。代理用户可以用于数据库的权限管理和审计，以便更灵活地控制用户权限。

replication_asynchronous_connection_failover

mysql.replication_asynchronous_connection_failover 表是在 MySQL 8.0.22 及更高版本中引入的，用于存储异步连接故障转移的配置信息。这个表是与异步复制连接故障转移机制相关联的，该机制允许在从副本到其源的现有连接失败后，自动建立到新源的异步复制连接。

以下是 mysql.replication_asynchronous_connection_failover 表中的一些关键字段：

CHANNEL_NAME: 复制通道的名称。
HOST: 潜在源服务器的主机名。
PORT: 潜在源服务器的端口号。
NETWORK_NAMESPACE: 网络命名空间（当前版本中不使用）。
WEIGHT: 服务器的加权优先级，用于故障转移决策。

当启用异步连接故障转移机制时，如果副本与源服务器的连接失败，MySQL 副本会尝试根据在 mysql.replication_asynchronous_connection_failover 表中设置的加权优先级列表，自动连接到新的源服务器。这个过程是异步的，意味着它不会阻塞副本上的其他操作。

管理员可以使用 asynchronous_connection_failover_add_source 和 asynchronous_connection_failover_delete_source 函数来添加或删除源服务器的配置。此外，对于托管组（如 Group Replication），可以使用 asynchronous_connection_failover_add_managed 和 asynchronous_connection_failover_delete_managed 函数来管理源服务器列表。

此功能要求在源和副本上使用 GTID，并且副本上必须启用 SOURCE_AUTO_POSITION 或 MASTER_AUTO_POSITION 选项，以便 GTID 自动定位用于与源的连接。此外，所有源服务器上必须存在相同的复制用户帐户和密码，该帐户用于连接到每个源。

mysql.replication_asynchronous_connection_failover 表和相关的异步连接故障转移机制为 MySQL 复制提供了更高的可用性和容错能力，特别是在多数据中心的环境中。

replication_asynchronous_connection_failover_managed

mysql.replication_asynchronous_connection_failover_managed 表是在 MySQL 8.0.23 及更高版本中引入的，用于存储异步连接故障转移的配置信息，特别是当副本（replica）需要与组复制（Group Replication）的成员进行同步时。

此表允许管理员定义一个受管理的组，例如一个组复制集群，并且指定该组的成员（MySQL 服务器）在异步复制连接故障转移时如何被对待。表中记录了组复制成员的身份信息和权重，以便在当前源服务器不可用时，副本可以根据这些信息自动选择另一个源服务器进行连接。

关键字段可能包括：

CHANNEL_NAME: 应用故障转移配置的复制通道名称。
MANAGED_TYPE: 管理的类型，目前唯一有效的值是 GroupReplication。
MANAGED_NAME: 管理组的名称，对应于组复制的 group_replication_group_name 系统变量的值。
HOST: 组复制成员的主机名。
PORT: 组复制成员的端口号。
NETWORK_NAMESPACE: 网络命名空间，当前版本中不使用。
PRIMARY_WEIGHT: 主服务器的权重。
SECONDARY_WEIGHT: 辅助服务器的权重。

使用 asynchronous_connection_failover_add_managed 函数可以向此表添加新的受管理组配置，而 asynchronous_connection_failover_delete_managed 函数可以删除现有的配置。

当组复制的成员身份发生变化时，例如有新的成员加入或现有成员离开，副本将自动更新其源列表，以保持与组复制成员的最新状态同步。如果副本与当前源的连接失败，它将根据 PRIMARY_WEIGHT 和 SECONDARY_WEIGHT 字段中定义的权重自动选择新的源进行连接。

这个功能增强了 MySQL 复制的高可用性，尤其是在涉及组复制的场景中。通过自动故障转移，减少了人为干预的需要，并提高了系统的容错能力。

replication_group_configuration_version

mysql.replication_group_configuration_version 表用于显示复制组成员操作配置的版本信息。这个表只有在安装了 Group Replication 时才可用。每当使用 group_replication_enable_member_action() 和 group_replication_disable_member_action() 函数启用或禁用成员操作时，版本号就会递增。如果使用 group_replication_reset_member_actions() 函数重置成员操作配置，将其设置为默认设置，版本号也会重置为1。

replication_group_configuration_version 表包含以下列：

NAME: 配置的名称。
VERSION: 配置的版本号。

这个表没有索引，并且不允许对 replication_group_configuration_version 表执行 TRUNCATE TABLE 操作。

此表用于追踪组复制配置的变更历史，以便于管理员能够了解当前配置的版本状态，从而更好地管理和维护 MySQL 组复制的配置。

replication_group_member_actions

mysql.replication_group_member_actions 表是在 MySQL 8.0.26 及更高版本中引入的，用于配置和管理组复制（Group Replication）成员的动作。这个表允许管理员为组成员在特定情况下设置自动化动作，例如在主节点选举后执行特定的操作。

以下是 mysql.replication_group_member_actions 表中的一些关键字段：

NAME: 成员动作的名称。
EVENT: 触发成员动作的事件。
ENABLED: 表示成员动作当前是否启用。
TYPE: 成员动作的类型，例如 INTERNAL 表示由组复制插件提供的操作。
PRIORITY: 成员动作的优先级，较低的值表示优先级更高，将首先执行。
ERROR_HANDLING: 如果在执行成员动作时发生错误，组复制将采取的操作。例如，IGNORE 表示记录错误消息但不采取进一步操作，而 CRITICAL 表示成员将进入 ERROR 状态，并执行 group_replication_exit_state_action 系统变量指定的操作。

成员动作配置在组内通过组消息传播，因此所有组成员都有相同的成员动作配置。这个配置不会赋予 GTID，也不会写入二进制日志，因此不会传播到组外的服务器。

管理员可以使用 group_replication_enable_member_action() 和 group_replication_disable_member_action() 函数来启用或禁用特定的成员动作。此外，可以使用 group_replication_reset_member_actions() 函数将成员动作配置重置为默认设置。

这个表是组复制管理的重要组成部分，提供了对组成员行为的细粒度控制，有助于实现高可用性和自动化的故障恢复。

role_edges

mysql.role_edges 表是 MySQL 8.0 版本引入的，用于存储角色（Role）之间的关系。在 MySQL 8.0 中，角色是一种新的权限管理方式，可以看作是权限的集合，可以授予用户，以简化权限的管理。角色类似于用户，但是不能用来直接登录数据库。

role_edges 表包含角色之间的层次关系，即哪个角色是另一个角色的成员。这个关系可以是有向的，表示一种继承关系，例如，如果角色 B 被定义为角色 A 的成员，那么拥有角色 A 的用户同时也会拥有角色 B 的权限。

以下是 mysql.role_edges 表中的一些关键字段：

FROM_ROLE: 源角色的名称。
TO_ROLE: 目标角色的名称，源角色是目标角色的成员。

通过这个表，可以方便地查询和维护角色之间的继承关系。例如，可以使用以下 SQL 语句来查看当前数据库中的角色关系：

SELECT * FROM mysql.role_edges;

这将返回角色之间的所有关系，从而可以了解角色的层次结构。

角色管理的一些基本操作包括创建角色、授予角色权限、将角色授予用户、激活角色等。例如，创建角色和授予权限的语句如下：

CREATE ROLE 'read_SC';
GRANT SELECT ON lab2.SC TO 'read_SC';

将角色授予用户：

GRANT 'read_SC' TO 'test';

激活角色：

SET ROLE 'read_SC';

角色功能在 MySQL 8.0 中是一个重要的增强，它提供了一种更加灵活和强大的方式来管理用户权限。通过角色，可以简化权限的分配和撤销，特别是在有多用户需要相同权限的情况下。

server_cost

mysql.server_cost 表是 MySQL 数据库中的一个系统表，它包含了一般服务器操作的优化器成本估算。这些成本估算值被优化器在执行计划构建期间使用，以帮助决定最佳的查询执行策略。表中的非 NULL 值的优先级高于编译好的默认值，如果表中的值为 NULL，则优化器会使用默认的成本估算值。

以下是 mysql.server_cost 表中的一些关键字段：

cost_name: 成本估算的名称，如 disk_temptable_create_cost、disk_temptable_row_cost、key_compare_cost、memory_temptable_create_cost、memory_temptable_row_cost 和 row_evaluate_cost 等。这些名称不区分大小写。
cost_value: 成本估算的值。如果这个值是非 NULL，服务器会使用它作为成本。否则，将使用默认估计值（已编译的值）。管理员可以通过更新此列来更改成本估算。
last_update: 记录最后一次更新的时间。
comment: 与成本估计相关的描述性评论。

例如，disk_temptable_create_cost 的默认值是 40.0，表示在磁盘上创建临时表的成本；memory_temptable_create_cost 的默认值是 2.0，表示在内存中创建临时表的成本。这些值可以由数据库管理员根据系统的实际性能进行调整，以影响优化器的决策。

通过修改这些成本值，可以对 MySQL 的查询优化器进行微调，以适应特定的硬件和使用场景，从而提高查询性能。在修改了 server_cost 表中的值之后，需要执行 FLUSH OPTIMIZER_COSTS 语句来通知服务器重新读取成本表。

servers

mysql.servers 表是在 MySQL 8.0 版本中引入的，用于存储使用 CREATE SERVER 语句创建的服务器定义。这些定义是用于 FEDERATED 存储引擎的，允许你定义远程服务器的连接信息，以便创建 FEDERATED 表，从而允许 MySQL 访问远程 MySQL 服务器上的表。

以下是 mysql.servers 表中的一些关键字段：

Server_name: 服务器定义的唯一名称。
Host: 远程服务器的主机名或 IP 地址。
Db: 远程服务器上的数据库名。
Username: 用于连接远程服务器的用户名。
Password: 用户的密码。
Port: 远程服务器上的端口号（如果未指定，则使用默认 MySQL 端口 3306）。
Socket: 远程服务器上的套接字文件路径。

通过 CREATE SERVER 语句创建的服务器定义会存储在 mysql.servers 表中。当创建 FEDERATED 表时，可以使用这个表中的信息来建立与远程服务器的连接。

例如，创建一个服务器定义的语句可能如下：

CREATE SERVER s FOREIGN DATA WRAPPER mysql
OPTIONS (USER 'Remote', HOST '198.51.100.106', DATABASE 'test');

然后，可以使用存储在 mysql.servers 表中的信息来创建一个 FEDERATED 表：

CREATE TABLE t (
  s1 INT
) ENGINE=FEDERATED CONNECTION='s';

这样，FEDERATED 表 t 就可以通过定义的服务器 s 连接到远程服务器上的 test 数据库。

mysql.servers 表的引入，为 MySQL 提供了一种灵活的方式来访问远程服务器上的表，这对于实现数据的分布式存储和访问非常有用。

slave_master_info

mysql.slave_master_info 表是 MySQL 数据库复制架构中的一个重要系统表，用于存储从服务器（slave）关于其对应的主服务器（master）的信息。这个表的信息通常在执行 CHANGE MASTER TO 命令时被设置，并且在从服务器的 I/O 线程启动时被读取。

以下是 mysql.slave_master_info 表中的一些关键字段：

Number_of_lines: 表中的信息行数。
Master_log_name: 主服务器上当前读取的二进制日志文件的名称。
Master_log_pos: 在上述二进制日志文件中当前读取的位置。
Host: 主服务器的主机名或 IP 地址。
User_name: 用于连接主服务器的复制用户的用户名。
User_password: 复制用户的密码。
Port: 主服务器上的端口号。
Connect_retry: 从服务器 I/O 线程在连接失败后重试连接的间隔时间。
Enabled_ssl: 是否启用了 SSL 加密连接。
Ssl_ca, Ssl_capath, Ssl_cert, Ssl_cipher, Ssl_key: SSL 连接的相关配置。
Heartbeat: 复制心跳包的间隔时间。
Ignored_server_ids: 指定从服务器在复制过程中应该忽略的服务器 ID 列表。
Uuid: 主服务器的 UUID。
Retry_count: 从服务器尝试重新连接主服务器的次数。
Ssl_crl, Ssl_crlpath: SSL 证书撤销列表的配置。
Enabled_auto_position: 是否启用了基于 GTID 的自动位置查找功能。
Channel_name: 复制通道的名称。

这个表的信息对于从服务器正确连接到主服务器并开始复制过程至关重要。表中的信息通常由 MySQL 维护，不应手动修改。如果需要修改复制配置，应使用 CHANGE MASTER TO 命令来更新配置，并由系统自动反映到这个表中。

在 MySQL 复制过程中，mysql.slave_master_info 表与 mysql.slave_relay_log_info 表和 mysql.slave_worker_info 表一起工作，后两个表分别存储了中继日志信息和多线程复制的相关信息。这些表共同支持了 MySQL 的复制功能，确保了数据从一个服务器到另一个服务器的一致性传输。

slave_relay_log_info

mysql.slave_relay_log_info 表在 MySQL 的复制架构中扮演着重要的角色，它用于记录从服务器（slave）的 SQL 线程的位置信息。这个表存储了当前中继日志文件的名称和 SQL 线程读取的位置，以及对应的主服务器（master）的二进制日志文件名称和位置。以下是该表的一些关键信息：

Number_of_lines: 表中的信息行数。
Relay_log_name: 当前正在使用的中继日志文件的名称。
Relay_log_pos: SQL 线程在当前中继日志文件中的位置。
Master_log_name: 对应于当前中继日志事件的主服务器的二进制日志文件的名称。
Master_log_pos: 对应于当前中继日志事件的主服务器的二进制日志文件中的位置。

当从服务器的 SQL 线程执行中继日志中的事件时，它会更新这个表中的信息。如果从服务器意外停止，SQL 线程会根据这个表中记录的位置来恢复，确保数据的一致性。

在 MySQL 5.6 版本之前，复制位点信息通常存储在文件系统中的 relay-log.info 文件中。从 MySQL 5.6 开始，可以设置 relay_log_info_repository 为 TABLE，将这些信息存储在 mysql.slave_relay_log_info 表中，以便使用事务型存储引擎（如 InnoDB）来保证数据的持久性。这样，在从服务器发生故障时，可以更容易地恢复到一个一致的状态。

mysql.slave_relay_log_info 表通常由 MySQL 内部管理，不需要手动编辑。在复制配置中，通常还会涉及到 mysql.slave_master_info 表，它存储了与主服务器相关的连接信息和二进制日志的位置信息。这两个表共同支持了 MySQL 的复制功能，确保了数据从一个服务器到另一个服务器的一致性传输。

slave_worker_info

mysql.slave_worker_info 表是在 MySQL 5.7 版本引入的，用于存储关于从服务器上并行复制工作线程的信息。在 MySQL 复制架构中，当配置了并行复制（也称为多线程复制）时，SQL 线程会被拆分为一个协调器线程和多个工作线程。这些工作线程负责并行执行中继日志中的事件。

以下是 mysql.slave_worker_info 表中的一些关键字段：

Id: 工作线程的唯一标识符。
Relay_log_name: 工作线程当前正在执行的中继日志文件的名称。
Relay_log_pos: 工作线程在当前中继日志文件中的位置。
Master_log_name: 对应于工作线程当前执行的中继日志事件的主服务器的二进制日志文件的名称。
Master_log_pos: 工作线程在对应主服务器二进制日志文件中的位置。
Checkpoint_relay_log_name: 工作线程的检查点中继日志文件的名称。
Checkpoint_relay_log_pos: 工作线程的检查点在中继日志文件中的位置。
Checkpoint_master_log_name: 工作线程的检查点对应的主服务器二进制日志文件的名称。
Checkpoint_master_log_pos: 工作线程的检查点在主服务器二进制日志文件中的位置。
Checkpoint_seqno: 工作线程执行的事务的序列号。
Checkpoint_group_size: 工作线程的执行队列的大小。
Checkpoint_group_bitmap: 表示工作线程已经执行的事务的位图。
Channel_name: 复制通道的名称。

这个表的信息对于监控和故障排除并行复制非常有用。例如，如果从服务器发生故障，mysql.slave_worker_info 表中记录的信息可以帮助确定哪些事务已经被工作线程执行，以及在恢复过程中应该从何处开始重新执行事务。

在正常情况下，这个表是由 MySQL 内部管理的，不需要手动编辑。它为从服务器的并行复制提供了重要的支持，确保了复制过程的高效性和数据的一致性。

slow_log

mysql.slow_log 表是 MySQL 5.6 及更高版本中引入的功能，用于存储慢查询日志。当查询语句的执行时间超过了 long_query_time 指定的阈值，且扫描的行数大于或等于 min_examined_row_limit 时，该查询语句将被记录到慢查询日志中。这个表通常用于分析和优化数据库性能。

以下是 mysql.slow_log 表中的一些关键字段：

start_time: 记录查询开始的时间。
user_host: 执行查询的用户名和主机名。
query_time: 查询执行的时间。
lock_time: 查询执行过程中锁定行的时间。
rows_sent: 查询发送给客户端的行数。
rows_examined: 查询检查的行数。
db: 执行查询的数据库名。
last_insert_id: 查询执行后，最后插入行的ID。
insert_id: 用于插入操作的ID。
server_id: 服务器的唯一ID。
sql_text: 执行的查询语句。

慢查询日志对于数据库管理员来说是非常重要的，因为它可以帮助他们识别和优化那些执行效率低下的查询语句。通过分析慢查询日志，可以发现潜在的性能瓶颈，并采取相应的措施，如添加索引、优化查询语句或调整系统配置。

默认情况下，慢查询日志是禁用的，需要手动开启。可以通过设置 slow_query_log 系统变量为 ON 来启用慢查询日志，并通过 slow_query_log_file 指定日志文件的存放路径。另外，可以通过 log_output 变量设置慢查询日志的输出位置，可以是 FILE 或 TABLE，或者两者兼有。

MySQL 还提供了 mysqldumpslow 工具来分析慢查询日志文件，它可以按不同的标准汇总和排序慢查询日志内容，从而帮助快速定位性能问题。

在某些情况下，可能希望清空慢查询日志，以释放空间或重新开始收集数据。如果是存储在表中，可以重命名旧表并创建一个新表来继续收集慢查询日志。

慢查询日志是数据库性能调优的重要工具之一，合理使用可以显著提高数据库的响应速度和整体性能。

tables_priv

mysql.tables_priv 表是 MySQL 数据库中的一个系统表，用于存储数据库表级别的权限信息。这个表允许数据库管理员对用户访问特定表的权限进行细粒度的控制。

以下是 mysql.tables_priv 表中的一些关键字段：

Host: 指出允许访问表的主机名或 IP 地址。
Db: 指出数据库名。
User: 指出用户名。
Table_name: 指出表名。
Grantor: 指出授予权限的用户。
Timestamp: 记录权限被修改的时间戳。
Table_priv: 指出授予的表级权限集合，可能包括 SELECT、INSERT、UPDATE、DELETE、CREATE、DROP、GRANT、REFERENCES、INDEX、ALTER、CREATE VIEW、SHOW VIEW、TRIGGER 等权限。
Column_priv: 指出授予的列级权限集合，可能包括 SELECT、INSERT、UPDATE、REFERENCES 等权限。

通过 GRANT 和 REVOKE 语句可以修改这个表中的权限信息。例如，可以通过以下 SQL 语句给用户授予对特定表的 SELECT 权限：

GRANT SELECT ON database_name.table_name TO 'username'@'hostname';

这个表的信息通常由 MySQL 的授权管理过程自动维护，不需要手动编辑。它为数据库管理员提供了一个强大的工具，以确保数据的安全性和适当的访问控制。

time_zone

mysql.time_zone 表是 MySQL 数据库中用于存储时区信息的系统表之一。它通常与 mysql.time_zone_name、mysql.time_zone_transitions 和 mysql.time_zone_leap_second 表一起使用，以提供关于时区的完整信息。

以下是 mysql.time_zone 表的一些关键字段：

Time_zone_id: 时区的唯一标识符。
Use_leap_seconds: 一个枚举值，表示该时区是否使用闰秒（'Y' 表示使用，'N' 表示不使用）。

这个表通常在系统安装 MySQL 时自动填充，或者可以通过使用 mysql_tzinfo_to_sql 工具从操作系统的时区数据库（如 /usr/share/zoneinfo）导入时区信息来填充。

在 MySQL 中，时区信息对于处理时间相关的函数和存储时间类型的数据（如 TIMESTAMP 和 DATETIME）至关重要。例如，NOW()、CURTIME() 等函数返回的值会根据当前会话的时区设置进行调整。

默认情况下，mysql.time_zone 表可能不包含任何记录，您可以通过 mysql_tzinfo_to_sql 工具添加时区信息。此外，还可以使用 SET time_zone 命令在运行时设置会话或全局时区。

值得注意的是，如果您的系统不支持时区，或者您需要确保 MySQL 与其他应用程序在时区处理上保持一致，可能需要手动填充这些时区表。您可以从 MySQL 官方网站下载时区表的 SQL 文件，并将其导入到数据库中。

在处理时区问题时，建议明确设置时区（例如 '+08:00' 或 'Asia/Shanghai'），避免使用 'SYSTEM' 选项，因为这可能会导致时区计算依赖于操作系统设置，从而可能引入错误或性能问题。

time_zone_leap_second

mysql.time_zone_leap_second 表是 MySQL 系统表之一，用于存储时区信息中涉及闰秒的数据。闰秒是用于调整地球自转速度变化的一种时间校正，通常在有必要的时候添加到协调世界时（UTC）中。这个表通常在系统安装 MySQL 时自动创建，但默认是空的，因为大多数情况下系统时区可以处理闰秒问题。

在 mysql.time_zone_leap_second 表中，包含以下字段：

Transition_time: 表示闰秒添加的时刻，用时间戳表示。
Correction: 表示闰秒的修正值，通常是 +1 或 -1 秒。

这个表在使用时通常与其他时区相关的表一起使用，例如 mysql.time_zone_name、mysql.time_zone、mysql.time_zone_transition 和 mysql.time_zone_transition_type 表，以提供完整的时区信息。如果需要考虑闰秒，可以使用 mysql_tzinfo_to_sql 工具来填充这个表。

在 MariaDB 10.4 及更高版本中，mysql.time_zone_leap_second 表使用 Aria 存储引擎。而在 MariaDB 10.3 及之前的版本中，使用的是 MyISAM 存储引擎。

需要注意的是，如果系统没有自己的时区信息数据库（例如 Windows），可以使用包含 SQL 语句的包来填充时区表，这些包可以从 MySQL 官方网站下载。如果系统有自己的时区数据库，则应使用 mysql_tzinfo_to_sql 工具来加载时区表，以避免 MySQL 与其他应用程序在日期时间处理上存在差异。

time_zone_name

mysql.time_zone_name 表是 MySQL 数据库中用于存储时区名称和时区 ID 的映射关系的系统表。这个表通常与 mysql.time_zone、mysql.time_zone_transitions 和 mysql.time_zone_leap_second 表一起使用，以提供完整的时区信息。

以下是 mysql.time_zone_name 表中的字段：

Name: 时区的名称，例如 "America/New_York" 或 "Asia/Shanghai"。这个名称对应于 time_zone 系统变量的有效值之一。
Time_zone_id: 关联的时区 ID，这个 ID 用于在其他时区相关的表中引用特定的时区。

默认情况下，mysql.time_zone_name 表可能是空的，因为它依赖于系统时区数据库或手动导入的时区数据。如果需要，可以使用 mysql_tzinfo_to_sql 工具从操作系统的时区数据库填充这个表。

填充时区表后，MySQL 能够正确处理与时区相关的函数和存储时间类型的数据。这对于确保跨时区的应用程序能够正确地存储和显示时间至关重要。

time_zone_transition

mysql.time_zone_transition 表是 MySQL 数据库中的一个系统表，用于记录时区转换信息。这个表通常与 mysql.time_zone_name、mysql.time_zone、mysql.time_zone_transition_type 和 mysql.time_zone_leap_second 表一起使用，以提供完整的时区信息。

以下是 mysql.time_zone_transition 表中的字段：

Time_zone_id: 时区的唯一标识符，与 mysql.time_zone_name 表中的 Time_zone_id 字段相对应。
Transition_time: 时区转换的时间点，通常表示为 Unix 时间戳（格林威治标准时间）。
Transition_type_id: 时区转换类型的 ID，与 mysql.time_zone_transition_type 表中的 Transition_type_id 字段相对应。

这个表的信息对于处理历史时区变化和夏令时转换非常重要，它确保了时间相关的查询可以正确地考虑这些变化。默认情况下，这个表可能不包含任何记录，需要通过 mysql_tzinfo_to_sql 工具从操作系统的时区数据库导入时区信息来填充。

例如，你可以使用以下 SQL 语句查询 mysql.time_zone_transition 表：

SELECT * FROM mysql.time_zone_transition;

这将返回时区转换的记录，包括时区 ID、转换时间和转换类型 ID。

mysql.time_zone_transition 表使用 Aria 存储引擎，并且在 MySQL 8.0 版本中引入。这个表对于确保跨时区的应用程序能够正确地存储和显示时间至关重要。

time_zone_transition_type

mysql.time_zone_transition_type 表是 MySQL 系统表之一，用于存储时区转换类型的详细信息。这个表通常与 mysql.time_zone_name、mysql.time_zone、mysql.time_zone_transitions 和 mysql.time_zone_leap_second 表一起使用，以提供完整的时区信息。

以下是 mysql.time_zone_transition_type 表中的字段：

Time_zone_id: 时区的唯一标识符，与 mysql.time_zone_name 表中的 Time_zone_id 字段相对应。
Transition_type_id: 时区转换类型的唯一标识符。
Offset: 时区相对于协调世界时（UTC）的偏移量，单位为秒。
Is_DST: 表示当前时区是否为夏令时的标识，通常 1 表示是夏令时，0 表示不是。
Abbreviation: 时区的缩写，例如 "EST" 代表东部标准时间，"PST" 代表太平洋标准时间。

例如，你可以使用以下 SQL 语句查询 mysql.time_zone_transition_type 表：

SELECT * FROM mysql.time_zone_transition_type;

这将返回时区转换类型的记录，包括时区 ID、转换类型 ID、偏移量、是否为夏令时以及时区缩写。

mysql.time_zone_transition_type 表使用 Aria 存储引擎，并且在 MySQL 8.0 版本中引入。这个表对于确保跨时区的应用程序能够正确地存储和显示时间至关重要。

user

mysql.user 表是 MySQL 数据库中非常重要的系统表，它存储了数据库用户的账户信息和权限。这个表中的信息决定了哪些用户可以连接到 MySQL 服务器，以及他们可以执行哪些操作。

以下是 mysql.user 表中的一些关键字段：

Host: 用户所在的主机。MySQL 使用这个字段来限制只有来自特定主机的用户才能连接到服务器。这个字段可以是具体的主机名，如 localhost，或者是一个 IP 地址，或者是使用通配符的模式，如 % 表示任何主机。
User: 用户名，用于登录 MySQL 服务器的标识符。
authentication_string: 存储用户密码的字段。在 MySQL 5.7.6 之前的版本中，密码通常以明文或加密形式存储在 Password 字段中。从 MySQL 5.7.6 开始，推荐使用 authentication_string 字段存储密码，它支持更安全的身份验证插件和方法。
Password: 在旧版本中用于存储密码的字段。从安全角度考虑，现在建议使用 authentication_string 字段。
Select_priv: 是否允许用户执行 SELECT 语句。
Insert_priv: 是否允许用户执行 INSERT 语句。
Update_priv: 是否允许用户执行 UPDATE 语句。
Delete_priv: 是否允许用户执行 DELETE 语句。
Create_priv: 是否允许用户创建新数据库和表。
Drop_priv: 是否允许用户删除数据库和表。
Grant_priv: 是否允许用户授予或撤销其他用户的权限。
References_priv: 是否允许用户创建外键。
Index_priv: 是否允许用户创建或删除索引。
Alter_priv: 是否允许用户修改表结构。
Create_tmp_table_priv: 是否允许用户创建临时表。
Lock_tables_priv: 是否允许用户锁定表。
Create_view_priv: 是否允许用户创建视图。
Show_view_priv: 是否允许用户查看视图定义。
Create_routine_priv: 是否允许用户创建存储过程和函数。
Alter_routine_priv: 是否允许用户修改存储过程和函数。
Execute_priv: 是否允许用户执行存储过程和函数。

这些字段中的权限可以单独设置，也可以通过 GRANT 和 REVOKE 语句来修改。mysql.user 表中的信息通常由 MySQL 的授权管理过程自动维护，不需要手动编辑。

管理员可以使用 CREATE USER、GRANT、REVOKE、SET PASSWORD 等语句来管理用户权限。例如，创建一个新用户并授予权限的语句可能如下：

CREATE USER 'newuser'@'localhost' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON database_name.* TO 'newuser'@'localhost';

这将创建一个新用户 newuser，并授予他们对 database_name 数据库中所有表的所有权限。

mysql.user 表是 MySQL 权限系统的核心，确保了数据库的安全性和适当的访问控制。

周杰伦的稻香

关注

10
点赞
踩
24

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫

专栏目录