MySQL8 中文参考(二十)(1)https://developer.aliyun.com/article/1566105
授权系统表
这些系统表包含有关用户帐户和其持有的权限的授权信息。有关这些表的结构、内容和目的的其他信息,请参见第 8.2.3 节,“授权表”。
从 MySQL 8.0 开始,授权表是InnoDB
(事务性)表。以前,这些是MyISAM
(非事务性)表。授权表存储引擎的更改伴随着 MySQL 8.0 中帐户管理语句行为的变化,例如CREATE USER
和GRANT
。以前,命名多个用户的帐户管理语句可能对某些用户成功,对其他用户失败。这些语句现在是事务性的,如果发生任何错误,则对所有命名用户成功或回滚并且不产生任何效果。
注意
如果 MySQL 从旧版本升级,但授权表未从MyISAM
升级到InnoDB
,服务器会将其视为只读,并且帐户管理语句会产生错误。有关升级说明,请参见第三章,升级 MySQL。
user
: 用户账户、全局权限和其他非权限列。global_grants
: 将动态全局权限分配给用户;请参见静态权限与动态权限。db
: 数据库级别的权限。tables_priv
: 表级别的权限。columns_priv
: 列级别的权限。procs_priv
: 存储过程和函数权限。proxies_priv
: 代理用户权限。default_roles
: 此表列出了用户连接和认证后要激活的默认角色,或执行SET ROLE DEFAULT
。role_edges
: 此表列出了角色子图的边缘。
给定的user
表行可能指向用户帐户或角色。服务器可以通过查询role_edges
表来区分行是表示用户帐户、角色还是两者之间的关系的信息。password_history
: 关于密码更改的信息。
对象信息系统表
这些系统表包含有关组件、可加载函数和服务器端插件的信息:
component
: 使用INSTALL COMPONENT
安装的服务器组件的注册表。在此表中列出的任何组件都将由加载程序在服务器启动序列期间安装。请参见第 7.5.1 节,“安装和卸载组件”。func
: 通过CREATE FUNCTION
安装的可加载函数的注册表。在正常启动序列期间,服务器会加载在此表中注册的函数。如果服务器使用--skip-grant-tables
选项启动,则表中注册的函数不会被加载,也无法使用。参见 Section 7.7.1, “Installing and Uninstalling Loadable Functions”。
注意
类似于mysql.func
系统表,性能模式user_defined_functions
表列出使用CREATE FUNCTION
安装的可加载函数。与mysql.func
表不同,user_defined_functions
表还列出了由服务器组件或插件自动安装的函数。这种差异使得user_defined_functions
比mysql.func
更适合用于检查已安装的函数。参见 Section 29.12.21.10, “The user_defined_functions Table”。plugin
: 通过INSTALL PLUGIN
安装的服务器端插件的注册表。在正常启动序列期间,服务器会加载在此表中注册的插件。如果服务器使用--skip-grant-tables
选项启动,则表中注册的插件不会被加载,也无法使用。参见 Section 7.6.1, “Installing and Uninstalling Plugins”。
日志系统表
服务器使用这些系统表进行日志记录:
general_log
: 一般查询日志表。slow_log
: 慢查询日志表。
日志表使用CSV
存储引擎。
更多信息,请参见 Section 7.4, “MySQL Server Logs”。
服务器端帮助系统表
这些系统表包含服务器端帮助信息:
help_category
: 关于帮助类别的信息。help_keyword
: 与帮助主题相关联的关键词。help_relation
: 帮助关键词和主题之间的映射。help_topic
: 帮助主题内容。
更多信息,请参见 Section 7.1.17, “Server-Side Help Support”。
时区系统表
这些系统表包含时区信息:
time_zone
: 时区 ID 以及它们是否使用闰秒。time_zone_leap_second
: 当闰秒发生时。time_zone_name
: 时区 ID 和名称之间的映射。time_zone_transition
,time_zone_transition_type
: 时区描述。
更多信息,请参阅第 7.1.15 节,“MySQL 服务器时区支持”。
复制系统表
服务器使用这些系统表来支持复制:
gtid_executed
: 用于存储 GTID 值的表。请参阅 mysql.gtid_executed 表。ndb_binlog_index
: NDB 集群复制的二进制日志信息。只有在服务器构建时使用NDBCLUSTER
支持时才会创建此表。请参阅第 25.7.4 节,“NDB 集群复制模式和表”。slave_master_info
,slave_relay_log_info
,slave_worker_info
: 用于在副本服务器上存储复制信息。请参阅第 19.2.4 节,“中继日志和复制元数据存储库”。
所有列出的表格都使用InnoDB
存储引擎。
优化器系统表
这些系统表供优化器使用:
innodb_index_stats
,innodb_table_stats
: 用于InnoDB
持久性优化器统计信息。请参阅第 17.8.10.1 节,“配置持久性优化器统计参数”。server_cost
,engine_cost
: 优化器成本模型使用包含有关查询执行过程中发生的操作的成本估算信息的表格。server_cost
包含一般服务器操作的优化器成本估算。engine_cost
包含特定存储引擎的操作的估算。请参阅第 10.9.5 节,“优化器成本模型”。
其他系统表
其他系统表不适用于前述类别:
audit_log_filter
,audit_log_user
: 如果安装了 MySQL 企业审计,这些表提供审计日志过滤器定义和用户帐户的持久性存储。请参阅审计日志表。firewall_group_allowlist
,firewall_groups
,firewall_memebership
,firewall_users
,firewall_whitelist
: 如果安装了 MySQL 企业防火墙,这些表提供防火墙使用的信息的持久性存储。请参阅第 8.4.7 节,“MySQL 企业防火墙”。servers
: 用于FEDERATED
存储引擎。参见 Section 18.8.2.2, “使用 CREATE SERVER 创建 FEDERATED 表”。innodb_dynamic_metadata
: 由InnoDB
存储引擎使用,用于存储快速变化的表元数据,如自增计数器值和索引树损坏标志。取代了存放在InnoDB
系统表空间中的数据字典缓冲表。
7.4 MySQL 服务器日志
7.4.1 选择通用查询日志和慢查询日志输出目的地
7.4.2 错误日志
7.4.3 通用查询日志
7.4.4 二进制日志
7.4.5 慢查询日志
7.4.6 服务器日志维护
MySQL 服务器有几个日志可以帮助您查找正在发生的活动。
日志类型 | 写入日志的信息 |
错误日志 | 启动、运行或停止时遇到的问题mysqld |
通用查询日志 | 来自客户端的已建立的客户端连接和语句 |
二进制日志 | 更改数据的语句(也用于复制) |
中继日志 | 来自复制源服务器的数据更改 |
慢查询日志 | 执行时间超过long_query_time 秒的查询 |
DDL 日志(元数据日志) | 由 DDL 语句执行的元数据操作 |
默认情况下,除了 Windows 上的错误日志之外,没有启用任何日志。(DDL 日志在需要时始终创建,并且没有用户可配置的选项;请参阅 DDL 日志。)以下特定于日志的部分提供有关启用日志记录的服务器选项的信息。
默认情况下,服务器在数据目录中为所有启用的日志编写文件。您可以通过刷新日志来强制服务器关闭并重新打开日志文件(或在某些情况下切换到新的日志文件)。当您发出FLUSH LOGS
语句时,日志刷新会发生;使用flush-logs
或refresh
参数执行mysqladmin;或使用--flush-logs
或--master-data
选项执行mysqldump。请参阅 Section 15.7.8.3, “FLUSH Statement”,Section 6.5.2, “mysqladmin — A MySQL Server Administration Program”和 Section 6.5.4, “mysqldump — A Database Backup Program”。此外,当二进制日志的大小达到max_binlog_size
系统变量的值时,二进制日志会被刷新。
您可以在运行时控制一般查询和慢查询日志。您可以启用或禁用日志记录,或更改日志文件名。您可以告诉服务器将一般查询和慢查询条目写入日志表、日志文件或两者。有关详细信息,请参阅第 7.4.1 节,“选择一般查询日志和慢查询日志输出目的地”,第 7.4.3 节,“一般查询日志”和第 7.4.5 节,“慢查询日志”。
中继日志仅在副本上使用,用于保存来自复制源服务器的数据更改,这些更改也必须在副本上进行。有关中继日志内容和配置的讨论,请参阅第 19.2.4.1 节,“中继日志”。
有关日志维护操作(如旧日志文件的过期)的信息,请参阅第 7.4.6 节,“服务器日志维护”。
关于保护日志安全的信息,请参阅第 8.1.2.3 节,“密码和日志记录”。
7.4.1 选择一般查询日志和慢查询日志输出目的地
MySQL 服务器可以灵活控制写入一般查询日志和慢查询日志的输出目的地,如果这些日志已启用。日志条目的可能目的地是日志文件或mysql
系统数据库中的general_log
和slow_log
表。可以选择文件输出、表输出或两者。
- 服务器启动时的日志控制
- 运行时的日志控制
- 日志表的优势和特点
服务器启动时的日志控制
log_output
系统变量指定日志输出的目的地。设置此变量本身不会启用日志;它们必须单独启用。
- 如果在启动时未指定
log_output
,则默认的日志记录目的地是FILE
。 - 如果在启动时指定了
log_output
,其值是从TABLE
(记录到表)、FILE
(记录到文件)或NONE
(不记录到表或文件)中选择的一个或多个逗号分隔的单词列表。如果存在NONE
,则优先于任何其他指定项。
general_log
系统变量控制所选日志目的地的一般查询日志的记录。如果在服务器启动时指定,general_log
接受一个可选参数 1 或 0 来启用或禁用日志。要为文件记录指定除默认文件名以外的文件名,请设置general_log_file
变量。类似地,slow_query_log
变量控制所选目的地的慢查询日志的记录,并设置slow_query_log_file
指定文件记录的文件名。如果启用了任一日志,则服务器会打开相应的日志文件并将启动消息写入其中。但是,除非选择了FILE
日志目的地,否则不会进一步记录查询到文件中。
示例:
- 要将一般查询日志条目写入日志表和日志文件,请使用
--log_output=TABLE,FILE
选择两个日志目的地,并使用--general_log
启用一般查询日志。 - 仅将一般和慢查询日志条目写入日志表,使用
--log_output=TABLE
选择表格作为日志目的地,并使用--general_log
和--slow_query_log
启用两个日志。 - 仅将慢查询日志条目写入日志文件,使用
--log_output=FILE
选择文件作为日志目的地,并使用--slow_query_log
启用慢查询日志。在这种情况下,因为默认的日志目的地是FILE
,您可以省略log_output
设置。
运行时日志控制
与日志表和文件相关的系统变量使得可以在运行时控制日志记录:
log_output
变量指示当前的日志输出目的地。可以在运行时修改以更改目的地。general_log
和slow_query_log
变量指示一般查询日志和慢查询日志是否已启用(ON
)或已禁用(OFF
)。您可以在运行时设置这些变量以控制日志是否已启用。general_log_file
和slow_query_log_file
变量指示一般查询日志和慢查询日志文件的名称。您可以在服务器启动时或在运行时设置这些变量以更改日志文件的名称。- 要为当前会话禁用或启用一般查询日志记录,请将会话
sql_log_off
变量设置为ON
或OFF
。(假设一般查询日志本身已启用。)
日志表的优点和特点
使用表格进行日志输出具有以下优点:
- 日志条目具有标准格式。要显示日志表的当前结构,请使用以下语句:
SHOW CREATE TABLE mysql.general_log; SHOW CREATE TABLE mysql.slow_log;
- 日志内容可通过 SQL 语句访问。这使得可以使用仅选择满足特定条件的日志条目的查询。例如,要选择与特定客户关联的日志内容(这对于识别来自该客户的问题查询很有用),使用日志表比使用日志文件更容易。
- 日志可通过任何能连接到服务器并发出查询的客户端远程访问(如果客户端具有适当的日志表权限)。无需登录到服务器主机并直接访问文件系统。
日志表实现具有以下特点:
- 一般来说,日志表的主要目的是为用户提供一个接口来观察服务器的运行时执行情况,而不是干预其运行时执行。
CREATE TABLE
、ALTER TABLE
和DROP TABLE
是对日志表的有效操作。对于ALTER TABLE
和DROP TABLE
,日志表不能在使用中,必须被禁用,如后面所述。- 默认情况下,日志表使用将数据以逗号分隔值格式写入的
CSV
存储引擎。对于可以访问包含日志表数据的.CSV
文件的用户,这些文件易于导入到其他程序中,如可以处理 CSV 输入的电子表格程序。
可以修改日志表以使用MyISAM
存储引擎。不能使用ALTER TABLE
来修改正在使用的日志表。必须先禁用日志。日志表只能使用CSV
或MyISAM
引擎,其他引擎不合法。
日志表和“打开文件过多”错误。 如果将TABLE
作为日志目的地,并且日志表使用CSV
存储引擎,您可能会发现在运行时反复禁用和启用常规查询日志或慢查询日志会导致.CSV
文件的打开文件描述符数量增加,可能导致“打开文件过多”错误。为解决此问题,执行FLUSH TABLES
或确保open_files_limit
的值大于table_open_cache_instances
的值。 - 要禁用日志记录以便修改(或删除)日志表,可以使用以下策略。示例使用常规查询日志;慢查询日志的过程类似,但使用
slow_log
表和slow_query_log
系统变量。
SET @old_log_state = @@GLOBAL.general_log; SET GLOBAL general_log = 'OFF'; ALTER TABLE mysql.general_log ENGINE = MyISAM; SET GLOBAL general_log = @old_log_state;
TRUNCATE TABLE
是对日志表的有效操作。可用于清除日志条目。RENAME TABLE
是对日志表的有效操作。可以使用以下策略来原子地重命名日志表(例如执行日志轮换):
USE mysql; DROP TABLE IF EXISTS general_log2; CREATE TABLE general_log2 LIKE general_log; RENAME TABLE general_log TO general_log_backup, general_log2 TO general_log;
CHECK TABLE
是对日志表的有效操作。LOCK TABLES
不能用于日志表。INSERT
、DELETE
和UPDATE
不能用于日志表。这些操作仅在服务器内部允许。FLUSH TABLES WITH READ LOCK
和read_only
系统变量的状态对日志表没有影响。服务器始终可以写入日志表。- 写入日志表的条目不会写入二进制日志,因此不会被复制到副本。
- 要刷新日志表或日志文件,请分别使用
FLUSH TABLES
或FLUSH LOGS
。 - 不允许对日志表进行分区。
- mysqldump转储包括重新创建这些表的语句,以便在重新加载转储文件后它们不会丢失。日志表内容不会被转储。
7.4.2 错误日志
7.4.2.1 错误日志配置
7.4.2.2 默认错误日志目标配置
7.4.2.3 错误事件字段
7.4.2.4 错误日志过滤类型
7.4.2.5 基于优先级的错误日志过滤 (log_filter_internal)
7.4.2.6 基于规则的错误日志过滤 (log_filter_dragnet)
7.4.2.7 以 JSON 格式记录错误日志
7.4.2.8 记录错误日志到系统日志
7.4.2.9 错误日志输出格式
7.4.2.10 错误日志文件刷新和重命名
本节讨论如何配置 MySQL 服务器以将诊断消息记录到错误日志中。有关选择错误消息字符集和语言的信息,请参见 Section 12.6, “Error Message Character Set”,以及 Section 12.12, “Setting the Error Message Language”。
错误日志包含mysqld启动和关闭时间的记录。它还包含在服务器启动和关闭期间以及服务器运行时发生的错误、警告和注释的诊断消息。例如,如果mysqld注意到需要自动检查或修复表,它会向错误日志写入一条消息。
根据错误日志配置,错误消息也可能填充到性能模式error_log
表中,以提供对日志的 SQL 接口,并使其内容可以被查询。参见 Section 29.12.21.2, “The error_log Table”。
在某些操作系统上,如果mysqld异常退出,错误日志中会包含堆栈跟踪。该跟踪可用于确定mysqld退出的位置。参见 Section 7.9, “Debugging MySQL”。
如果用于启动mysqld,mysqld_safe可能会向错误日志写入消息。例如,当mysqld_safe注意到异常的mysqld退出时,它会重新启动mysqld并向错误日志写入mysqld restarted
消息。
以下部分讨论配置错误日志的方面。
原文:
dev.mysql.com/doc/refman/8.0/en/error-log-configuration.html
7.4.2.1 错误日志配置
在 MySQL 8.0 中,错误日志记录使用了在第 7.5 节,“MySQL 组件”中描述的 MySQL 组件架构。错误日志子系统由执行日志事件过滤和写入的组件以及配置哪些组件加载和启用以实现所需日志记录结果的系统变量组成。
本节讨论了如何加载和启用错误日志记录的组件。有关特定于日志过滤器的说明,请参阅第 7.4.2.4 节,“错误日志过滤类型”。有关特定于 JSON 和系统日志接收器的说明,请参阅第 7.4.2.7 节,“以 JSON 格式记录错误日志”和第 7.4.2.8 节,“将错误日志记录到系统日志”。有关所有可用日志组件的更多详细信息,请参阅第 7.5.3 节,“错误日志组件”。
基于组件的错误日志记录提供了以下功能:
- 可由过滤组件过滤的日志事件,以影响可用于写入的信息。
- 由接收器(写入器)组件输出的日志事件。可以启用多个接收器组件,将错误日志输出写入多个目的地。
- 实现默认错误日志格式的内置过滤器和接收器组件。
- 一个可加载的接收器,可启用以 JSON 格式记录日志。
- 一个可加载的接收器,可启用将日志记录到系统日志中。
- 控制加载和启用哪些日志组件以及每个组件如何运行的系统变量。
错误日志配置在本节中描述如下主题:
- 默认错误日志配置
- 错误日志配置方法
- 隐式错误日志配置
- 显式错误日志配置
- 更改错误日志配置方法
- 故障排除配置问题
- 配置多个日志接收器
- 日志汇流性能模式支持
默认错误日志配置
log_error_services
系统变量控制要加载的可加载日志组件(从 MySQL 8.0.30 开始)以及要为错误日志记录启用的日志组件。默认情况下,log_error_services
具有以下值:
mysql> SELECT @@GLOBAL.log_error_services; +----------------------------------------+ | @@GLOBAL.log_error_services | +----------------------------------------+ | log_filter_internal; log_sink_internal | +----------------------------------------+
该值表示日志事件首先通过log_filter_internal
过滤组件,然后通过log_sink_internal
汇流组件,这两个都是内置组件。过滤器修改后续命名的组件看到的日志事件。汇流是日志事件的目的地。通常,汇流将日志事件处理为具有特定格式的日志消息,并将这些消息写入其关联的输出,例如文件或系统日志。
log_filter_internal
和log_sink_internal
的组合实现了默认的错误日志过滤和输出行为。这些组件的操作受其他服务器选项和系统变量的影响:
- 输出目的地由
--log-error
选项确定(在 Windows 上,还有--pid-file
和--console
)。这些选项确定是否将错误消息写入控制台或文件,如果写入文件,则确定错误日志文件名。参见 Section 7.4.2.2, “Default Error Log Destination Configuration”。 log_error_verbosity
和log_error_suppression_list
系统变量影响log_filter_internal
允许或抑制哪些类型的日志事件。参见 Section 7.4.2.5, “Priority-Based Error Log Filtering (log_filter_internal)”")。
在配置log_error_services
时,请注意以下特性:
- 日志组件列表可以用分号或(从 MySQL 8.0.12 开始)逗号分隔,可选地跟随空格。给定设置不能同时使用分号和逗号分隔符。组件顺序很重要,因为服务器按照列出的顺序执行组件。
log_error_services
值中的最终组件不能是过滤器。这是一个错误,因为它对事件的任何更改都不会对输出产生影响:
mysql> SET GLOBAL log_error_services = 'log_filter_internal'; ERROR 1231 (42000): Variable 'log_error_services' can't be set to the value of 'log_filter_internal'
- 要纠正问题,请在值的末尾包含一个 sink:
mysql> SET GLOBAL log_error_services = 'log_filter_internal; log_sink_internal';
- 在
log_error_services
中命名的组件顺序很重要,特别是与过滤器和接收器的相对顺序有关。考虑这个log_error_services
值:
log_filter_internal; log_sink_1; log_sink_2
- 在这种情况下,日志事件经过内置过滤器,然后传递到第一个接收器,再传递到第二个接收器。两个接收器都会接收到经过过滤的日志事件。
将其与此log_error_services
值进行比较:
log_sink_1; log_filter_internal; log_sink_2
- 在这种情况下,日志事件经过第一个接收器,然后经过内置过滤器,再传递到第二个接收器。第一个接收器接收未经过滤的事件。第二个接收器接收经过过滤的事件。如果您希望一个日志包含所有日志事件的消息,另一个日志仅包含部分日志事件的消息,您可以以这种方式配置错误日志记录。
错误日志配置方法
错误日志配置涉及根据需要加载和启用错误日志组件,并执行特定于组件的配置。
有两种错误日志配置方法,隐式 和 显式。建议选择一种配置方法并专门使用。同时使用两种方法可能会导致启动时出现警告。有关更多信息,请参阅 故障排除配置问题。
- 隐式错误日志配置(MySQL 8.0.30 中引入)此配置方法加载并启用由
log_error_services
变量定义的日志组件。在启动时,尚未加载的可加载组件会在InnoDB
存储引擎完全可用之前隐式加载。此配置方法具有以下优点:
- 日志组件在启动序列的早期加载,早于
InnoDB
存储引擎,使得记录的信息更早可用。 - 它避免了在启动过程中发生故障时丢失缓冲的日志信息。
- 使用
INSTALL COMPONENT
安装错误日志组件并不是必需的,简化了错误日志配置。
- 要使用这种方法,请参阅 隐式错误日志配置。
- 显式错误日志配置
注意
此配置方法支持向后兼容。推荐使用 MySQL 8.0.30 中引入的隐式配置方法。
这种配置方法需要使用INSTALL COMPONENT
加载错误日志组件,然后配置log_error_services
以启用日志组件。INSTALL COMPONENT
将组件添加到mysql.component
表(一个InnoDB
表),启动时要加载的组件从该表中读取,该表只有在InnoDB
初始化后才能访问。
在InnoDB
存储引擎初始化期间,启动序列期间缓冲记录的信息,这有时会因为InnoDB
启动序列期间发生的恢复和数据字典升级等操作而延长。
要使用此方法,请参阅显式错误日志配置。
MySQL8 中文参考(二十)(3)https://developer.aliyun.com/article/1566109