要配置审核日志文件名，请在服务器启动时设置 audit_log_file 系统变量。默认名称是 audit.log 在服务器数据目录中。为了最佳安全性，请将审核日志写入仅供 MySQL 服务器和合法用户查看的目录。

插件将audit_log_file值解释为可选的前导目录名、基本名称和可选的后缀。如果启用了压缩或加密，实际文件名（用于创建日志文件的名称）将不同于配置的文件名，因为它具有附加的后缀：

实际审核日志文件名是通过将适用的压缩和加密后缀添加到配置文件名而获得的结果。例如，如果配置的audit_log_file值为audit.log，则实际文件名将是以下表格中显示的值之一。

pwd_id指示用于加密或解密文件的密码ID。pwd_id格式为pwd_timestamp-seq，其中：

以下是一些示例pwd_id密码ID值：

20190403T142359-1
20190403T142400-1
20190403T142400-2

要构建相应的密钥环ID以存储密码在密钥环中，审核日志插件将audit_log-前缀添加到pwd_id值中。对于刚刚显示的密码ID，相应的密钥环ID为：

audit_log-20190403T142359-1
audit_log-20190403T142400-1
audit_log-20190403T142400-2

当前用于加密的审核日志插件的密码ID是具有最大 pwd_timestamp 值的那个。如果多个密码具有该 pwd_timestamp 值，则当前密码ID是具有最大序号的那个。例如，在前面的密码ID集中，两个密码具有最大时间戳 20190403T142400，因此当前密码ID是具有最大序号（2）的那个。

审核日志插件在初始化和终止时执行某些操作，基于有效的审核日志文件名：

要配置审核日志文件格式，请在服务器启动时设置 audit_log_format 系统变量。以下格式可用：

有关每种格式的详细信息，请参阅 第 8.4.5.4 节，“审核日志文件格式”。

MySQL Enterprise Audit 提供了设置刷新间隔以自动清除内存缓存的能力。使用 audit_log_flush_interval_seconds 系统变量配置的刷新任务，默认值为零，即不计划运行。

当任务配置为运行（值非零）时，MySQL Enterprise Audit 尝试在初始化时调用 调度器 组件，并配置内存缓存的定期刷新：

类似地，MySQL Enterprise Audit 在其反初始化时调用 scheduler 组件，并取消了它计划的刷新。它保持对调度器注册服务的活动引用，直到计划任务取消注册，以确保 scheduler 组件不能在活动计划任务时卸载。所有执行调度器和其任务的结果都写入服务器错误日志。

要计划审核日志刷新任务：

在 MySQL 8.3 中，您可以将 JSON 格式的日志文件扩展到可选数据字段，以显示查询时间、发送和接收的字节数、返回给客户端的行数和检查的行数。这些数据在慢查询日志中可用于检测异常值，并在审核日志中类似地帮助检测活动分析中的异常值。这些扩展数据字段只能在审核日志为 JSON 格式 (audit_log_format=JSON) 时添加，该设置不是默认设置。

查询统计信息通过组件服务传递到审核日志中，您可以设置这些服务作为审核日志过滤函数。这些服务名为 mysql_audit_print_service_longlong_data_source 和 mysql_audit_print_service_double_data_source。您可以为每个输出项选择任一数据类型。对于查询时间， longlong 输出微秒值， double 输出秒值。

您可以使用 audit_log_filter_set_filter() 审核日志函数将查询统计信息添加到审核日志中，作为 JSON 过滤语法的 service 元素，如下所示：

SELECT audit_log_filter_set_filter('QueryStatistics',  
                                   '{ "filter": { "class": { "name": "general", "event": { "name": "status", "print" : '
                                   '{ "service": { "implementation": "mysql_server", "tag": "query_statistics", "element": [ '
                                   '{ "name": "query_time",     "type": "double" }, '
                                   '{ "name": "bytes_sent",     "type": "longlong" }, '
                                   '{ "name": "bytes_received", "type": "longlong" }, '
                                   '{ "name": "rows_sent",      "type": "longlong" }, '
                                   '{ "name": "rows_examined",  "type": "longlong" } ] } } } } } }');

要填充 bytes_sent 和 bytes_received 字段，系统变量 log_slow_extra 必须设置为 ON。如果系统变量的值是 OFF，则将 null 值写入日志文件中这些字段。

如果您想停止收集查询统计信息，请使用 audit_log_filter_set_filter() 审核日志函数删除过滤器，例如：

SELECT audit_log_filter_remove_filter('QueryStatistics');

审核日志文件压缩可以为任何日志格式启用。

要配置审核日志文件压缩，请在服务器启动时设置 audit_log_compression 系统变量。允许的值是 NONE（无压缩；默认）和 GZIP（GNU Zip 压缩）。

