MySQL8 中文参考（二十一）（2）

MySQL8 中文参考（二十一）（1）https://developer.aliyun.com/article/1566170

7.4.4.5.1 启用二进制日志事务压缩时的行为

具有压缩有效负载的事务可以像任何其他事务一样回滚，并且也可以通过常规过滤选项在副本中过滤掉。二进制日志事务压缩可以应用于 XA 事务。

当启用二进制日志事务压缩时，服务器的max_allowed_packet和replica_max_allowed_packet或slave_max_allowed_packet限制仍然适用，并且是基于Transaction_payload_event的压缩大小加上事件头使用的字节进行计量。

重要

压缩事务负载作为一个单独的数据包发送，而不是在未使用二进制日志事务压缩时，将事务的每个事件作为单独的数据包发送。如果您的复制拓扑处理大型事务，请注意，当使用二进制日志事务压缩时，一个在未使用二进制日志事务压缩时可以成功复制的大型事务，可能由于其大小而停止复制。

对于多线程工作者，每个事务（包括其 GTID 事件和Transaction_payload_event）被分配给一个工作线程。工作线程解压缩事务负载，并逐个应用其中的各个事件。如果在Transaction_payload_event中应用任何事件时发现错误，则将报告整个事务失败给协调者。当replica_parallel_type或slave_parallel_type设置为DATABASE时，事务调度之前将受事务影响的所有数据库映射。与未压缩事务相比，使用二进制日志事务压缩与DATABASE策略可以减少并行性，后者将每个事件映射并调度。

对于半同步复制（参见 Section 19.4.10, “Semisynchronous Replication”)，当完整的Transaction_payload_event被接收时，副本确认事务。

当启用二进制日志校验和（这是默认设置）时，复制源服务器不会为压缩事务负载中的单个事件写入校验和。相反，为完整的Transaction_payload_event写入校验和，并为未压缩的任何事件写入单独的校验和，例如与 GTID 相关的事件。

对于SHOW BINLOG EVENTS和SHOW RELAYLOG EVENTS语句，Transaction_payload_event首先作为一个单元打印，然后解压缩并打印其中的每个事件。

对于引用事件结束位置的操作，比如START REPLICA（或在 MySQL 8.0.22 之前的版本中，START SLAVE）带有UNTIL子句，SOURCE_POS_WAIT()或MASTER_POS_WAIT()，以及sql_replica_skip_counter或sql_slave_skip_counter，您必须指定压缩事务有效载荷（Transaction_payload_event）的结束位置。当使用sql_replica_skip_counter或sql_slave_skip_counter跳过事件时，压缩的事务有效载荷被计为单个计数器值，因此其中的所有事件都作为一个单元被跳过。

7.4.4.5.2 组合压缩和未压缩的事务有效载荷

支持二进制日志事务压缩的 MySQL 服务器版本可以处理压缩和未压缩的事务有效载荷的混合。

• 与二进制日志事务压缩相关的系统变量不需要在所有组复制组成员上设置相同，并且不会从源复制到副本在复制拓扑中。您可以决定是否对具有二进制日志的每个 MySQL 服务器实例启用二进制日志事务压缩。
  
• 如果启用了事务压缩，然后在服务器上禁用了压缩，则未来在该服务器上发起的事务不会应用压缩，但已经压缩的事务有效载荷仍然可以被处理和显示。
  
• 如果通过设置binlog_transaction_compression的会话值为个别会话指定了事务压缩，则二进制日志可以包含压缩和未压缩的事务有效载荷的混合。
  

当复制拓扑中的源和其副本都启用了二进制日志事务压缩时，副本接收压缩的事务有效载荷并将其压缩写入其中继日志。它解压事务有效载荷以应用事务，然后在应用后再次压缩以写入其二进制日志。任何下游副本都会接收压缩的事务有效载荷。

当复制拓扑中的源具有启用二进制日志事务压缩，但其副本没有启用时，副本接收压缩的事务有效载荷并将其压缩写入其中继日志。它解压事务有效载荷以应用事务，然后将其未压缩写入其自己的二进制日志（如果有）。任何下游副本接收未压缩的事务有效载荷。

