描述二进制日志捕获发生的 DML、DDL 和安全更改，并以二进制格式存储这些更改。二进制日志支持时间点恢复，防止在灾难恢复情况下丢失数据。它还使您能够查看对数据库所做的所有更改。这 binlog_rows_query_log_events 系统变量仅影响基于行的日志记录。启用后，它会导致 MySQL 5.6.2 或更高版本的服务器将信息日志事件（例如行查询日志事件）写入其二进制日志。此信息可用于调试和相关目的；例如，当无法从行更新中重建时，获取在 master 上发出的原始查询。这些事件通常被 MySQL 5.6.2 和读取二进制日志的更高版本的程序忽略，因此在从备份复制或恢复时不会引起任何问题。这对于 amysqld或 不是真的mysqlbinlog来自 MySQL 5.6.1 或更早版本。如果读取日志的旧版本程序遇到信息性日志事件，它将失败，并在此时停止读取。为了使二进制日志可被从属复制 MySQL 服务器和其他服务器（例如mysqlbinlog MySQL 5.6.1 或更早版本）读取， binlog_rows_query_log_events 必须在日志记录期间禁用。

严重性轻微警告

建议调查将行查询日志事件等信息性日志事件写入二进制日志是否适合您的环境。也就是说，如果读取你日志的所有服务器和其他日志读取器如 mysqlbinlog 都是 MySQL 5.6.2 及更高版本。如果是这样，请打开此功能以在日志中捕获额外信息。binlog_rows_query_log_events 您可以将系统变量的值动态设置 为ON，将新值放入[mysqld]my.cnf/my.ini 文件的部分，以便在您重新启动服务器时它仍然有效。

描述二进制日志捕获发生的 DML、DDL 和安全更改，并以二进制格式存储这些更改。二进制日志支持时间点恢复，防止在灾难恢复情况下丢失数据。它还使您能够查看对数据库所做的所有更改。可以使用--binlog-do-db和 --binlog-ignore-db选项将二进制日志记录限制为特定数据库。但是，如果使用这些选项，您的时间点恢复选项将受到相应限制，同时您查看对系统所做更改的能力也会受到限制。

严重性轻微警告

建议查看 my.cnf/my.ini 文件中的 --binlog-do-db和 --binlog-ignore-db设置，以确保您正在捕获对所有重要数据库的更新。它们目前在服务器上设置如下：--binlog-do-db : %binlog_do_db%和 --binlog-ignore-db : %binlog_ignore_db%

描述二进制日志捕获发生的 DML、DDL 和安全更改，并以二进制格式存储这些更改。二进制日志支持时间点恢复，防止在灾难恢复情况下丢失数据。它还使您能够查看对数据库所做的所有更改。

严重性轻微警告

建议通过在my.cnf/my.ini 文件的部分中 设置log-bin配置变量，为时间点恢复启用二进制日志记录 。[mysqld]

描述默认情况下，二进制日志内容不会同步到磁盘。如果服务器主机或操作系统崩溃，二进制日志中的最新事件有可能不会保存在磁盘上。您可以使用 sync_binlog 服务器变量更改此行为。如果这个变量的值大于 0，MySQL 服务器会在 sync_binlog 提交组写入二进制日志后将其二进制日志同步到磁盘（使用 fdatasync()）。sync_binlog 的默认值为 0，即不同步到磁盘 - 在这种情况下，服务器依靠操作系统不时地刷新二进制日志的内容，就像任何其他文件一样。值 1 是最安全的选择，因为在发生崩溃时，您最多会从二进制日志中丢失一个提交组。然而，它也是最慢的选择（除非磁盘有电池备份缓存，这使得同步非常快）。

严重性轻微警告

建议在 my.cnf/my.ini 文件的 [mysqld] 部分中设置 sync_binlog = 1 以确保从硬件、操作系统和 MySQL 服务器崩溃中恢复的最大安全性。