如果同时启用压缩和加密，压缩将在加密之前发生。要手动恢复原始文件，首先解密，然后解压缩。请参阅 手动解压缩和解密审核日志文件。

审核日志文件加密可以为任何日志格式启用。加密基于用户定义的密码（除初始密码外，审核日志插件生成的密码）。要使用此功能，MySQL 密钥环必须启用，因为审核日志使用它来存储密码。任何密钥环组件或插件都可以使用；有关说明，请参阅 第 8.4.4 节，“MySQL 密钥环”。

要配置审核日志文件加密，请在服务器启动时设置 audit_log_encryption 系统变量。允许的值是 NONE（无加密；默认）和 AES（AES-256-CBC 密码加密）。

要设置或获取加密密码在运行时，请使用这些审核日志函数：

有关审计日志加密函数的更多信息，请参阅审计日志函数。

当审计日志插件初始化时，如果发现日志文件加密已启用，它将检查密钥环中是否存在审计日志加密密码。如果没有，该插件将自动生成一个随机的初始加密密码并将其存储在密钥环中。要发现该密码，请调用audit_log_encryption_password_get()。

如果同时启用了压缩和加密，压缩将在加密之前发生。要手动恢复原始文件，首先解密，然后解压缩。请参阅手动解压缩和解密审计日志文件。

审计日志文件可以使用标准工具解压缩和解密。这应该仅对已关闭（存档）的日志文件进行，不是当前由审计日志插件写入的日志文件。你可以通过审计日志插件在文件名中添加时间戳来识别存档日志文件。

在本讨论中，假设audit_log_file设置为audit.log。在那种情况下，存档审计日志文件将具有以下表格所示的名称。

如审核日志文件命名约定中所讨论的那样，pwd_id格式为pwd_timestamp-seq。因此，存档加密日志文件的名称实际上包含两个时间戳。第一个表示文件旋转时间，第二个表示加密密码创建时间。

考虑以下一组存档加密日志文件名称：

audit.20190410T205827.log.20190403T185337-1.enc
audit.20190410T210243.log.20190403T185337-1.enc
audit.20190415T145309.log.20190414T223342-1.enc
audit.20190415T151322.log.20190414T223342-2.enc

每个文件名都有一个唯一的旋转时间时间戳。相比之下，加密密码时间戳不是唯一的：

要手动解压缩压缩日志文件，请使用gunzip、gzip -d或等效命令。例如：

gunzip -c audit.timestamp.log.gz > audit.timestamp.log

要手动解密加密日志文件，请使用openssl命令。例如：

openssl enc -d -aes-256-cbc -pass pass:password -md sha256
    -in audit.timestamp.log.pwd_id.enc
    -out audit.timestamp.log

要执行该命令，您必须获取password，加密密码。为此，请使用audit_log_encryption_password_get()。例如，如果审核日志文件名为audit.20190415T151322.log.20190414T223342-2.enc，密码ID为20190414T223342-2，密钥环ID为audit-log-20190414T223342-2。检索密钥环密码如下：

SELECT audit_log_encryption_password_get('audit-log-20190414T223342-2');

如果审核日志记录启用了压缩和加密，压缩将在加密之前发生。在这种情况下，文件名将添加.gz和.pwd_id.enc后缀，相应于这些操作的顺序。要手动恢复原始文件，请执行反向操作，即首先解密文件，然后解压缩它：

openssl enc -d -aes-256-cbc -pass pass:password -md sha256
    -in audit.timestamp.log.gz.pwd_id.enc
    -out audit.timestamp.log.gz
gunzip -c audit.timestamp.log.gz > audit.timestamp.log

本节涵盖了 MySQL 8.0.17 之前的审核日志文件加密功能的差异，以及密码历史记录的实现（包括密码存档和过期）。它还表明了审核日志插件如何处理从低于 8.0.17 的版本升级到 MySQL 8.0.17 或更高版本。

在 MySQL 8.0.17 之前，没有密码历史记录，因此设置新密码将使旧密码不可访问，从而使 MySQL Enterprise Audit 无法读取使用旧密码加密的日志文件。如果您预计需要手动解密这些文件，您必须保留以前的密码记录。

如果在升级到 MySQL 8.0.17 或更高版本时启用了审核日志文件加密，则审核日志插件将执行以下升级操作：

审核日志文件可能会变得非常大，占用大量磁盘空间。如果您正在收集可选的查询时间和大小统计信息，这将增加空间要求。查询统计信息仅支持 JSON 格式。

管理空间使用的方法：

要配置审核日志文件空间管理，请使用以下系统变量：