当复制拓扑中的源没有启用二进制日志事务压缩，但其副本启用时，如果副本具有二进制日志，则在应用事务后压缩事务有效载荷，并将压缩的事务有效载荷写入其二进制日志。任何下游副本接收压缩的事务有效载荷。

当 MySQL 服务器实例没有二进制日志时，如果它是来自 MySQL 8.0.20 的版本，则无论其对binlog_transaction_compression的值如何，它都可以接收、处理和显示压缩的事务有效载荷。这些服务器实例接收的压缩事务有效载荷以其压缩状态写入中继日志，因此它们间接受益于复制拓扑中其他服务器执行的压缩。

MySQL 8.0.20 之前的版本的副本无法从启用二进制日志事务压缩的源进行复制。MySQL 8.0.20 或更高版本的副本可以从不支持二进制日志事务压缩的早期版本的源进行复制，并在将其写入自己的二进制日志时对从该源接收的事务进行自己的压缩。

7.4.4.5.3 监视二进制日志事务压缩

您可以使用性能模式表binary_log_transaction_compression_stats监视二进制日志事务压缩的影响。统计数据包括监控期间的数据压缩比率，您还可以查看压缩对服务器上最后一个事务的影响。您可以通过截断表来重置统计信息。二进制日志和中继日志的统计数据是分开的，因此您可以看到每种日志类型的压缩影响。MySQL  服务器实例必须具有二进制日志才能生成这些统计信息。

Performance Schema 表 events_stages_current 显示事务何时处于解压缩或压缩阶段，以及显示该阶段的进度。压缩是由处理事务的工作线程在事务提交之前执行的，前提是在最终捕获缓存中没有排除事务的事件（例如，事故事件）。当需要解压缩时，会逐个事件从有效载荷中进行解压缩。

mysqlbinlog 使用 --verbose 选项时，会包含注释，说明压缩事务有效载荷的压缩大小和未压缩大小，以及所使用的压缩算法。

您可以在复制连接的协议级别启用连接压缩，使用 CHANGE REPLICATION SOURCE TO 语句（从 MySQL 8.0.23 开始）或 CHANGE MASTER TO 语句（在 MySQL 8.0.23 之前），或 replica_compressed_protocol 或 slave_compressed_protocol 系统变量的 SOURCE_COMPRESSION_ALGORITHMS | MASTER_COMPRESSION_ALGORITHMS 和 SOURCE_ZSTD_COMPRESSION_LEVEL | MASTER_ZSTD_COMPRESSION_LEVEL  选项。如果在启用连接压缩的系统中启用了二进制日志事务压缩，连接压缩的影响会减小，因为可能很少有机会进一步压缩已经压缩的事务有效载荷。但是，连接压缩仍然可以操作未压缩的事件和消息头。如果您需要节省存储空间以及网络带宽，可以在启用连接压缩的情况下启用二进制日志事务压缩。有关复制连接的连接压缩的更多信息，请参见  Section 6.2.8, “Connection Compression Control”。

对于组复制，当消息超过group_replication_compression_threshold系统变量设置的阈值时，默认启用压缩。您还可以通过使用group_replication_recovery_compression_algorithms和group_replication_recovery_zstd_compression_level系统变量，为从捐赠者的二进制日志进行状态传输的消息配置压缩。如果在配置了这些内容的系统中启用了二进制日志事务压缩，组复制的消息压缩仍然可以在未压缩事件和消息头上运行，但其影响会减小。有关组复制消息压缩的更多信息，请参见第 20.7.4 节，“消息压缩”。

7.4.5 慢查询日志

慢查询日志包含执行时间超过long_query_time秒且需要至少检查min_examined_row_limit行的 SQL 语句。慢查询日志可用于查找执行时间长且需要优化的查询。然而，检查长时间的慢查询日志可能是一项耗时的任务。为了简化这个过程，可以使用mysqldumpslow命令处理慢查询日志文件并总结其内容。参见第 6.6.10 节，“mysqldumpslow — Summarize Slow Query Log Files”。

