要配置审核日志文件名，请 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中，其中有两个密码ID的时间戳最大 20190403T142400，因此当前密码ID就是序列号（2）最大的密码ID。

审计日志插件根据有效的审计日志文件名在初始化和终止期间执行某些操作：

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

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

从 MySQL 8.0.30 开始，您可以使用可选数据字段扩展 JSON 格式的日志文件，以显示查询时间、发送和接收的字节数、返回给客户端的行数以及检查的行数。此数据在慢速查询日志中可用于符合条件的查询，在审计日志的上下文中，它同样有助于检测异常值以进行活动分析。只有当审计日志是JSON格式（ ）时才可以添加扩展数据字段audit_log_format=JSON，这不是默认设置。

查询统计信息通过您设置为审核日志过滤功能的组件服务传送到审核日志。这些服务被命名为 mysql_audit_print_service_longlong_data_source and mysql_audit_print_service_double_data_source。您可以为每个输出项选择任一数据类型。对于查询时间，longlong以微秒为单位double输出值，以秒为单位输出值。

audit_log_filter_set_filter() 您使用审计日志功能 添加查询统计信息 ，作为serviceJSON 过滤语法的元素，如下所示：

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。如果系统变量值为 value is OFF，则将空值写入这些字段的日志文件。

如果要停止收集查询统计信息，使用 audit_log_filter_set_filter() 审计日志功能去除过滤器，例如：

SELECT audit_log_filter_remove_filter('QueryStatistics');

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

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

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

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

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

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

有关审核日志加密功能的其他信息，请参阅审核日志功能。

审计日志插件在初始化时，如果发现启用了日志文件加密，则检查keyring是否包含审计日志加密密码。如果没有，插件会自动生成一个随机的初始加密密码并将其存储在密钥环中。要发现此密码，请调用 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 或更高版本时启用了审计日志文件加密，审计日志插件将执行以下升级操作：

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

要管理使用的空间，请使用以下方法：

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

以下部分更详细地描述了日志文件轮换和修剪。

手动审计日志文件轮转（MySQL 8.0.31 之前）

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

手动审核日志文件轮换（来自 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()函数读取。

自动审核日志文件轮换

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

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

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

如果日志文件被加密，原始文件名已经包含一个时间戳，指示加密密码创建时间（参见审计日志文件的命名约定）。在这种情况下，旋转后的文件名包含两个时间戳。例如，名为 的加密日志文件被重命名 audit.log.20210110T130749-1.enc为诸如 audit.20210115T140633.log.20210110T130749-1.enc.

审计日志文件修剪

如果启用了自动日志文件轮换，审计日志插件支持修剪轮换的 JSON 格式审计日志文件。要使用此功能：

JSON 格式日志文件的修剪（如果启用）如下所示：

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

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

审计日志插件可以使用多种日志写入策略中的任何一种。无论策略如何，日志记录都是在尽力而为的基础上进行的，不保证一致性。

要指定写入策略，请 audit_log_strategy在服务器启动时设置系统变量。默认情况下，策略值为 ASYNCHRONOUS，插件异步记录到缓冲区，等待缓冲区是否已满。可以告诉插件不要等待 ( PERFORMANCE) 或同步记录，使用文件系统缓存 ( ) 或在每次写入请求后SEMISYNCHRONOUS通过调用强制输出 ( )。 sync()SYNCHRONOUS

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

异步日志记录策略具有以下特点：

使用异步日志记录时，如果在写入文件期间出现问题或插件未完全关闭（例如，在服务器主机意外退出的情况下），则日志文件的完整性可能会受到损害。为了降低这种风险，设置 audit_log_strategy为使用同步日志记录。

策略的一个缺点PERFORMANCE是它会在缓冲区已满时丢弃事件。对于负载很重的服务器，审计日志可能缺少事件。