以下部分将详细描述日志文件旋转和修剪。

Manual Audit Log File Rotation (Before MySQL 8.0.31)

如果 audit_log_rotate_on_size 为 0（默认值），则不会发生日志旋转，除非手动执行。在这种情况下，审计日志插件在 audit_log_flush 值从禁用更改为启用时关闭并重新打开日志文件。日志文件重命名必须在服务器外部进行。假设日志文件名为 audit.log，您想维护最新的三个日志文件，循环使用名称 audit.log.1 到 audit.log.3。在 Unix 上，手动旋转日志文件，如下所示：

Manual Audit Log File Rotation (From MySQL 8.0.31)

如果 audit_log_rotate_on_size 为 0（默认值），除非手动执行，否则不会发生日志旋转。

要手动旋转审核日志文件，请运行 SELECT audit_log_rotate(); 以重命名当前审核日志文件并打开一个新的审核日志文件。文件将根据 审核日志文件命名约定 进行重命名。

需要 AUDIT_ADMIN 权限来使用 audit_log_rotate() 函数。

管理已存档日志文件的数量（即已重命名的文件）及其所占用的空间是一个手动任务，涉及从文件系统中删除不再需要的已存档审核日志文件。

使用 audit_log_rotate() 函数重命名的审核日志文件的内容可以由 audit_log_read() 函数读取。

Automatic Audit Log File Rotation

如果 audit_log_rotate_on_size 大于 0，设置 audit_log_flush 将无效。相反，当写入当前日志文件时，如果其大小超过 audit_log_rotate_on_size 值，审核日志插件将自动重命名当前日志文件并打开一个新的当前日志文件，使用原始名称。

自动大小基于旋转也会在以下条件下发生：

插件将原始文件重命名，插入时间戳就在其基本名称后面。例如，如果文件名是audit.log，插件将其重命名为类似audit.20210115T140633.log的值。时间戳是一个UTC值，以YYYYMMDDThhmmss格式表示。对于XML日志记录，时间戳表示轮换时间。对于JSON日志记录，时间戳是最后一个事件写入文件的时间。

如果日志文件被加密，原始文件名已经包含了加密密码创建时间的时间戳（见Audit Log Files的命名约定）。在这种情况下，文件名在轮换后包含两个时间戳。例如，一个加密的日志文件名为audit.log.20210110T130749-1.enc，将被重命名为类似audit.20210115T140633.log.20210110T130749-1.enc的值。

Audit Log File Pruning

审核日志插件支持自动轮换的JSON格式审核日志文件的修剪，如果启用了自动日志文件轮换。

JSON 格式日志文件的修剪，如果启用，将按照以下方式进行：

对于基于旋转日志文件大小的修剪，如果旋转日志文件的总大小超过audit_log_max_size指定的限制，审计日志插件将删除最旧的文件，直到总大小不超过限制。

对于基于旋转日志文件年龄的修剪，修剪点是当前时间减去audit_log_prune_seconds的值。在旋转的 JSON 格式日志文件中，每个文件名的时间戳部分表示文件中最后一个事件的时间戳。审计日志插件使用文件名时间戳来确定哪些文件仅包含比修剪点更旧的事件，并删除它们。

审计日志插件可以使用多种策略来写入日志。无论使用哪种策略，日志记录都是尽力而为的，没有一致性保证。

要指定写入策略，请在服务器启动时设置audit_log_strategy系统变量。默认情况下，策略值为ASYNCHRONOUS，插件异步地将日志写入缓冲区，如果缓冲区满则等待。您可以告诉插件不要等待（PERFORMANCE）或同步地写入日志，使用文件系统缓存（SEMISYNCHRONOUS）或在每个写入请求后强制输出（SYNCHRONOUS）。

在许多情况下，如果当前查询太大无法写入缓冲区，插件将直接写入 JSON 格式审计日志。写入策略确定插件如何增加直接写入计数。您可以使用Audit_log_direct_writes状态变量来跟踪直接写入的数量。

对于异步写策略，audit_log_buffer_size 系统变量是以字节为单位的缓冲区大小。在服务器启动时设置该变量以更改缓冲区大小。插件在初始化时分配一个缓冲区，并在终止时删除该缓冲区。对于非异步写策略，插件不分配该缓冲区。

异步日志策略具有以下特征：

使用异步日志记录时，如果在写入文件或插件未正确关闭（例如，服务器主机意外退出）时出现问题，日志文件的完整性可能会受到损害。为了减少这种风险，可以将 audit_log_strategy 设置为使用同步日志记录。

使用 PERFORMANCE 策略的一个缺点是，当缓冲区满时，它会丢弃事件。在服务器负载很高的情况下，审核日志可能会缺少事件。