获取初始锁的时间不计入执行时间。mysqld在执行完语句并释放所有锁之后将其写入慢查询日志，因此日志顺序可能与执行顺序不同。

• 慢查询日志参数
  
• 慢查询日志内容
  

慢查询日志参数

long_query_time的最小和默认值分别为 0 和 10。该值可以以微秒为分辨率进行指定。

默认情况下，不会记录管理语句，也不会记录未使用索引进行查找的查询。可以通过log_slow_admin_statements和log_queries_not_using_indexes进行更改，稍后会详细描述。

默认情况下，慢查询日志是禁用的。要明确指定初始慢查询日志状态，请使用--slow_query_log[={0|1}]。没有参数或参数为 1 时，--slow_query_log启用日志。参数为 0 时，此选项禁用日志。要指定日志文件名，请使用--slow_query_log_file=*file_name*。要指定日志目标，请使用log_output系统变量（如第 7.4.1 节，“选择通用查询日志和慢查询日志输出目标”中所述）。

注意

如果指定TABLE日志目的地，请参阅 Log Tables and “Too many open files” Errors。

如果未为慢查询日志文件指定名称，则默认名称为*host_name*-slow.log。服务器将在数据目录中创建该文件，除非给定绝对路径名以指定不同的目录。

要在运行时禁用或启用慢查询日志，或更改日志文件名，请使用全局slow_query_log和slow_query_log_file系统变量。将slow_query_log设置为 0 以禁用日志，设置为 1 以启用日志。将slow_query_log_file设置为指定日志文件的名称。如果已经打开了日志文件，则关闭该文件并打开新文件。

如果使用--log-short-format选项，服务器将向慢查询日志写入较少的信息。

要在慢查询日志中包含慢管理语句，请启用log_slow_admin_statements系统变量。管理语句包括ALTER TABLE、ANALYZE TABLE、CHECK TABLE、CREATE INDEX、DROP INDEX、OPTIMIZE TABLE和REPAIR TABLE。

要在慢查询日志中写入不使用索引进行行查找的查询语句，请启用log_queries_not_using_indexes系统变量。（即使启用了该变量，由于表少于两行，服务器也不会记录不受索引影响的查询。）

当记录不使用索引的查询时，慢查询日志可能会迅速增长。可以通过设置log_throttle_queries_not_using_indexes系统变量对这些查询设置速率限制。默认情况下，此变量为  0，表示没有限制。正值对不使用索引的查询的日志记录施加每分钟限制。第一个这样的查询打开一个 60  秒的窗口，在此窗口内，服务器记录达到给定限制的查询，然后抑制额外的查询。如果在窗口结束时有被抑制的查询，服务器将记录一个摘要，指示有多少个查询以及在其中花费的总时间。当服务器记录下一个不使用索引的查询时，下一个  60 秒的窗口开始。

服务器按照以下顺序使用控制参数来确定是否将查询写入慢查询日志：

1. 查询必须不是管理语句，或者必须启用log_slow_admin_statements。
   
2. 查询必须至少花费long_query_time秒，或者必须启用log_queries_not_using_indexes，并且查询没有使用索引进行行查找。
   
3. 查询必须至少检查了min_examined_row_limit行。
   
4. 查询必须根据log_throttle_queries_not_using_indexes设置而不被抑制。
   

log_timestamps系统变量控制写入慢查询日志文件（以及一般查询日志文件和错误日志）中消息的时间戳的时区。它不影响写入日志表的一般查询日志和慢查询日志消息的时区，但是可以通过CONVERT_TZ()或设置会话time_zone系统变量，将从这些表中检索的行从本地系统时区转换为任何所需的时区。