描述二进制日志捕获发生的 DML、DDL 和安全更改，并以二进制格式存储这些更改。二进制日志支持时间点恢复，防止在灾难恢复情况下丢失数据。它在主复制服务器上用作要发送到从服务器的语句的记录。它还使您能够查看对数据库所做的所有更改。但是，日志文件的数量和它们使用的空间会迅速增长，尤其是在繁忙的服务器上，因此只要已进行适当的备份，就必须在不再需要时定期删除这些文件。该 binlog_expire_logs_seconds 参数启用自动二进制日志删除。

严重性轻微警告

建议调查为什么二进制日志每隔 %expire_logs_days% 天自动删除。这可能是适合您的环境的设置，但异常低，因此请确保您的备份计划和执行足以支持您的灾难恢复方案。如有必要，将 expire_logs_days 的设置增加到一个值，以确保在您的环境中安全可靠地操作，同时最大限度地减少磁盘使用，并确保二进制日志至少可以追溯到上次完整备份。确保还更新 my.cnf/my.ini 文件中的 expire_logs_days 的值，以便在服务器重新启动时正确设置它。

说明底层操作系统的大小写敏感性决定了数据库和表名的大小写敏感性。如果您只在一个平台上使用 MySQL，您通常不必担心这一点。但是，根据您配置服务器的方式，如果您想要在文件系统区分大小写不同的平台之间传输表，您可能会遇到困难。

严重性轻微警告

建议在 my.cnf/my.ini 文件中设置 lower_case_table_names=1 并重新启动 MySQL 服务器。请注意，如果您计划在 Unix 上将 lower_case_table_names 系统变量设置为 1，则必须先将旧数据库和表名转换为小写，然后再使用新变量设置重新启动 mysqld。

描述事件调度程序在启用时是一个非常有用的功能。它是一个在特定时间或定期执行 SQL 命令的框架。从概念上讲，它类似于 Unix crontab（也称为“cron 作业”）或 Windows 任务计划程序。其架构的基础很简单。事件是具有开始日期和时间以及循环标记的存储例程。一旦定义并激活，它将在请求时运行。与触发器不同，事件不链接到特定的表操作，而是链接到日期和时间。使用事件调度程序，数据库管理员可以毫不费力地执行重复发生的事件。常见用途是清理过时数据，创建统计汇总表，

严重性轻微警告

建议启用事件调度程序并使用它来自动执行重复发生的事件。将行 event_scheduler=1 添加到 my.cnf/my.ini 文件的 [mysqld] 部分，以便在服务器重新启动时正确设置变量。

描述一般查询日志是对mysqld正在做什么的一般记录。当客户端连接或断开连接时，服务器将信息写入此日志，并记录从客户端收到的每个 SQL 语句。当您怀疑客户端有错误并想确切地知道客户端发送给 mysqld 的内容时，通用查询日志可能非常有用。但是，一般查询日志不应在生产环境中启用，因为： 它会增加服务器的开销；它按照收到的顺序而不是执行的顺序记录语句，因此备份/恢复不可靠；它增长很快，会占用大量磁盘空间。您应该改用二进制日志。

严重性轻微警告

建议禁用一般查询日志：从 my.cnf/my.ini 文件中删除日志选项，或从启动 MySQL 服务器的脚本中删除 --log 选项。

描述如果构建临时表所需的空间超过 tmp_table_size 或 max_heap_table_size ，MySQL 会在服务器的 tmpdir 目录中创建一个基于磁盘的表。出于性能原因，理想的做法是在内存中创建大多数临时表，而在磁盘上创建非常大的临时表。许多 DBA 适当地配置了 tmp_table_size，但忘记了 max_heap_table_size 也起作用。

严重性轻微警告

建议考虑将 max_heap_table_size 设置为等于或大于 tmp_table_size。变量 tmp_table_size 当前设置为 %tmp_table_size% 并且 max_heap_table_size 设置为 %max_heap_table_size% 。

