二进制日志记录选项和变量
- 二进制记录使用的启动选项
- 二进制日志记录使用的系统变量
您可以使用本节中描述的mysqld选项和系统变量来影响二进制日志的操作以及控制将哪些语句写入二进制日志。有关二进制日志的更多信息，请参见“MySQL服务器二进制日志”。有关使用MySQL服务器选项和系统变量的更多信息，请参见“服务器命令选项”和“服务器系统变量”。
二进制记录使用的启动选项
下表描述了用于启用和配置二进制日志的启动选项。本节稍后将讨论与二进制日志记录一起使用的系统变量。
--binlog-row-event-max-size=N属性 值 命令行格式 --binlog-row-event-max-size=# 系统变量（>= 8.0.14） binlog_row_event_max_size 范围（>= 8.0.14） Global 动态（>= 8.0.14） 没有 SET_VAR提示适用（>= 8.0.14）没有 类型 整数 默认值 8192 最低值 256 最大值（64位平台） 18446744073709551615 最大值（32位平台） 4294967295 当使用基于行的二进制日志记录时，此设置是对基于行的二进制日志事件的最大大小（以字节为单位）的软限制。如果可能，将二进制日志中存储的行分组为大小不超过此设置的值的事件。如果事件无法拆分，则可以超过最大大小。该值必须是256的倍数（否则将被舍入为256）。默认值为8192字节。
--log-bin[=base_name]属性 值 命令行格式 --log-bin=file_name 类型 文件名 指定用于二进制日志文件的基本名称。启用二进制日志记录后，服务器会将所有更改数据的语句记录到二进制日志中，该日志用于备份和复制。二进制日志是具有基本名称和数字扩展名的文件序列。该
--log-bin选项的值是日志序列的基本名称。服务器通过在基本名称中添加数字后缀来依次创建二进制日志文件。如果不提供该
--log-bin选项，则MySQL将使用binlog二进制日志文件的默认基本名称。为了与早期版本兼容，如果提供的--log-bin选项不带字符串或带空字符串，则基本名称默认为host_name-bin，使用主机名。二进制日志文件的默认位置是数据目录。您可以使用该
--log-bin选项来指定替代位置，方法是在基本名称中添加前导绝对路径名以指定其他目录。当服务器从二进制日志索引文件中读取一个条目（该文件跟踪已使用的二进制日志文件）时，它将检查该条目是否包含相对路径。如果是这样，则将路径的相对部分替换为使用--log-bin选项。二进制日志索引文件中记录的绝对路径保持不变；在这种情况下，必须手动编辑索引文件以启用新路径。二进制日志文件的基本名称和任何指定的路径都可以用作log_bin_basename系统变量。在早期的MySQL版本中，默认情况下禁用二进制日志记录，如果指定了该
--log-bin选项，则启用二进制日志记录。从MySQL 8.0开始，无论您是否指定该--log-bin选项，默认情况下都会启用二进制日志记录。例外是，如果默认情况下禁用二进制日志记录，则使用mysqld通过使用--initializeor--initialize-insecure选项手动调用数据目录来初始化它。通过指定--log-bin选项，可以在这种情况下启用二进制日志记录。启用二进制日志记录后，log_bin将显示服务器上二进制日志记录状态的系统变量设置为ON。要禁用二进制日志记录，可以在启动时指定
--skip-log-bin或--disable-log-bin选项。如果指定了这些选项中的一个并且--log-bin也指定了该选项，则后面指定的选项优先。禁用二进制日志记录时，log_bin系统变量设置为OFF。在服务器上使用GTID时，如果在异常关闭后重新启动服务器时禁用了二进制日志记录，则某些GTID可能会丢失，从而导致复制失败。在正常关闭状态下，当前二进制日志文件中的GTID集会保存在
mysql.gtid_executed表。在未发生异常关闭（未发生这种情况）之后，在恢复过程中，只要仍启用了二进制日志记录，GTID就会从二进制日志文件添加到表中。如果在重新启动服务器时禁用了二进制日志记录，则服务器将无法访问二进制日志文件以恢复GTID，因此无法启动复制。正常关闭后，可以安全地禁用二进制日志记录。在
--log-slave-updates和--slave-preserve-commit-order选项需要二进制日志。如果禁用二进制日志记录，请忽略这些选项，或者指定--log-slave-updates=OFF和--skip-slave-preserve-commit-order。当指定--skip-log-bin或时，MySQL默认禁用这些选项--disable-log-bin。如果指定--log-slave-updates或--slave-preserve-commit-order连同--skip-log-bin或者--disable-log-bin，发出警告或错误信息。在MySQL 5.7中，启用二进制日志记录时必须指定服务器ID，否则服务器将无法启动。在MySQL 8.0中，
server_id系统变量默认设置为1。启用二进制日志记录后，现在可以使用该默认服务器ID启动服务器，但是如果您没有通过设置server_id系统变量来显式指定服务器ID，则会发出参考消息。对于复制拓扑中使用的服务器，必须为每个服务器指定一个唯一的非零服务器ID。有关二进制日志的格式和管理的信息，请参见“MySQL服务器二进制日志”。
--log-bin-index[=file_name]属性 值 命令行格式 --log-bin-index=file_name 系统变量 log_bin_index 范围 Global 动态 没有 SET_VAR提示适用没有 类型 文件名 二进制日志索引文件的名称，其中包含二进制日志文件的名称。默认情况下，它的位置和基本名称与使用
--log-bin选项加扩展名为二进制日志文件指定的值相同.index。如果未指定--log-bin，则默认的二进制日志索引文件名为binlog.index。如果指定的--log-bin选项不带任何字符串或为空字符串，则默认的二进制日志索引文件名是host_name-bin.index，使用主机名。有关二进制日志的格式和管理的信息，请参见“MySQL服务器二进制日志”。
语句选择选项。下表中的选项影响哪些语句被写入二进制日志，并因此由复制主服务器发送到其从属服务器。从服务器还有一些选项，用于控制应执行或忽略从主服务器接收的哪些语句。有关详细信息，请参见“复制从站选项和变量”。
--binlog-do-db=db_name属性 值 命令行格式 --binlog-do-db=name 类型 string 此选项以类似于
--replicate-do-db影响复制的方式影响二进制日志记录。此选项的效果取决于使用的是基于语句的记录格式还是基于行的日志记录格式，就像
--replicate-do-db依赖于使用的是基于语句的复制还是基于行的复制一样。您应该记住，用于记录给定语句的格式不一定与的值所表示的格式相同binlog_format。例如，DDL语句（例如CREATE TABLE和）ALTER TABLE始终作为语句记录，而不考虑有效的记录格式，因此以下基于语句的规则--binlog-do-db始终适用于确定是否记录该语句。基于语句的日志记录。只有那些语句被写入二进制日志，其中默认的数据库（也就是一个由选定的
USE）是db_name。要指定多个数据库，请多次使用此选项，每个数据库一次；但是，这样做不会导致跨数据库语句，例如在选择其他数据库（或未选择数据库）时记录跨数据库语句。UPDATE some_db.some_table SET foo='bar'警告
要指定多个数据库，您必须使用此选项的多个实例。因为数据库名称可以包含逗号，所以如果提供逗号分隔的列表，则该列表将被视为单个数据库的名称。
使用基于语句的日志记录时，可能无法正常工作的示例：如果服务器启动时
--binlog-do-db=sales发出以下语句，UPDATE则不会记录该语句：USE prices;UPDATE sales.januarySET amount=amount+1000;这种“仅检查默认数据库”行为的主要原因是，仅凭语句很难知道是否应复制它（例如，如果您使用的是多表
DELETE语句或UPDATE跨多个表起作用的多表语句）数据库）。如果不需要，仅检查默认数据库而不是所有数据库也更快。即使在设置选项时未指定给定数据库，复制给定数据库时也会发生另一种不言而喻的情况。如果服务器启动时
--binlog-do-db=sales，UPDATE即使prices设置时未包含以下语句，也会记录以下语句--binlog-do-db：USE sales;UPDATE prices.discountsSET percentage = percentage + 10;因为
sales是UPDATE发出该语句时的默认数据库，所以UPDATE会记录该数据库。基于行的日志记录。记录仅限于数据库
db_name。仅db_name记录对属于的表的更改；默认数据库对此没有影响。假设服务器从启动，--binlog-do-db=sales并且基于行的日志记录生效，然后执行以下语句：USE prices;UPDATE sales.februarySET amount=amount+100;数据库
february中表的更改将sales按照以下UPDATE语句记录：无论是否USE发出声明，都会发生这种情况。但是，当使用基于行的日志记录格式和时--binlog-do-db=sales，UPDATE不会记录以下内容所做的更改：USE prices;UPDATE prices.marchSET amount=amount-25;即使将
USE prices语句更改为USE sales，该UPDATE语句的效果仍不会写入二进制日志。--binlog-do-db与引用基于行的日志记录相比，处理基于语句的日志记录的另一个重要区别在于引用多个数据库的语句。假设服务器以启动--binlog-do-db=db1，并执行以下语句：USE db1;UPDATE db1.table1SET col1 = 10, db2.table2SET col2 = 20;如果使用的是基于语句的日志记录，则两个表的更新都将写入二进制日志。但是，当使用基于行的格式时，仅
table1记录对的更改；否则，将记录更改。table2在另一个数据库中，因此不会被更改UPDATE。现在，假设已使用USE db1一条USE db4语句代替该语句：USE db4;UPDATE db1.table1SET col1 = 10, db2.table2SET col2 = 20;在这种情况下，
UPDATE使用基于语句的日志记录时，不会将该语句写入二进制日志。但是，在使用基于行的日志记录时，将记录对的更改table1，而不记录对的更改，table2换句话说，仅--binlog-do-db记录对名为的数据库中表的更改，并且默认数据库的选择对此行为没有影响。--binlog-ignore-db=db_name属性 值 命令行格式 --binlog-ignore-db=name 类型 string 此选项以类似于
--replicate-ignore-db影响复制的方式影响二进制日志记录。此选项的效果取决于使用的是基于语句的记录格式还是基于行的日志记录格式，就像
--replicate-ignore-db依赖于使用的是基于语句的复制还是基于行的复制一样。您应该记住，用于记录给定语句的格式不一定与的值所表示的格式相同binlog_format。例如，DDL语句（例如CREATE TABLE和）ALTER TABLE始终作为语句记录，而不考虑有效的记录格式，因此以下基于语句的规则--binlog-ignore-db始终适用于确定是否记录该语句。基于语句的日志记录。告诉服务器无法登录，其中默认的数据库（即通过选择一个任何声明
USE）是db_name。如果没有默认数据库，则不
--binlog-ignore-db应用任何选项，并且始终记录此类语句。（缺陷＃11829838，错误＃60188）基于行的格式。告诉服务器不要将更新记录到数据库中的任何表中
db_name。当前数据库无效。When using statement-based logging, the following example does not work as you might expect. Suppose that the server is started with
--binlog-ignore-db=salesand you issue the following statements:USE prices;UPDATE sales.januarySET amount=amount+1000;该
UPDATE声明被记录在这样的情况下，因为--binlog-ignore-db只适用于默认数据库（由确定的USE语句）。因为sales在该语句中显式指定了数据库，所以该语句尚未过滤。但是，在使用基于行的日志记录时，该UPDATE语句的效果不会写入二进制日志，这意味着不会sales.january记录对表的任何更改。在这种情况下，--binlog-ignore-db=sales导致对主副本的表中的表进行的所有更改sales为了二进制日志记录而忽略的数据库。要指定多个要忽略的数据库，请多次使用此选项，每个数据库一次。因为数据库名称可以包含逗号，所以如果提供逗号分隔的列表，则该列表将被视为单个数据库的名称。
如果您正在使用跨数据库更新，并且您不想记录这些更新，则不应使用此选项。
校验和选项。 MySQL支持读写二进制日志校验和。使用此处列出的两个选项可以启用这些功能：
--binlog-checksum={NONE|CRC32}属性 值 命令行格式 --binlog-checksum=type 类型 string 默认值 CRC32 有效值 NONECRC32启用此选项会使主服务器为写入二进制日志的事件写入校验和。设置为
NONE禁用，或者设置为用于生成校验和的算法的名称；当前仅支持CRC32校验和，默认为CRC32。您不能在事务中更改此选项的设置。
要控制从属设备（从中继日志中）读取校验和，请使用该--slave-sql-verify-checksum选项。
测试和调试选项。以下二进制日志选项用于复制测试和调试。它们不适合在正常操作中使用。
--max-binlog-dump-events=N属性 值 命令行格式 --max-binlog-dump-events=# 类型 整数 默认值 0 MySQL测试套件在内部使用此选项进行复制测试和调试。
--sporadic-binlog-dump-fail属性 值 命令行格式 --sporadic-binlog-dump-fail[={OFF|ON}] 类型 布尔型 默认值 OFF MySQL测试套件在内部使用此选项进行复制测试和调试。
二进制日志记录使用的系统变量
下表描述了用于控制二进制日志记录的系统变量。可以在服务器启动时设置它们，其中一些可以在运行时使用进行更改SET。本节前面列出了用于控制二进制日志记录的服务器选项。
binlog_cache_size属性 值 命令行格式 --binlog-cache-size=# 系统变量 binlog_cache_size 范围 Global 动态 是 SET_VAR提示适用没有 类型 整数 默认值 32768 最低值 4096 最大值（64位平台） 18446744073709551615 最大值（32位平台） 4294967295 在事务期间，用于保存更改的二进制日志的内存缓冲区的大小。在服务器上启用二进制日志记录时（
log_bin系统变量设置为ON），如果服务器支持任何事务存储引擎，则会为每个客户端分配一个二进制日志缓存。如果用于事务的数据超过了内存缓冲区中的空间，则多余的数据将存储在一个临时文件中。当服务器上的二进制日志加密处于活动状态时，不会对内存缓冲区进行加密，但是（用于MySQL 8.0.17的）任何用于保存二进制日志缓存的临时文件都将被加密。提交每个事务后，通过清除内存缓冲区并截断临时文件（如果使用的话）来重置二进制日志缓存。如果您经常使用大型事务，则可以通过减少或消除写入临时文件的需要来增加此缓存的大小，以获得更好的性能。在
Binlog_cache_use与Binlog_cache_disk_use状态变量可以用于调整该变量的大小是有用的。请参见“MySQL服务器二进制日志”。binlog_cache_size设置仅事务高速缓存的大小；语句缓存的大小由binlog_stmt_cache_size系统变量控制。binlog_checksum属性 值 命令行格式 --binlog-checksum=name 系统变量 binlog_checksum 范围 Global 动态 是 SET_VAR提示适用没有 类型 string 默认值 CRC32 有效值 NONECRC32启用后，此变量使主服务器在二进制日志中为每个事件写入一个校验和。
binlog_checksum支持值NONE（禁用）和CRC32。默认值为CRC32。您无法更改binlog_checksum事务内的价值。当
binlog_checksum被禁用（值NONE），服务器验证它是只写写和检查每个事件的事件长度（而不是校验）完整的事件二进制日志。更改此变量的值会导致二进制日志被轮换。校验和总是写入整个二进制日志文件，而不是仅写入其中一部分。
将主服务器上的此变量设置为从服务器无法识别的值会导致从服务器将其自身的
binlog_checksum值设置为NONE，并由于错误而停止复制。（缺陷号＃13553750，错误号＃61096）如果考虑到与较早的从站的向后兼容性，则可能需要将该值显式设置为NONE。binlog_direct_non_transactional_updates属性 值 命令行格式 --binlog-direct-non-transactional-updates[={OFF|ON}] 系统变量 binlog_direct_non_transactional_updates 范围 Global, Session 动态 是 SET_VAR提示适用没有 类型 布尔型 默认值 OFF 由于并发问题，当事务同时包含对事务表和非事务表的更新时，从站可能会变得不一致。MySQL试图通过将非事务性语句写入事务高速缓存来保留这些语句之间的因果关系，事务高速缓存将在提交后刷新。但是，当代表事务对非事务表所做的修改对其他连接而言立即可见时，就会出现问题，因为这些更改可能不会立即写入二进制日志中。
该
binlog_direct_non_transactional_updates变量为该问题提供了一种可能的解决方法。默认情况下，此变量是禁用的。启用binlog_direct_non_transactional_updates会使对非事务表的更新直接写入二进制日志，而不是事务高速缓存。从MySQL 8.0.14开始，设置此系统变量的会话值是受限制的操作。会话用户必须具有足以设置受限会话变量的特权。请参见“系统变量特权”。
binlog_direct_non_transactional_updates仅适用于使用基于语句的二进制日志记录格式复制的语句；也就是说，它仅在binlog_formatis 的值STATEMENT或binlog_formatisMIXED和使用基于语句的格式复制给定语句时才有效。当二进制日志格式为ROW或binlog_format设置为MIXED且使用基于行的格式复制给定的语句时，此变量无效。重要
在启用此变量之前，必须确保事务表和非事务表之间没有依赖关系。这种依赖的一个例子就是声明
INSERT INTO myisam_table SELECT * FROM innodb_table。否则，这样的陈述很可能导致从机偏离主机。当二进制日志格式为
ROW或时，此变量无效MIXED。binlog_encryption属性 值 命令行格式 --binlog-encryption[={OFF|ON}] 介绍了 8.0.14 系统变量 binlog_encryption 范围 Global 动态 是 SET_VAR提示适用没有 类型 布尔型 默认值 OFF 为该服务器上的二进制日志文件和中继日志文件启用加密。
OFF是默认值。ON为二进制日志文件和中继日志文件设置加密。无需在服务器上启用二进制日志记录即可启用加密，因此您可以在没有二进制日志的从站上对中继日志文件进行加密。要使用加密，必须安装并配置密钥环插件以提供MySQL Server的密钥环服务。有关执行此操作的说明，请参见“ MySQL密钥环”。任何受支持的密钥环插件均可用于存储二进制日志加密密钥。首次启动启用了二进制日志加密的服务器时，将在初始化二进制日志和中继日志之前生成一个新的二进制日志加密密钥。此密钥用于为每个二进制日志文件（如果服务器启用了二进制日志记录）和中继日志文件（如果服务器具有复制通道）加密文件密码，并且从文件密码生成的其他密钥用于加密数据在文件中。中继日志文件针对所有通道进行了加密，包括组复制应用程序通道和激活加密后创建的新通道。二进制日志索引文件和中继日志索引文件从不加密。
如果在服务器运行时激活加密，则此时将生成一个新的二进制日志加密密钥。例外是，如果加密先前在服务器上处于活动状态，然后又被禁用，则在这种情况下，将再次使用之前使用的二进制日志加密密钥。立即旋转二进制日志文件和中继日志文件，并使用此二进制日志加密密钥对新文件以及所有后续二进制日志文件和中继日志文件的文件密码进行加密。服务器上仍然存在的现有二进制日志文件和中继日志文件不会自动加密，但是如果不再需要它们，则可以清除它们。
如果通过将
binlog_encryption系统变量更改为来停用加密OFF，则二进制日志文件和中继日志文件将立即旋转，并且所有后续日志记录均未加密。先前加密的文件不会自动解密，但是服务器仍然可以读取它们。在服务器运行时激活或停用加密需要SUPER特权或BINLOG_ENCRYPTION_ADMIN特权。组复制应用程序通道不包括在中继日志轮换请求中，因此，只有在常规使用中轮换其日志后，这些通道的未加密日志记录才开始。有关二进制日志文件和中继日志文件加密的更多信息，请参见“加密二进制日志文件和中继日志文件”。
binlog_error_action属性 值 命令行格式 --binlog-error-action[=value] 系统变量 binlog_error_action 范围 Global 动态 是 SET_VAR提示适用没有 类型 列举 默认值 ABORT_SERVER 有效值 IGNORE_ERRORABORT_SERVER控制当服务器遇到诸如无法写入，刷新或同步二进制日志之类的错误时发生的情况，该错误可能导致主服务器的二进制日志变得不一致，并且复制从服务器失去同步。
此变量默认为
ABORT_SERVER，这使得服务器在遇到二进制日志中的此类错误时会暂停日志记录并关闭服务器。重新启动后，将继续进行恢复，就像服务器意外停止一样（请参见“处理复制从设备的意外停止”）。当
binlog_error_action设置为IGNORE_ERROR，如果服务器遇到了这样的错误继续正在进行的交易，然后记录错误停止记录，并继续执行更新。要恢复二进制记录，log_bin必须再次启用二进制记录，这需要重新启动服务器。此设置提供了与旧版本MySQL的向后兼容性。binlog_expire_logs_seconds属性 值 命令行格式 --binlog-expire-logs-seconds=# 系统变量 binlog_expire_logs_seconds 范围 Global 动态 是 SET_VAR提示适用没有 类型 整数 默认值 2592000 最低值 0 最大值 4294967295 设置二进制日志的有效期限，以秒为单位。有效期结束后，可以自动删除二进制日志文件。在启动时和刷新二进制日志时可能会删除。如“ MySQL服务器日志”中所述，发生日志刷新。
默认的二进制日志有效期限为2592000秒，等于30天（30 * 24 * 60 * 60秒）。如果启动时既未设置
binlog_expire_logs_seconds也不推荐使用的系统变量，expire_logs_days则默认设置适用。如果变量之一的非零值binlog_expire_logs_seconds或expire_logs_days在启动时设置，则该值将用作二进制日志的有效期限。如果在启动时为这两个变量都设置了非零值，则将for的值binlog_expire_logs_seconds用作二进制日志的有效期，并expire_logs_days通过警告消息将其忽略。要禁用自动清除二进制日志，请为显式指定值0
binlog_expire_logs_seconds，而不为指定值expire_logs_days。为了与早期版本兼容，如果您显式指定的值为0expire_logs_days而不为指定值，则也将禁用自动清除binlog_expire_logs_seconds。在这种情况下，binlog_expire_logs_seconds不会应用默认值。要手动删除二进制日志文件，请使用以下
PURGE BINARY LOGS语句。请参见“ PURGE BINARY LOGS语句”。binlog_format属性 值 命令行格式 --binlog-format=format 系统变量 binlog_format 范围 Global, Session 动态 是 SET_VAR提示适用没有 类型 列举 默认值 ROW 有效值 ROWSTATEMENTMIXED此变量设置二进制日志格式，并且可以是任何一个
STATEMENT，ROW或MIXED。请参见“复制格式”。binlog_format可以在启动时或运行时进行设置，除了在某些情况下，无法在运行时更改此变量或导致复制失败（如后面所述）。默认值为
ROW。例外：在NDB群集中，默认值为MIXED; NDB群集不支持基于语句的复制。设置此系统变量的会话值是受限制的操作。会话用户必须具有足以设置受限会话变量的特权。请参见“系统变量特权”。
控制何时对该变量进行更改以及该效果持续多长时间的规则与其他MySQL服务器系统变量相同。有关更多信息，请参见“变量分配的SET语法”。
当
MIXED指定，基于语句的复制时，除了仅基于行的复制是保证导致正确的结果的情况。例如，当语句包含用户定义的函数（UDF）或该UUID()函数时，就会发生这种情况。有关设置每种二进制日志记录格式时如何处理存储程序（存储过程和函数，触发器和事件）的详细信息，请参见“存储程序二进制记录”。
当您无法在运行时切换复制格式时，会有一些例外情况：
- 无法从存储的函数或触发器中更改复制格式。
- 如果会话具有打开的临时表，则不能为该会话（
SET @@SESSION.binlog_format）更改复制格式。 - 如果任何复制通道都有打开的临时表，则不能全局（
SET @@GLOBAL.binlog_format或SET @@PERSIST.binlog_format）更改复制格式。 - 如果当前正在运行任何复制通道应用程序线程，则不能全局（
SET @@GLOBAL.binlog_format或SET @@PERSIST.binlog_format）更改复制格式。
在任何这些情况下尝试切换复制格式（或尝试设置当前复制格式）都会导致错误。但是，您可以随时使用
PERSIST_ONLY（SET @@PERSIST_ONLY.binlog_format）更改复制格式，因为此操作不会修改运行时全局系统变量值，并且仅在服务器重新启动后才生效。不存在任何临时表时，建议不要在运行时切换复制格式，因为仅在使用基于语句的复制时才记录临时表，而对于基于行的复制和混合复制，则不记录它们。
更改复制主服务器上的日志记录格式不会导致复制从属服务器更改其日志记录格式以匹配。如果复制从属服务器启用了二进制日志记录，则在复制进行过程中切换复制格式可能会导致问题，并且更改会导致从属服务器在使用
STATEMENT主服务器时使用格式日志记录ROW或MIXED格式日志记录。复制从设备无法将以ROW日志记录格式接收的二进制日志条目STATEMENT转换为在其自己的二进制日志中使用的格式，因此这种情况可能导致复制失败。有关更多信息，请参见“MySQL服务器二进制日志”。二进制日志格式会影响以下服务器选项的行为：
--replicate-do-db--replicate-ignore-db--binlog-do-db--binlog-ignore-db
这些效果将在各个选项的说明中详细讨论。
binlog_group_commit_sync_delay属性 值 命令行格式 --binlog-group-commit-sync-delay=# 系统变量 binlog_group_commit_sync_delay 范围 Global 动态 是 SET_VAR提示适用没有 类型 整数 默认值 0 最低值 0 最大值 1000000 控制二进制日志提交在将二进制日志文件同步到磁盘之前等待多少微秒。默认情况下
binlog_group_commit_sync_delay设置为0，表示没有延迟。设置binlog_group_commit_sync_delay为微秒延迟可使更多事务一次同步到磁盘上，从而减少了提交一组事务的总时间，因为较大的组每组需要较少的时间单位。当
sync_binlog=0或sync_binlog=1设置，由指定的延迟binlog_group_commit_sync_delay被应用于每个二进制日志提交组同步之前（或在的情况下sync_binlog=0，继续操作之前）。当sync_binlog设置为大于1的n值时，将在每n个二进制日志提交组之后应用延迟。设置
binlog_group_commit_sync_delay可以增加具有复制从属（或在故障转移后可能具有）的任何服务器上并行提交事务的数量，因此可以增加复制从属上的并行执行。要受益于此效果，必须slave_parallel_type=LOGICAL_CLOCK设置从属服务器，并且binlog_transaction_dependency_tracking=COMMIT_ORDER还设置了该效果会更显着。在调整设置时，必须同时考虑主机的吞吐量和从机的吞吐量binlog_group_commit_sync_delay。设置
binlog_group_commit_sync_delay还可以减少在fsync()具有二进制日志的任何服务器（主服务器或从属服务器）上对二进制日志的调用次数。请注意，设置会
binlog_group_commit_sync_delay增加服务器上事务的延迟，这可能会影响客户端应用程序。同样，在高度并行的工作负载上，延迟可能会增加争用并因此降低吞吐量。通常，设置延迟的好处胜于缺点，但应始终执行调整以确定最佳设置。binlog_group_commit_sync_no_delay_count属性 值 命令行格式 --binlog-group-commit-sync-no-delay-count=# 系统变量 binlog_group_commit_sync_no_delay_count 范围 Global 动态 是 SET_VAR提示适用没有 类型 整数 默认值 0 最低值 0 最大值 1000000 由中止指定的中止当前延迟之前等待的最大事务数
binlog_group_commit_sync_delay。如果binlog_group_commit_sync_delay设置为0，则此选项无效。binlog_max_flush_queue_time属性 值 命令行格式 --binlog-max-flush-queue-time=# 不推荐使用 是 系统变量 binlog_max_flush_queue_time 范围 Global 动态 是 SET_VAR提示适用没有 类型 整数 默认值 0 最低值 0 最大值 100000 binlog_max_flush_queue_time已弃用，并标记为在将来的MySQL版本中最终删除。以前，此系统变量控制着以毫秒为单位的时间，以便继续进行刷新之前继续从刷新队列中读取事务。它不再具有任何作用。binlog_order_commits属性 值 命令行格式 --binlog-order-commits[={OFF|ON}] 系统变量 binlog_order_commits 范围 Global 动态 是 SET_VAR提示适用没有 类型 布尔型 默认值 ON 在复制主数据库上启用此变量（默认设置）后，发给存储引擎的事务提交指令将在单个线程上序列化，因此事务始终以与写入二进制日志相同的顺序提交。禁用此变量将允许使用多个线程发出事务提交指令。与二进制日志组提交结合使用，可以防止单个事务的提交率成为吞吐量的瓶颈，并因此可以提高性能。
当所有涉及的存储引擎已确认准备提交事务时，将事务写入二进制日志。然后，二进制日志组提交逻辑将在二进制日志写操作完成后提交一组事务。什么时候
binlog_order_commits禁用此选项，因为此过程使用了多个线程，所以提交组中的事务可能以与二进制日志中的顺序不同的顺序提交。（来自单个客户端的事务始终按时间顺序提交。）在许多情况下，这无关紧要，因为在单独的事务中执行的操作应产生一致的结果，如果不是这样，则应改用单个事务。如果要确保主服务器和多线程复制从服务器上的事务历史记录保持相同，请
slave_preserve_commit_order=1在复制从服务器上进行设置。binlog_rotate_encryption_master_key_at_startup属性 值 命令行格式 --binlog-rotate-encryption-master-key-at-startup[={OFF|ON}] 介绍了 8.0.14 系统变量 binlog_rotate_encryption_master_key_at_startup 范围 Global 动态 没有 SET_VAR提示适用没有 类型 布尔型 默认值 OFF 指定在服务器启动时是否旋转二进制日志主密钥。二进制日志主密钥是二进制日志加密密钥，用于加密服务器上二进制日志文件和中继日志文件的文件密码。启用二进制日志加密的服务器首次启动（
binlog_encryption=ON）时，将生成一个新的二进制日志加密密钥，并将其用作二进制日志主密钥。如果binlog_rotate_encryption_master_key_at_startup系统变量也设置为ON，每当服务器重新启动时，就会生成另一个二进制日志加密密钥，并将其用作所有后续二进制日志文件和中继日志文件的二进制日志主密钥。如果binlog_rotate_encryption_master_key_at_startup系统变量设置为OFF，这是默认值，则在服务器重新启动后，将再次使用现有的二进制日志主密钥。有关二进制日志加密密钥和二进制日志主密钥的更多信息，请参见“加密二进制日志文件和中继日志文件”。binlog_row_event_max_size属性 值 命令行格式 --binlog-row-event-max-size=# 系统变量（>= 8.0.14） binlog_row_event_max_size 范围（>= 8.0.14） Global 动态（>= 8.0.14） 没有 SET_VAR提示适用（>= 8.0.14）没有 类型 整数 默认值 8192 最低值 256 最大值（64位平台） 18446744073709551615 最大值（32位平台） 4294967295 当使用基于行的二进制日志记录时，此设置是对基于行的二进制日志事件的最大大小（以字节为单位）的软限制。如果可能，将二进制日志中存储的行分组为大小不超过此设置的值的事件。如果事件无法拆分，则可以超过最大大小。该值必须是256的倍数（否则将被舍入为256）。默认值为8192字节。
该全局系统变量是只读的，只能在服务器启动时设置。因此，只能通过在语句中使用
PERSIST_ONLY关键字或@@persist_only限定符来修改其值SET。binlog_row_image属性 值 命令行格式 --binlog-row-image=image_type 系统变量 binlog_row_image 范围 Global, Session 动态 是 SET_VAR提示适用没有 类型 列举 默认值 full 有效值 full（记录所有列）minimal（仅记录更改的列以及标识行所需的列）noblob（记录所有列，但不需要的BLOB和TEXT列除外）对于MySQL基于行的复制，此变量确定如何将行图像写入二进制日志。
设置此系统变量的会话值是受限制的操作。会话用户必须具有足以设置受限会话变量的特权。请参见“系统变量特权”。
在MySQL基于行的复制中，每个行更改事件均包含两个图像：一个“ before ”图像，在搜索要更新的行时其列与之匹配；一个“ after ”图像包含更改。通常，MySQL会记录前后映像的完整行（即所有列）。但是，并不一定要在两个映像中都包括每一列，并且通过记录仅实际需要的那些列，我们通常可以节省磁盘，内存和网络使用量。
注意
删除行时，仅记录前映像，因为没有更改的值可在删除后传播。插入行时，由于没有现有行要匹配，因此仅记录后映像。仅当更新一行时，才需要前后图像，并且都将其写入二进制日志。
对于前一个映像，仅需要记录唯一标识行所需的最小列集。如果包含行的表具有主键，则仅将一个或多个主键列写入二进制日志。否则，如果表具有一个唯一键，其所有列均为
NOT NULL，则仅需要记录唯一键中的列。（如果表既没有主键又没有任何NULL列的唯一键，那么所有列都必须在前映像中使用并记录。）在后映像中，仅需要记录实际已更改的列。您可以使用
binlog_row_image系统变量使服务器记录完整或最少的行。该变量实际上采用三个可能值之一，如以下列表所示：full：记录前映像和后映像中的所有列。minimal：仅记录前映像中标识要更改的行所需的那些列；仅记录后映像中由SQL语句指定值或由自动增量生成的值的那些列。noblob：记录所有列（与相同full），除了BLOB和TEXT不需要标识行或未更改的列。
注意
NDB群集不支持该变量。设置它对
NDB表的日志记录没有影响。默认值为
full。使用
minimal或时noblob，如果且仅当源表和目标表都满足以下条件时，才能确保删除和更新对于给定表正确运行：- 所有列都必须以相同顺序出现。每列必须使用与另一张表中相同的数据类型。
- 这些表必须具有相同的主键定义。
（换句话说，这些表必须相同，但可能不属于表主键的索引除外）。
如果不满足这些条件，则目标表中的主键列值可能证明不足以为删除或更新提供唯一匹配。在这种情况下，不会发出警告或错误；主机和从机无声地分开，从而破坏了一致性。
当二进制日志记录格式为时，设置此变量无效
STATEMENT。当binlog_format为时MIXED，的设置binlog_row_image将应用于使用基于行的格式记录的更改，但是此设置对记录为语句的更改无效。binlog_row_image在全局或会话级别进行设置不会导致隐式提交。这意味着可以在进行交易时更改此变量，而不会影响交易。binlog_row_metadata属性 值 命令行格式 --binlog-row-metadata=metadata_type 系统变量 binlog_row_metadata 范围 Global 动态 是 SET_VAR提示适用没有 类型 列举 默认值 MINIMAL 有效值 FULL（包括所有元数据）MINIMAL（限制包含的元数据）使用基于行的日志记录时，配置添加到二进制日志中的表元数据的数量。设置为时
MINIMAL，默认情况下，仅记录与SIGNED标志，列字符集和几何类型有关的元数据。设置为FULL完整时，将记录表的元数据，例如列名ENUM或SET字符串值，PRIMARY KEY信息等。扩展的元数据用于以下目的：
- 当从站的表结构与主站的表结构不同时，从站将使用元数据来传输数据。
- 外部软件可以使用元数据来解码行事件，并将数据存储到外部数据库（例如数据仓库）中。
binlog_row_value_options属性 值 命令行格式 --binlog-row-value-options=# 系统变量 binlog_row_value_options 范围 Global, Session 动态 是 SET_VAR提示适用没有 类型 组 默认值 '' 有效值 PARTIAL_JSON 设置为时
PARTIAL_JSON，这将启用节省空间的二进制日志格式用于仅修改JSON文档的一小部分的更新，这将导致基于行的复制仅将JSON文档的修改后的部分写入后映像中，二进制日志中的更新（而不是写入完整的文档）。此作品为UPDATE它修改使用的任何序列的JSON列声明JSON_SET()，JSON_REPLACE()和JSON_REMOVE()。如果修改所需的空间大于完整文档的空间，或者服务器无法生成部分更新，则使用完整文档。设置此系统变量的会话值是受限制的操作。会话用户必须具有足以设置受限会话变量的特权。请参见“系统变量特权”。
PARTIAL_JSON是唯一支持的值；要取消设置binlog_row_value_options，请将其值设置为空字符串。binlog_row_value_options=PARTIAL_JSON仅在启用二进制日志记录并将binlog_format其设置为ROW或时，此选项才生效MIXED。基于语句的复制始终仅记录JSON文档的修改部分，而不管为设置的任何值binlog_row_value_options。要最大程度地节省空间，请使用binlog_row_image=NOBLOB或binlog_row_image=MINIMAL与该选项一起使用。binlog_row_image=FULL由于完整的JSON文档存储在前映像中，而部分更新仅存储在后映像中，因此比这两个方法都节省了更少的空间。mysqlbinlog输出包括使用
BINLOG语句编码为base-64字符串的事件形式的部分JSON更新。如果--verbose指定了该选项，则 mysqlbinlog使用伪SQL语句将部分JSON更新显示为可读JSON。如果无法对从属服务器上的JSON文档进行修改，则MySQL复制会产生错误。这包括找不到路径。请注意，即使进行了此检查和其他安全检查，如果从属服务器上的JSON文档与主服务器上的JSON文档有所不同，并且应用了部分更新，从理论上讲，仍然有可能在从属服务器上生成有效但意外的JSON文档。
binlog_rows_query_log_events属性 值 命令行格式 --binlog-rows-query-log-events[={OFF|ON}] 系统变量 binlog_rows_query_log_events 范围 Global, Session 动态 是 SET_VAR提示适用没有 类型 布尔型 默认值 OFF 此系统变量仅影响基于行的日志记录。启用后，它将导致服务器将诸如行查询日志事件之类的信息日志事件写入其二进制日志中。此信息可用于调试和相关目的，例如，当无法从行更新中重建原始查询时，获取原始查询。
设置此系统变量的会话值是受限制的操作。会话用户必须具有足以设置受限会话变量的特权。请参见“系统变量特权”。
这些信息事件通常被读取二进制日志的MySQL程序忽略，因此从备份复制或还原时不会引起任何问题。要参见它们，请通过
--verbose两次使用mysqlbinlog的选项as-vv或来增加详细级别--verbose --verbose。binlog_stmt_cache_size属性 值 命令行格式 --binlog-stmt-cache-size=# 系统变量 binlog_stmt_cache_size 范围 Global 动态 是 SET_VAR提示适用没有 类型 整数 默认值 32768 最低值 4096 最大值（64位平台） 18446744073709551615 最大值（32位平台） 4294967295 二进制日志的内存缓冲区的大小，用于保存事务期间发出的非事务性语句。在服务器上启用二进制日志记录时（
log_bin系统变量设置为ON），如果服务器支持任何事务存储引擎，则会为每个客户端分配单独的二进制日志事务和语句缓存。如果事务中使用的非事务性语句的数据超过了内存缓冲区中的空间，则多余的数据将存储在一个临时文件中。当服务器上的二进制日志加密处于活动状态时，不会对内存缓冲区进行加密，但是（用于MySQL 8.0.17的）任何用于保存二进制日志缓存的临时文件都将被加密。提交每个事务后，通过清除内存缓冲区并截断临时文件（如果使用的话）来重置二进制日志语句高速缓存。如果您在事务处理过程中经常使用大型非事务性语句，则可以通过减少或消除对临时文件的写入来增加此高速缓存的大小，以获得更好的性能。在
Binlog_stmt_cache_use与Binlog_stmt_cache_disk_use状态变量可以用于调整该变量的大小是有用的。请参见“MySQL服务器二进制日志”。该
binlog_cache_size系统变量设置为事务高速缓存的大小。binlog_transaction_dependency_tracking属性 值 命令行格式 --binlog-transaction-dependency-tracking=value 系统变量 binlog_transaction_dependency_tracking 范围 Global 动态 是 SET_VAR提示适用没有 类型 列举 默认值 COMMIT_ORDER 有效值 COMMIT_ORDERWRITESETWRITESET_SESSION对于具有多线程从属服务器（复制从属服务器
slave_parallel_workers的值设置为大于0 的复制主服务器），请binlog_transaction_dependency_tracking指定主服务器在二进制日志中记录的相关性信息源，以帮助从属服务器确定可以并行执行的事务。可能的值为：COMMIT_ORDER：依赖关系信息是从主机的提交时间戳生成的。这是默认值。WRITESET：依赖关系信息是从主服务器的写集生成的，并且可以对写入不同元组的任何事务进行并行化。WRITESET_SESSION：依赖关系信息是从主机的写集生成的，并且可以对写入不同元组的任何事务进行并行化处理，但不能对来自同一会话的两个更新进行重新排序。
WRITESET和WRITESET_SESSION模式不会提供比在COMMIT_ORDER模式下返回的事务依赖优化程度更低的任何事务依赖。当您将值设置为WRITESET或WRITESET_SESSION作为值时，主服务器将对COMMIT_ORDER具有空或部分写集的任何事务，对不具有主键或唯一键的表进行更新的任何事务以及对具有外键关系的父表进行更新的任何事务使用模式。要设置
WRITESET或WRITESET_SESSION作为的值binlog_transaction_dependency_tracking，transaction_write_set_extraction必须将其设置为指定算法（不设置为OFF）。MySQL 8.0中的默认transaction_write_set_extraction设置是XXHASH64。您选择的值transaction_write_set_extraction不能再次更改，而的值binlog_transaction_dependency_tracking仍为WRITESET或WRITESET_SESSION。保留的行散列数和检查是否已更改给定行的最新事务由值决定
binlog_transaction_dependency_history_size。对于组复制，设置
binlog_transaction_dependency_tracking=WRITESET_SESSION可以提高组成员的性能，具体取决于组的工作负载。在应用中继日志中的事务时，组复制在认证后执行其自身的并行化，而与的设置值无关binlog_transaction_dependency_tracking。但是，的值binlog_transaction_dependency_tracking确实影响将事务写入组复制成员上的二进制日志的方式。这些日志中的依赖项信息用于协助从捐助者的二进制日志进行状态转移的过程，以进行分布式恢复，只要成员加入或重新加入该组，就会发生这种情况。binlog_transaction_dependency_history_size属性 值 命令行格式 --binlog-transaction-dependency-history-size=# 系统变量 binlog_transaction_dependency_history_size 范围 Global 动态 是 SET_VAR提示适用没有 类型 整数 默认值 25000 最低值 1 最大值 1000000 设置行哈希值的上限，该行哈希值保留在内存中，用于查找最后修改给定行的事务。一旦达到此哈希数，便清除历史记录。
expire_logs_days属性 值 命令行格式 --expire-logs-days=# 不推荐使用 是 系统变量 expire_logs_days 范围 Global 动态 是 SET_VAR提示适用没有 类型 整数 默认值 0 最低值 0 最大值 99 指定自动删除二进制日志文件之前的天数。
expire_logs_days已不推荐使用，并将在以后的版本中删除。而是使用binlog_expire_logs_seconds，以秒为单位设置二进制日志的有效期限。如果您未为任何一个系统变量设置值，则默认有效期为30天。在启动时和刷新二进制日志时可能会删除。如“ MySQL服务器日志”中所述，发生日志刷新。expire_logs_days如果binlog_expire_logs_seconds也指定，则将忽略您指定的任何非零值，并将的值binlog_expire_logs_seconds用作二进制日志的有效期限。在这种情况下会发出警告消息。expire_logs_days如果binlog_expire_logs_seconds未指定或指定为0 ，则非零值仅用作二进制日志到期期限。要禁用自动清除二进制日志，请为显式指定值0
binlog_expire_logs_seconds，而不为指定值expire_logs_days。为了与早期版本兼容，如果您显式指定的值为0expire_logs_days而不为指定值，则也将禁用自动清除binlog_expire_logs_seconds。在这种情况下，binlog_expire_logs_seconds不会应用默认值。要手动删除二进制日志文件，请使用以下
PURGE BINARY LOGS语句。请参见“ PURGE BINARY LOGS语句”。log_bin属性 值 系统变量 log_bin 范围 Global 动态 没有 SET_VAR提示适用没有 类型 布尔型 显示服务器上二进制日志记录的状态（启用（
ON）或禁用（OFF））。启用二进制日志记录后，服务器会将所有更改数据的语句记录到二进制日志中，该日志用于备份和复制。ON表示二进制日志可用，OFF表示未使用。该--log-bin选项可用于指定二进制日志的基本名称和位置。在早期的MySQL版本中，默认情况下禁用二进制日志记录，如果指定了该
--log-bin选项，则启用二进制日志记录。从MySQL 8.0开始，默认情况下启用二进制日志记录，并且log_bin系统变量设置为ON，无论您是否指定该--log-bin选项。例外是，如果默认情况下禁用二进制日志记录，则使用mysqld通过使用--initializeor--initialize-insecure选项手动调用数据目录来初始化它。通过指定--log-bin选项，可以在这种情况下启用二进制日志记录。如果在启动时指定
--skip-log-bin或--disable-log-bin选项，则禁用二进制日志记录，并且log_bin系统变量设置为OFF。如果指定了这些选项中的一个并且--log-bin也指定了该选项，则后面指定的选项优先。有关二进制日志的格式和管理的信息，请参见“MySQL服务器二进制日志”。
log_bin_basename属性 值 系统变量 log_bin_basename 范围 Global 动态 没有 SET_VAR提示适用没有 类型 文件名 保留二进制日志文件的基本名称和路径，可以使用
--log-binserver选项设置。在MySQL 8.0中，如果--log-bin未提供该选项，则默认的基本名称为binlog。为了与MySQL 5.7兼容，如果提供的--log-bin选项不带字符串或带空字符串，则默认基本名称为host_name-bin，使用主机名。默认位置是数据目录。log_bin_index属性 值 命令行格式 --log-bin-index=file_name 系统变量 log_bin_index 范围 Global 动态 没有 SET_VAR提示适用没有 类型 文件名 保留二进制日志索引文件的基本名称和路径，可以使用
--log-bin-indexserver选项设置。log_bin_trust_function_creators属性 值 命令行格式 --log-bin-trust-function-creators[={OFF|ON}] 系统变量 log_bin_trust_function_creators 范围 Global 动态 是 SET_VAR提示适用没有 类型 布尔型 默认值 OFF This variable applies when binary logging is enabled. It controls whether stored function creators can be trusted not to create stored functions that will cause unsafe events to be written to the binary log. If set to 0(the default), users are not permitted to create or alter stored functions unless they have the
SUPERprivilege in addition to theCREATE ROUTINEorALTER ROUTINEprivilege. A setting of 0 also enforces the restriction that a function must be declared with theDETERMINISTICcharacteristic, or with theREADS SQL DATAorNO SQL特性。如果变量设置为1，MySQL不会在创建存储函数时强制执行这些限制。此变量也适用于触发器创建。请参见“存储程序二进制记录”。log_bin_use_v1_row_events属性 值 命令行格式 --log-bin-use-v1-row-events[={OFF|ON}] 不推荐使用 8.0.18 系统变量 log_bin_use_v1_row_events 范围 Global 动态 没有 SET_VAR提示适用没有 类型 布尔型 默认值 OFF 不建议使用此只读系统变量。
ON通过使用版本1二进制日志行事件而不是版本2二进制日志行事件写入二进制日志，将系统变量设置为在服务器启动时启用与运行MySQL Server 5.5及更早版本的从属的基于行的复制，而不是MySQL 5.6的默认版本2 。log_slave_updates属性 值 命令行格式 --log-slave-updates[={OFF|ON}] 系统变量 log_slave_updates 范围 Global 动态 没有 SET_VAR提示适用没有 类型 布尔型 默认值 ON 从服务器从主服务器收到的更新是否应记录到从服务器自己的二进制日志中。
启用此变量将导致从属服务器将从主服务器接收并由从属服务器的SQL线程执行的更新写入到从属服务器自己的二进制日志中。二进制日志记录（由
--log-bin选项控制，默认情况下已启用）也必须在从属服务器上启用才能记录更新。请参见“复制和二进制日志记录选项和变量”。log_slave_updates默认情况下启用，除非您指定--skip-log-bin禁用二进制日志记录，在这种情况下，MySQL默认还禁用从属更新日志记录。如果在启用二进制日志记录时需要禁用从属更新日志记录，请--log-slave-updates=OFF在从属服务器启动时指定。启用
log_slave_updates使复制服务器可以链接。例如，您可能要使用以下安排来设置复制服务器：A -> B -> C
在这里，
A充当从属主机B，并B充当从属主机C。为了使其正常工作，B必须既是主机又是从机。在启用和log_slave_updates启用二进制日志记录（这是默认设置）的情况下，从接收到的更新A将记录B到其二进制日志中，因此可以传递给C。log_statements_unsafe_for_binlog属性 值 命令行格式 --log-statements-unsafe-for-binlog[={OFF|ON}] 系统变量 log_statements_unsafe_for_binlog 范围 Global 动态 是 SET_VAR提示适用没有 类型 布尔型 默认值 ON 如果遇到错误1592，则控制是否将生成的警告添加到错误日志中。
master_verify_checksum属性 值 命令行格式 --master-verify-checksum[={OFF|ON}] 系统变量 master_verify_checksum 范围 Global 动态 是 SET_VAR提示适用没有 类型 布尔型 默认值 OFF 启用此变量将使主服务器通过检查校验和来验证从二进制日志读取的事件，并在不匹配的情况下因错误而停止。
master_verify_checksum默认情况下处于禁用状态；在这种情况下，主服务器使用二进制日志中的事件长度来验证事件，以便仅从二进制日志中读取完整的事件。max_binlog_cache_size属性 值 命令行格式 --max-binlog-cache-size=# 系统变量 max_binlog_cache_size 范围 Global 动态 是 SET_VAR提示适用没有 类型 整数 默认值 18446744073709551615 最低值 4096 最大值 18446744073709551615 如果事务需要的内存字节数超过此数量，则服务器将生成多语句事务，而该语句需要的存储错误数超过“ max_binlog_cache_size”字节。最小值为4096。最大可能值为16EiB（千兆字节）。推荐的最大值为4GB。这是由于MySQL当前无法使用大于4GB的二进制日志位置。
max_binlog_cache_size设置仅事务高速缓存的大小；语句缓存的上限由max_binlog_stmt_cache_size系统变量控制。max_binlog_cache_size与binlog_cache_size系统变量匹配的会话可见性；换句话说，更改其值仅影响更改该值后启动的新会话。max_binlog_size属性 值 命令行格式 --max-binlog-size=# 系统变量 max_binlog_size 范围 Global 动态 是 SET_VAR提示适用没有 类型 整数 默认值 1073741824 最低值 4096 最大值 1073741824 如果对二进制日志的写入导致当前日志文件的大小超过此变量的值，则服务器将旋转二进制日志（关闭当前文件并打开下一个日志）。最小值为4096字节。最大值和默认值为1GB。加密的二进制日志文件还有一个512字节的标头，该标头包含在中
max_binlog_size。事务以一个块的形式写入二进制日志，因此永远不会在多个二进制日志之间进行拆分。因此，如果您的交易量很大，您可能会看到二进制日志文件大于
max_binlog_size。如果
max_relay_log_size为0，则值也max_binlog_size适用于中继日志。在服务器上使用GTID的情况下
max_binlog_size，如果到达该时间，如果mysql.gtid_executed无法访问系统表以从当前二进制日志文件写入GTID，则二进制日志无法循环。在这种情况下，服务器将根据其binlog_error_action设置进行响应。如果IGNORE_ERROR设置为，则在服务器上记录错误，并停止二进制日志记录；如果ABORT_SERVER设置了，则关闭服务器。max_binlog_stmt_cache_size属性 值 命令行格式 --max-binlog-stmt-cache-size=# 系统变量 max_binlog_stmt_cache_size 范围 Global 动态 是 SET_VAR提示适用没有 类型 整数 默认值 18446744073709547520 最低值 4096 最大值 18446744073709547520 如果事务中的非事务性语句需要的内存量超过此字节数，则服务器将生成错误。最小值为4096。在32位平台上，最大值和默认值为4GB；在64位平台上，最大值和默认值为16EB（艾字节）。
max_binlog_stmt_cache_size设置仅用于语句缓存的大小；事务缓存的上限仅由max_binlog_cache_size系统变量控制。original_commit_timestamp属性 值 系统变量 original_commit_timestamp 范围 Session 动态 是 SET_VAR提示适用没有 类型 数字 供复制内部使用。在从属服务器上重新执行事务时，此时间设置为将事务提交到原始主服务器上的时间，以自纪元以来的微秒为单位。这允许原始提交时间戳在整个复制拓扑中传播。
设置此系统变量的会话值是受限制的操作。会话用户必须具有
REPLICATION_APPLIER特权（请参见“复制特权检查”）或具有足以设置受限会话变量的特权（请参见“系统变量特权”）。但是，请注意，该变量并非供用户设置。它是由复制基础结构自动设置的。sql_log_bin属性 值 系统变量 sql_log_bin 范围 Session 动态 是 SET_VAR提示适用没有 类型 布尔型 默认值 ON 此变量控制是否为当前会话启用到二进制日志的日志记录（假设二进制日志本身已启用）。默认值为
ON。要为当前会话禁用或启用二进制日志记录，请将会话sql_log_bin变量设置为OFF或ON。将该变量设置
OFF为一个会话，以在禁用不想复制到从属主机的更改时临时禁用二进制日志记录。设置此系统变量的会话值是受限制的操作。会话用户必须具有足以设置受限会话变量的特权。请参见“系统变量特权”。
无法设置
sql_log_bin事务或子查询中的会话值。设置此变量
OFF可防止将GTID分配给二进制日志中的事务。如果您使用GTID进行复制，则意味着即使稍后再次启用了二进制日志记录，从这一点开始写入日志的GTID也不考虑与此期间发生的任何事务，因此实际上这些事务会丢失。sync_binlog属性 值 命令行格式 --sync-binlog=# 系统变量 sync_binlog 范围 Global 动态 是 SET_VAR提示适用没有 类型 整数 默认值 1 最低值 0 最大值 4294967295 控制MySQL服务器将二进制日志同步到磁盘的频率。
sync_binlog=0：禁用MySQL服务器将二进制日志同步到磁盘的功能。取而代之的是，MySQL服务器依靠操作系统不时地将二进制日志刷新到磁盘上，就像处理其他任何文件一样。此设置提供最佳性能，但是在电源故障或操作系统崩溃的情况下，服务器可能提交了尚未同步到二进制日志的事务。sync_binlog=1：启用在提交事务之前将二进制日志同步到磁盘。这是最安全的设置，但由于磁盘写入次数增加，可能会对性能产生负面影响。如果出现电源故障或操作系统崩溃，二进制日志中缺少的事务将仅处于准备状态。这允许自动恢复例程回滚事务，从而保证二进制日志中不会丢失任何事务。sync_binlog=N，其中N的值不是0或1：是N二进制日志提交组已收集之后，二进制日志将同步到磁盘。在电源故障或操作系统崩溃的情况下，服务器可能提交了尚未刷新到二进制日志的事务。由于磁盘写入次数的增加，此设置可能会对性能产生负面影响。较高的值可以提高性能，但会增加数据丢失的风险。
为了在
InnoDB与事务一起使用的复制设置中获得最大的持久性和一致性，请使用以下设置：sync_binlog=1。innodb_flush_log_at_trx_commit=1。
警告
许多操作系统和某些磁盘硬件使“刷新磁盘”操作变得愚蠢。他们可能告诉mysqld刷新已经发生，即使没有发生。在这种情况下，即使使用建议的设置也无法保证事务的持久性，并且在最坏的情况下，停电可能会破坏
InnoDB数据。在SCSI磁盘控制器或磁盘本身中使用电池供电的磁盘缓存可以加快文件刷新的速度，并使操作更安全。您也可以尝试禁用硬件高速缓存中磁盘写入的高速缓存。transaction_write_set_extraction属性 值 命令行格式 --transaction-write-set-extraction[=value] 系统变量 transaction_write_set_extraction 范围 Global, Session 动态 是 SET_VAR提示适用没有 类型 列举 默认值 XXHASH64 默认值 OFF 有效值 OFFMURMUR32XXHASH64对于具有多线程从属服务器（复制从属服务器
slave_parallel_workers的值设置为大于0）的复制主服务器，其中binlog_transaction_dependency_tracking将其设置为WRITESET或WRITESET_SESSION从主服务器的写操作集生成依赖项信息，请transaction_write_set_extraction指定用于对事务期间提取的写操作进行哈希处理的算法。当
WRITESET或WRITESET_SESSION设置为的值时binlog_transaction_dependency_tracking，transaction_write_set_extraction必须设置为指定算法（不设置为OFF）。MySQL 8.0中的默认transaction_write_set_extraction设置是XXHASH64。虽然当前值binlog_transaction_dependency_tracking是WRITESET或WRITESET_SESSION，你不能改变的值transaction_write_set_extraction。对于组复制，
transaction_write_set_extraction必须将其设置为XXHASH64。组复制中使用从事务中提取写操作的过程对所有组成员进行冲突检测和认证。请参见“组复制要求”。从MySQL 8.0.14开始，设置此系统变量的会话值是受限制的操作。会话用户必须具有足以设置受限会话变量的特权。请参见“系统变量特权”。