默认情况下，副本不会将复制的查询写入慢查询日志。要更改此设置，请启用系统变量log_slow_replica_statements（从 MySQL 8.0.26 开始）或log_slow_slave_statements（在 MySQL 8.0.26 之前）。请注意，如果使用基于行的复制（binlog_format=ROW），这些系统变量不起作用。仅当以语句格式在二进制日志中记录时，即当设置了binlog_format=STATEMENT时，或者当设置了binlog_format=MIXED并且语句以语句格式记录时，才会将查询添加到副本的慢查询日志中。即使启用了log_slow_replica_statements或log_slow_slave_statements，当以行格式记录慢查询时，即使设置了binlog_format=MIXED，或者当设置了binlog_format=ROW，也不会将其添加到副本的慢查询日志中。

慢查询日志内容

当慢查询日志被启用时，服务器会将输出写入由log_output系统变量指定的任何目的地。如果启用了日志，服务器会打开日志文件并将启动消息写入其中。然而，除非选择了FILE日志目的地，否则不会进一步将查询记录到文件中。如果目的地是NONE，即使启用了慢查询日志，服务器也不会写入任何查询。如果未选择FILE作为输出目的地，则设置日志文件名不会影响日志记录。

如果启用了慢查询日志并选择了FILE作为输出目的地，则写入日志的每个语句前面都会有一行以#字符开头并具有以下字段（所有字段都在一行上）：

• Query_time: *持续时间*
  语句执行时间（秒）。
  
• Lock_time: *持续时间*
  获取锁所需的时间（秒）。
  
• Rows_sent: *N*
  发送到客户端的行数。
  
• Rows_examined:
服务器层检查的行数（不包括存储引擎内部处理的任何处理）。
  