描述为了防止 SQL 中被忽略的拼写错误和语法错误，或操作模式和 SQL 命令的各种组合的其他意外后果，InnoDB 提供了一种“严格模式”的操作。在这种模式下，InnoDB 在某些情况下会引发错误条件，而不是发出警告并处理指定的命令（可能有一些意外的默认值）。这类似于 MySQL 的 sql_mode，它控制 MySQL 将接受什么 SQL 语法，并确定它是否会默默地忽略错误，或验证输入语法和数据值。不在严格模式下运行时，在 CREATE TABLE 和 ALTER TABLE 命令以及 CREATE INDEX 命令上使用 ROW_FORMAT 和 KEY_BLOCK_SIZE 的新子句和设置可能会造成混淆。除非您在严格模式下运行，否则 InnoDB 将忽略某些语法错误并创建表或索引，消息日志中只会出现警告。但是，如果启用了 InnoDB 严格模式，此类错误将立即产生错误并且不会创建表或索引，从而通过在发出命令时捕获错误来节省时间。

严重性轻微警告

建议调查 innodb_strict_mode 变量设置为 OFF 的原因。将 innodb_strict_mode=1 添加到您的 my.cnf/my.ini 文件，以便在服务器重新启动时正确设置。

描述如果不允许 InnoDB 系统表空间自动增长以满足传入数据需求，并且您的应用程序生成的数据超过了空间，则会发生空间不足错误，并且您的应用程序可能会遇到问题。

严重性轻微警告

建议通过在 my.cnf/my.ini 文件的 innodb_data_file_path 变量中包含 autoextend 关键字，将 InnoDB 系统表空间配置为自动扩展。为了帮助确保低水平的碎片，将自动扩展增量（InnoDB 表空间将增长的空间量）设置为一个较大的量。

描述为避免频繁的检查点活动并减少整体物理 I/O，这会减慢写入繁重的系统，InnoDB 事务日志应约为 InnoDB 缓冲池大小的 50-100%，具体取决于缓冲区的大小水池。

严重性轻微警告

建议增加 InnoDB 事务日志的大小。但是请注意，更大的事务日志可能意味着更多的崩溃恢复时间和更密集的检查点周期，因为更多的数据必须从缓冲池和日志中刷新到表空间数据文件中。考虑到这一点，建议的最大大小为每个日志文件 1 GB。要更改日志文件的大小，请彻底关闭 MySQL，在 my.cnf/my.ini 文件中相应地更改 innodb_log_file_size 的值，将当前的 ib_logfile* 文件从数据目录移动到另一个位置，然后重新启动 MySQL因此可以自动创建新的日志文件。

说明MySQL 服务器遇到的错误情况总是记录在错误日志中，但只有当 log_warnings 设置为大于 0 的值时才会记录警告情况。如果未记录警告，您将不会获得有关中止连接和其他各种有价值的信息通讯错误。如果您使用复制，这一点尤其重要，这样您可以获得有关正在发生的事情的更多信息，例如有关网络故障和重新连接的消息。请注意，从 MySQL 5.7.2 开始， log_error_verbosity 系统变量优先于 log_warnings ，并且应该使用它来代替 log_warnings 。

严重性轻微警告

建议调查 log_warnings 设置为 0 的原因。除非有明确且令人信服的理由不记录警告，否则请将 log_warnings 设置为大于 0 的值。但是，在为 log_warnings 选择值时，请注意 Bug #42851 和 Bug #46265。当对某些语句使用二进制日志记录时，设置 log_warnings = 2 可能会使错误日志充满关于这些语句的警告。在这些情况下，请检查您是否可以使用基于行的日志记录，因为该格式始终是安全的。重要说明：从 MySQL 5.7.2 开始， log_error_verbosity 系统变量优先于 log_warnings ，并且应该使用它来代替 log_warnings 。参见http://dev.mysql.com/doc/mysql/en/server-system-variables的说明。html#sysvar_log_warnings 有关该变量如何与 log_error_verbosity 相关的信息。特别是，为 log_warnings 赋值会为 log_error_verbosity 赋值，反之亦然。另外，请注意 MySQL Server 5.7.11 中添加的 log_statements_unsafe_for_binlog 选项。如果遇到错误 1592，它控制生成的警告是否添加到错误日志中。