启用log_slow_extra系统变量（MySQL 8.0.14 起可用）会导致服务器将以下额外字段写入FILE输出，除了刚刚列出的字段外（TABLE`输出不受影响）。一些字段描述涉及状态变量名称。有关更多信息，请参考状态变量描述。但是，在慢查询日志中，计数器是每个语句的值，而不是每个会话的累积值。

• Thread_id: *ID*
  语句线程标识符。
  
• Errno: *错误编号*
  语句错误编号，如果没有错误则为 0。
  
• Killed: *N*
  如果语句被终止，表示为什么的错误编号，如果语句正常终止则为 0。
  
• Bytes_received: *N*
Bytes_received语句的值。
  
• Bytes_sent: *N*
Bytes_sent语句的值。
  
• Read_first: *N*
Handler_read_first语句的值。
  
• Read_last: *N*
Handler_read_last语句的值。
  
• Read_key: *N*
Handler_read_key语句的值。
  
• Read_next: *N*
Handler_read_next语句的值。
  
• Read_prev: *N*
Handler_read_prev语句的值。
  
• Read_rnd: *N*
Handler_read_rnd语句的值。
  
• Read_rnd_next: *N*
Handler_read_rnd_next语句的值。
  
• Sort_merge_passes: *N*
Sort_merge_passes语句的值。
  
• Sort_range_count: *N*
Sort_range语句的值。
  
• Sort_rows: *N*
Sort_rows语句的值。
  
• Sort_scan_count: *N*
Sort_scan语句的值。
  
• Created_tmp_disk_tables: *N*
Created_tmp_disk_tables语句的值。
  
• Created_tmp_tables: *N*
Created_tmp_tables语句的值。
  
• Start: *时间戳*
  语句执行开始时间。
  
• End: *时间戳*
  语句执行结束时间。
  

给定的慢查询日志文件可能包含启用log_slow_extra后添加了额外字段的行和没有额外字段的行。日志文件分析器可以通过字段计数确定一行是否包含额外字段。

每条写入慢查询日志文件的语句前面都有一个包含时间戳的SET语句。从 MySQL 8.0.14 开始，时间戳表示慢语句开始执行的时间。在 8.0.14 之前，时间戳表示慢语句被记录的时间（这发生在语句执行完成后）。

写入慢查询日志的语句中的密码会被服务器重写，以避免明文出现。参见第 8.1.2.3 节，“密码和日志记录”。

从 MySQL 8.0.29 开始，由于语法错误等原因无法解析的语句不会被写入慢查询日志。

7.4.6 服务器日志维护

如 第 7.4 节，“MySQL 服务器日志” 中所述，MySQL 服务器可以创建几个不同的日志文件，帮助您查看正在发生的活动。然而，您必须定期清理这些文件，以确保日志不会占用太多磁盘空间。

当使用启用日志记录的 MySQL 时，您可能希望定期备份并删除旧的日志文件，并告诉 MySQL 开始记录到新文件中。参见 第 9.2 节，“数据库备份方法”。

在 Linux（Red Hat）安装中，您可以使用 mysql-log-rotate 脚本进行日志维护。如果您从 RPM 发行版安装了 MySQL，则此脚本应该已自动安装。如果您正在使用二进制日志进行复制，请小心使用此脚本。在确定所有副本都已处理其内容之前，不应删除二进制日志。

在其他系统上，您必须自己安装一个短脚本，然后从 cron（或其等效物）启动以处理日志文件。

二进制日志文件在服务器的二进制日志过期期间后会自动删除。文件的删除可以在启动时和二进制日志刷新时进行。默认的二进制日志过期期限为 30 天。要指定替代的过期期限，请使用 binlog_expire_logs_seconds 系统变量。如果您正在使用复制，您应该指定一个不低于副本可能滞后源的最长时间的过期期限。要按需删除二进制日志，请使用 PURGE BINARY LOGS 语句（参见 第 15.4.1.1 节，“PURGE BINARY LOGS 语句”）。

要强制 MySQL 开始使用新的日志文件，需要刷新日志。执行FLUSH LOGS语句或mysqladmin flush-logs、mysqladmin refresh、mysqldump --flush-logs或mysqldump --master-data命令时会发生日志刷新。参见第  15.7.8.3 节，“FLUSH 语句”、第 6.5.2 节，“mysqladmin — A MySQL Server  Administration Program”和第 6.5.4 节，“mysqldump — A Database Backup  Program”。此外，当当前二进制日志文件大小达到max_binlog_size系统变量的值时，服务器会自动刷新二进制日志。

FLUSH LOGS支持可选修饰符，以启用对单个日志的选择性刷新（例如，FLUSH BINARY LOGS）。参见第 15.7.8.3 节，“FLUSH 语句”。

日志刷新操作具有以下效果：

• 如果启用了二进制日志记录，服务器会关闭当前的二进制日志文件，并打开下一个序列号的新日志文件。
  
• 如果启用了一般查询日志或慢查询日志到日志文件的记录，服务器会关闭并重新打开日志文件。
  
• 如果服务器是使用--log-error选项启动的，以将错误日志写入文件，服务器会关闭并重新打开日志文件。
  

执行刷新日志语句或命令需要使用具有RELOAD权限的帐户连接到服务器。在 Unix 和类 Unix 系统上，刷新日志的另一种方法是向服务器发送信号，可以由root或拥有服务器进程的帐户执行。（参见第 6.10 节，“MySQL 中的 Unix 信号处理”。）信号使得可以在不连接到服务器的情况下执行日志刷新：

• SIGHUP信号会刷新所有日志。然而，SIGHUP除了日志刷新之外还有其他可能不希望的附加效果。
  
• 截至 MySQL 8.0.19 版本，SIGUSR1会导致服务器刷新错误日志、一般查询日志和慢查询日志。如果只想刷新这些日志，SIGUSR1可以作为一个更“轻量级”的信号，不会产生与日志无关的SIGHUP效果。
  

如前所述，刷新二进制日志会创建一个新的二进制日志文件，而刷新一般查询日志、慢查询日志或错误日志只是关闭并重新打开日志文件。对于后者的日志，在  Unix  上，要在刷新之前重命名当前日志文件以创建一个新的日志文件。在刷新时，服务器会使用原始名称打开新的日志文件。例如，如果一般查询日志、慢查询日志和错误日志文件分别命名为mysql.log、mysql-slow.log和err.log，您可以在命令行中使用一系列命令如下：

cd *mysql-data-directory*
mv mysql.log mysql.log.old
mv mysql-slow.log mysql-slow.log.old
mv err.log err.log.old
mysqladmin flush-logs

在 Windows 上，使用rename而不是mv。

此时，您可以备份mysql.log.old、mysql-slow.log.old和err.log.old，然后将它们从磁盘中删除。

要在运行时重命名一般查询日志或慢查询日志，首先连接到服务器并禁用日志：

SET GLOBAL general_log = 'OFF';
SET GLOBAL slow_query_log = 'OFF';

禁用日志后，可以在外部重命名日志文件（例如，从命令行）。然后再次启用日志：

SET GLOBAL general_log = 'ON';
SET GLOBAL slow_query_log = 'ON';

这种方法适用于任何平台，不需要重新启动服务器。

注意

在您在外部重命名文件后，服务器重新创建给定日志文件时，文件位置必须可被服务器写入。这并非总是如此。例如，在 Linux 上，服务器可能将错误日志写入为/var/log/mysqld.log，其中/var/log由root拥有且不可写入mysqld。在这种情况下，日志刷新操作无法创建新的日志文件。

处理这种情况，您必须在重命名原始日志文件后手动创建具有适当所有权的新日志文件。例如，以root身份执行以下命令：

mv /var/log/mysqld.log /var/log/mysqld.log.old
install -omysql -gmysql -m0644 /dev/null /var/log/mysqld.log

7.5 MySQL 组件

7.5.1 安装和卸载组件

7.5.2 获取组件信息

7.5.3 错误日志组件

7.5.4 查询属性组件

7.5.5 调度器组件

MySQL Server 包括一个基于组件的基础架构，用于扩展服务器功能。组件提供对服务器和其他组件可用的服务。（在服务使用方面，服务器是一个组件，与其他组件相等。）组件之间仅通过它们提供的服务进行交互。

MySQL 发行版包含几个实现服务器扩展的组件：

• 用于配置错误日志的组件。参见第 7.4.2 节，“错误日志”和第 7.5.3 节，“错误日志组件”。
  
• 一个用于检查密码的组件。参见第 8.4.3 节，“密码验证组件”。
  
• Keyring 组件为敏感信息提供安全存储。参见第 8.4.4 节，“MySQL Keyring”。
  
• 一个使应用程序能够向审计日志添加自己的消息事件的组件。参见第 8.4.6 节，“审计消息组件”。
  
• 实现用于访问查询属性的可加载函数的组件。参见第 11.6 节，“查询属性”。
  
• 用于调度主动执行任务的组件。参见第 7.5.5 节，“调度器组件”。
  

当组件安装时，由组件实现的系统和状态变量将被公开，并具有以组件特定前缀开头的名称。例如，log_filter_dragnet错误日志过滤组件实现了一个名为log_error_filter_rules的系统变量，其完整名称为dragnet.log_error_filter_rules。要引用此变量，请使用完整名称。

以下部分描述了如何安装和卸载组件，以及在运行时如何确定已安装的组件并获取有关它们的信息。

有关组件的内部实现信息，请参阅 MySQL Server Doxygen 文档，网址为dev.mysql.com/doc/index-other.html。例如，如果您打算编写自己的组件，了解这些信息对于理解组件的工作原理非常重要。

7.5.1 安装和卸载组件

组件必须在服务器中加载后才能使用。MySQL 支持在运行时手动加载组件和在服务器启动期间自动加载组件。

在加载组件时，可以按照 Section 7.5.2, “Obtaining Component Information”中描述的方式获取有关组件的信息。

INSTALL COMPONENT和UNINSTALL COMPONENT SQL 语句可实现组件的加载和卸载。例如：

INSTALL COMPONENT 'file://component_validate_password';
UNINSTALL COMPONENT 'file://component_validate_password';

加载程序服务处理组件的加载和卸载，并在mysql.component系统表中注册已加载的组件。

组件操作的 SQL 语句会影响服务器操作和mysql.component系统表，具体如下：

• INSTALL COMPONENT会将组件加载到服务器中。组件会立即生效。加载程序服务还会在mysql.component系统表中注册已加载的组件。对于后续的服务器重新启动，加载程序服务会在启动序列中加载mysql.component中列出的任何组件。即使服务器使用--skip-grant-tables选项启动，也会发生这种情况。可选的SET子句允许在安装组件时设置组件系统变量的值。
  
• UNINSTALL COMPONENT会停用组件并从服务器中卸载它们。加载程序服务还会从mysql.component系统表中注销这些组件，以便服务器在后续重新启动时不再在启动序列中加载它们。
  

与服务器插件的对应INSTALL PLUGIN语句相比，组件的INSTALL COMPONENT语句具有显著优势，不需要知道任何特定于平台的文件名后缀来命名组件。这意味着给定的INSTALL COMPONENT语句可以在各个平台上统一执行。

安装组件时，可能还会自动安装相关的可加载函数。如果是这样，卸载组件时也会自动卸载这些函数。

7.5.2 获取组件信息

mysql.component 系统表包含有关当前加载的组件的信息，并显示哪些组件已使用INSTALL COMPONENT进行注册。从表中选择显示已安装的组件。例如：

mysql> SELECT * FROM mysql.component;
+--------------+--------------------+------------------------------------+
| component_id | component_group_id | component_urn                      |
+--------------+--------------------+------------------------------------+
|            1 |                  1 | file://component_validate_password |
|            2 |                  2 | file://component_log_sink_json     |
+--------------+--------------------+------------------------------------+

component_id 和 component_group_id 值仅供内部使用。component_urn 是在INSTALL COMPONENT和UNINSTALL COMPONENT语句中用于加载和卸载组件的 URN。

7.5.3 错误日志组件

本节描述了各个错误日志组件的特性。有关配置错误日志的一般信息，请参见 Section 7.4.2, “The Error Log”。

日志组件可以是过滤器或接收器：

• 过滤器处理日志事件，以添加、删除或修改事件字段，或完全删除事件。处理后的事件传递到已启用组件列表中的下一个日志组件。
  
• 接收器是日志事件的目的地（写入器）。通常，接收器将日志事件处理成具有特定格式的日志消息，并将这些消息写入其关联的输出，如文件或系统日志。接收器还可以写入到性能模式error_log表；参见 Section 29.12.21.2, “The error_log Table”。事件未经修改地传递到已启用组件列表中的下一个日志组件（即，尽管接收器格式化事件以生成输出消息，但它不会在内部传递给下一个组件时修改事件）。
  

log_error_services系统变量值列出了已启用的日志组件。未在列表中命名的组件已禁用。从 MySQL 8.0.30 开始，如果未加载错误日志组件，则log_error_services也会隐式加载它们。有关更多信息，请参见 Section 7.4.2.1, “Error Log Configuration”。

以下各节描述了按组件类型分组的各个日志组件：

• 过滤器错误日志组件
  
• 接收器错误日志组件
  

组件描述包括以下类型的信息：

• 组件名称和预期目的。
  
• 组件是内置的还是必须加载。对于可加载组件，描述指定了在使用INSTALL COMPONENT和UNINSTALL COMPONENT语句显式加载或卸载组件时要使用的 URN。隐式加载错误日志组件只需要组件名称。有关更多信息，请参见 Section 7.4.2.1, “Error Log Configuration”。
  
• 组件是否可以在log_error_services值中列出多次。
  
• 对于一个接收组件，组件写入输出的目的地。
  
• 对于一个接收组件，它是否支持与性能模式error_log表的接口。
  

过滤错误日志组件

错误日志过滤组件实现对错误日志事件的过滤。如果没有启用过滤组件，则不会进行过滤。

任何启用的过滤组件仅影响稍后在log_error_services值中列出的组件的日志事件。特别是，对于在log_error_services中较早列出的任何日志接收组件，不会发生任何日志事件过滤。

log_filter_internal 组件

• 目的：实现基于日志事件优先级和错误代码的过滤，结合log_error_verbosity和log_error_suppression_list系统变量。参见第 7.4.2.5 节“基于优先级的错误日志过滤（log_filter_internal）”。
  
• URN：此组件是内置的，无需加载。
  
• 允许多次使用：否。
  

如果log_filter_internal被禁用，log_error_verbosity和log_error_suppression_list将不起作用。

log_filter_dragnet 组件

• 目的：实现根据dragnet.log_error_filter_rules系统变量设置定义的规则进行过滤。参见第 7.4.2.6 节“基于规则的错误日志过滤（log_filter_dragnet）”。
  
• URN：file://component_log_filter_dragnet
  
• 允许多次使用：否。
  

接收错误日志组件

错误日志接收组件是实现错误日志输出的写入器。如果没有启用接收组件，则不会发生日志输出。

一些接收组件描述涉及默认的错误日志目的地。这是控制台或文件，并由log_error系统变量的值表示，如第 7.4.2.2 节“默认错误日志目的地配置”中所述确定。

log_sink_internal 组件

• 目的：实现传统的错误日志消息输出格式。
  
• URN：此组件是内置的，无需加载。
  
• 允许多次使用：否。
  
• 输出目的地：写入默认的错误日志目的地。
  
• 性能模式支持：写入error_log表。提供一个解析器用于读取以前服务器实例创建的错误日志文件。
  

JSON 格式日志汇聚组件

• 目的：实现 JSON 格式的错误日志记录。参见第 7.4.2.7 节，“JSON 格式错误日志记录”。
  
• URN：file://component_log_sink_json
  
• 多次使用允许：允许。
  
• 输出目的地：该汇聚根据默认错误日志目的地确定其输出目的地，该目的地由log_error系统变量给出：

• 如果log_error指定了一个文件，汇聚将基于该文件名进行输出文件命名，加上一个以.*NN*.json为后缀的编号，其中*NN从 00 开始。例如，如果log_error是file_name*，那么在log_error_services值中连续命名的log_sink_json将写入*file_name*.00.json，*file_name*.01.json等。
  
• 如果log_error是stderr，则汇聚将写入控制台。如果在log_error_services值中多次命名log_sink_json，它们都将写入控制台，这可能没有用处。
  

• 性能模式支持：写入error_log表。提供一个解析器用于读取以前服务器实例创建的错误日志文件。
  

日志汇聚系统事件日志组件

• 目的：实现将错误日志记录到系统日志。这是 Windows 上的事件日志，以及 Unix 和类 Unix 系统上的syslog。参见第 7.4.2.8 节，“将错误日志记录到系统日志”。
  
• URN：file://component_log_sink_syseventlog
  
• 多次使用允许：不允许。
  
• 输出目的地：写入系统日志。不使用默认错误日志目的地。
  
• 性能模式支持：不写入error_log表。不提供解析器用于读取以前服务器实例创建的错误日志文件。
  

日志汇聚测试组件

• 目的：用于编写测试用例的内部使用，不用于生产环境。
  
• URN：file://component_log_sink_test
  

由于log_sink_test是用于内部使用，因此未指定诸如是否允许多次使用和输出目的地等汇聚属性。因此，其行为可能随时发生变化。

7.5.4 查询属性组件

从 MySQL 8.0.23 开始，一个组件服务提供了对查询属性的访问（参见第 11.6 节，“查询属性”）。query_attributes组件使用此服务在 SQL 语句中提供对查询属性的访问。

• 目的：实现mysql_query_attribute_string()函数，该函数接受属性名称参数并将属性值作为字符串返回，如果属性不存在则返回NULL。
  
• URN：file://component_query_attributes
  

希望使用query_attributes所使用的相同查询属性组件服务的开发人员应查阅 MySQL 源代码分发中的mysql_query_attributes.h文件。

MySQL8 中文参考（二十一）（3）https://developer.aliyun.com/article/1566172