MySQL日志文件（转）

5.11. MySQL日志文件

5.11.1. 错误日志

5.11.2. 通用查询日志

5.11.3. 二进制日志

5.11.4. 慢速查询日志

5.11.5. 日志文件维护

MySQL 有几个不同的日志文件，可以帮助你找出mysqld 内部发生的事情：

日志文件	记入文件中的信息类型
错误日志	记录启动、运行或停止mysqld 时出 现的问题。
查询日志	记录建立的客户端连接和执行的语句。
更新日志	记录更改数据的语句。不赞成使用该日志。
二进制日志	记录所有更改数据的语句。还用于复制。
慢日志	记录所有执行时间超过long_query_time 秒的所有查询或不使用索引的查询。

默认情况下，所有日志创建于mysqld 数据目录中。通过刷新日志，你可以强制 mysqld 来关闭和重新打开日志文件（或者在某些情况下切换到一个新的日志）。当你执行一个FLUSH LOGS 语句或执行mysqladmin flush-logs 或mysqladmin refresh 时，出现日志刷新。参见13.5.5.2节，“FLUSH语法” 。

如果你正使用MySQL 复制功能，从复制服务器将维护更多日志文件，被称为接替日志。相关讨论参见第6章： MySQL中的复制 。

5.11.1. 错误日志

错误日志文件包含了当mysqld 启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。

如果mysqld 莫名其妙地死掉并且mysqld_safe 需要重新启动它，mysqld_safe 在错误日志中写入一条restarted mysqld 消息。如果mysqld 注意到需要自动检查或着修复一个表，则错误日志中写入一条消息。

在一些操作系统中，如果mysqld 死掉，错误日志包含堆栈跟踪信息。跟踪信息可以用来确定mysqld 死掉的地方。参见E.1.4节，“使用堆栈跟踪” 。

可以用--log-error[=file_name ] 选项来指定mysqld 保存错误日志文件的位置。如果没有给定file_name 值，mysqld 使用错误日志名host_name.err 并在数据目录中写入日志文件。如果你执行FLUSH LOGS ，错误日志用-old 重新命名后缀并且mysqld 创建一个新的空日志文件。( 如果未给出--log-error 选项，则不会重新命名）。

如果不指定--log-error ，或者( 在Windows 中) 如果你使用--console 选项，错误被写入标准错误输出stderr 。通常标准输出为你的终端。

在Windows 中，如果未给出--console 选项，错误输出总是写入.err 文件。

5.11.2. 通用查询日志

如果你想要知道mysqld 内部发生了什么，你应该用--log[=file_name ] 或-l [file_name ] 选项启动它。如果没有给定file_name 的值， 默认名是host_name .log 。 所有连接和语句被记录到日志文件。当你怀疑在客户端发生了错误并想确切地知道该客户端发送给mysqld 的语句时，该日志可能非常有用。

mysqld 按照它接收的顺序记录语句到查询日志。这可能与执行的顺序不同。这与更新日志和二进制日志不同，它们在查询执行后，但是任何一个锁释放之前记录日志。( 查询日志还包含所有语句，而二进制日志不包含只查询数据的语句）。

服务器重新启动和日志刷新不会产生新的一般查询日志文件( 尽管刷新关闭并重新打开一般查询日志文件) 。在Unix 中，你可以通过下面的命令重新命名文件并创建一个新文件：

shell> 
mv hostname.log hostname-old.log

shell> 
mysqladmin flush-logs

shell> 
cp hostname-old.log to-backup-directory

shell> 
rm hostname-old.log

在Windows 中，服务器打开日志文件期间你不能重新命名日志文件。你必须先停止服务器然后重新命名日志文件。然后，重启服务器来创建新的日志文件。

5.11.3. 二进制日志

二进制日志以一种更有效的格式，并且是事务安全的方式包含更新日志中可用的所有信息。

二进制日志包含了所有更新了数据或者已经潜在更新了数据（例如，没有匹配任何行的一个DELETE ）的所有语句。语句以“事件 ”的形式保存，它描述数据更改。

注 释：二进制日志已经代替了老的更新日志，更新日志在MySQL 5.1 中不再使用。

二进制日志还包含关于每个更新数据库的语句的执行时间信息。它不包含没有修改任何数据的语句。如果你想要记录所有语句（例如，为了识别有问题的查询），你应使用一般查询日志。参见5.11.2节，“通用查询日志” 。

二进制日志的主要目的是在恢复使能够最大可能地更新数据库，因为二进制日志包含备份后进行的所有更新。

二进制日志还用于在主复制服务器上记录所有将发送给从服务器的语句。参见第6章： MySQL中的复制 。

运行服务器时若启用二进制日志则性能大约慢1% 。但是，二进制日志的好处，即用于恢复并允许设置复制超过了这个小小的性能损失。

当用--log-bin[=file_name ] 选项启动时，mysqld 写入包含所有更新数据的SQL 命令的日志文件。如果未给出file_name 值， 默认名为-bin 后面所跟的主机名。如果给出了文件名，但没有包含路径，则文件被写入数据目录。建议指定一个文件名，原因参见A.8.1节，“MySQL中的打开事宜” 。

如果你在日志名中提供了扩展名( 例如，--log-bin=file_name.extension ) ，则扩展名被悄悄除掉并忽略。

mysqld 在每个二进制日志名后面添加一个数字扩展名。每次你启动服务器或刷新日志时该数字则增加。如果当前的日志大小达到max_binlog_size ，还会自动创建新的二进制日志。如果你正使用大的事务，二进制日志还会超过max_binlog_size ：事务全写入一个二进制日志中，绝对不要写入不同的二进制日志中。

为了能够知道还使用了哪个不同的二进制日志文件，mysqld 还创建一个二进制日志索引文件，包含所有使用的二进制日志文件的文件名。默认情况下与二进制日志文件的文件名相同，扩展名为'.index' 。你可以用--log-bin-index[=file_name ] 选项更改二进制日志索引文件的文件名。当mysqld 在运行时，不应手动编辑该文件；如果这样做将会使mysqld 变得混乱。

可以用RESET MASTER 语句删除所有二进制日志文件，或用PURGE MASTER LOGS 只删除部分二进制文件。参见13.5.5.5节，“RESET语法” 和13.6.1节，“用于控制主服务器的SQL语句” 。

二进制日志格式有一些已知限制，会影响从备份恢复。参见6.7节，“复制特性和已知问题” 。

保存程序和触发器的二进制日志的描述参见20.4节，“存储子程序和触发程序的二进制日志功能” 。

可以使用下面的mysqld 选项来影响记录到二进制日志知的内容。又见选项后面的讨论。

·         --binlog-do-db=db_name

告诉主服务器，如果当前的数据库( 即USE 选定的数据库) 是db_name ，应将更新记录到二进制日志中。其它所有没有明显指定的数据库  被忽略。如果使用该选项，你应确保只对当前的数据库进行更新。

对于CREATE DATABASE 、ALTER DATABASE 和DROP DATABASE 语句，有一个例外，即通过操作的数据库来决定是否应记录语句，而不是用当前的数据库。

一个不能按照期望执行的例子：如果用binlog-do-db=sales 启动服务器，并且执行USE prices; UPDATE sales.january SET amount=amount+1000 ； ，该语句不写入二进制日志。

·         --binlog-ignore-db=db_name

告诉主服务器，如果当前的数据库( 即USE 选定的数据库) 是db_name ，不应将更新保存到二进制日志中。如果你使用该选项，你应确保只对当前的数据库进行更新。

一个不能按照你期望的执行的例子：如果服务器用binlog-ignore-db=sales 启动，并且执行USE prices; UPDATE sales.january SET amount=amount+1000 ； ，该语句不写入二进制日志。

类似于--binlog-do-db ，对于CREATE DATABASE 、ALTER DATABASE 和DROP DATABASE 语句，有一个例外，即通过操作的数据库来决定是否应记录语句，而不是用当前的数据库。

要想记录或忽视多个数据库，使用多个选项，为每个数据库指定相应的选项。

服务器根据下面的规则对选项进行评估，以便将更新记录到二进制日志中或忽视。请注意对于CREATE / ALTER / DROP DATABASE 语句有一个例外。在这些情况下，根据以下规则，所创建、修改或删除的 数据库将代替当前的数据库。

1.    是否有binlog-do-db 或binlog-ignore-db 规则?

·         没有：将语句写入二进制日志并退出。

·         有：执行下一步。

2.    有一些规则( binlog-do-db 或binlog-ignore-db 或二者都有) 。当前有一个数据库( USE 是否选择了数据库?)?

·         没有：不要 写入语句，并退出。

·         有：执行下一步。

3.    有当前的数据库。是否有binlog-do-db 规则?

·         有：当前的数据库是否匹配binlog-do-db 规则?

o        有：写入语句并退出。

o        没有：不要写入语句，退出。

·         No ：执行下一步。

4.    有一些binlog-ignore-db 规则。当前的数据库是否匹配binlog-ignore-db 规则?

·         有：不要写入语句，并退出。

·         没有：写入查询并退出。

例如，只用binlog-do-db=sales 运行的服务器不将当前数据库不为sales 的语句写入二进制日志( 换句话说，binlog-do-db 有时可以表示“忽视其它数据库 ”) 。

如果你正进行复制，应确保没有从服务器在使用旧的二进制日志文件，方可删除它们。一种方法是每天一次执行mysqladmin flush-logs 并删除三天前的所有日志。可以手动删除，或最好使用PURGE MASTER LOGS ( 参见13.6.1节，“用于控制主服务器的SQL语句” ) ，该语句还会安全地更新二进制日志索引文件( 可以采用日期参数) 。

具有SUPER 权限的客户端可以通过SET SQL_LOG_BIN=0 语句禁止将自己的语句记入二进制记录。参见13.5.3节，“SET语法” 。

你可以用mysqlbinlog 实用工具检查二进制日志文件。如果你想要重新处理日志止的语句，这很有用。例如，可以从二进制日志更新MySQL 服务器，方法如下：

shell> 
mysqlbinlog log-file | mysql -h server_name

关于mysqlbinlog 实用工具的详细信息以及如何使用它，参见8.6节，“mysqlbinlog：用于处理二进制日志文件的实用工具” 。

如果你正使用事务，必须使用MySQL 二进制日志进行备份，而不能使用旧的更新日志。

查询结束后、锁定被释放前或提交完成后则立即记入二进制日志。这样可以确保按执行顺序记入日志。

对非事务表的更新执行完毕后立即保存到二进制日志中。对于事务表，例如BDB 或InnoDB 表，所有更改表的更新( UPDATE 、DELETE 或INSERT ) 被缓存起来，直到服务器接收到COMMIT 语句。在该点，执行完COMMIT 之前，mysqld 将整个事务写入二进制日志。当处理事务的线程启动时，它为缓冲查询分配binlog_cache_size 大小的内存。如果语句大于该值，线程则打开临时文件来保存事务。线程结束后临时文件被删除。

Binlog_cache_use 状态变量显示了使用该缓冲区( 也可能是临时文件) 保存语句的事务的数量。Binlog_cache_disk_use 状态变量显示了这些事务中实际上有多少必须使用临时文件。这两个变量可以用于将binlog_cache_size 调节到足够大的值，以避免使用临时文件。

max_binlog_cache_size( 默认4GB) 可以用来限制用来缓存多语句事务的缓冲区总大小。如果某个事务大于该值，将会失败并 回滚。

如果你正使用更新日志或二进制日志，当使用CREATE ... SELECT or INSERT ... SELECT 时，并行插入被转换为普通插入。这样通过在备份时使用日志可以确保重新创建表的备份。

请注意MySQL 5.1 值的二进制日志格式与以前版本的MySQL 不同，因为复制改进了。参见6.5节，“不同MySQL版本之间的复制兼容性” 。

默认情况下，并不是每次写入时都将二进制日志与硬盘同步。因此如果操作系统或机器( 不仅仅是MySQL 服务器) 崩溃，有可能二进制日志中最后的语句丢失了。要想防止这种情况，你可以使用sync_binlog 全局变量(1 是最安全的值，但也是最慢的) ，使二进制日志在每N 次二进制日志写入后与硬盘同步。参见5.3.3节，“服务器系统变量” 。即使sync_binlog 设置为1, 出现崩溃时，也有可能表内容和二进制日志内容之间存在不一致性。例如，如果使用InnoDB 表，MySQL 服务器处理COMMIT 语句，它将整个事务写入二进制日志并将事务提交到InnoDB 中。 如果在两次操作之间出现崩溃，重启时，事务被InnoDB 回滚，但仍然存在二进制日志中。可以用--innodb-safe-binlog 选项解决该问题，可以增加InnoDB 表内容和二进制日志之间的一致性。( 注释：在MySQL 5.1 中不需要--innodb-safe-binlog ；由于引入了XA 事务支持，该选项作废了）。

该选项可以提供更大程度的安全，还应对MySQL 服务器进行配置，使每个事务的二进制日志( sync_binlog =1 ) 和( 默认情况为真) InnoDB 日志与硬盘同步。该选项的效果是崩溃后重启时，在滚回事务后，MySQL 服务器从二进制日志剪切 回滚的InnoDB 事务。这样可以确保二进制日志反馈InnoDB 表的确切数据等，并使从服务器保持与主服务器保持同步( 不接收 回滚的语句) 。

请注意即使MySQL 服务器更新其它存储引擎而不是InnoDB ，也可以使用--innodb-safe-binlog 。在InnoDB 崩溃恢复时，只从二进制日志中删除影响InnoDB 表的语句/ 事务。如果崩溃恢复时MySQL 服务器发现二进制日志变短了( 即至少缺少一个成功提交的InnoDB 事务) ，如果sync_binlog =1 并且硬盘/ 文件系统的确能根据需要进行同步( 有些不需要) 则不会发生，则输出错误消息 (" 二进制日志< 名> 比期望的要小") 。在这种情况下，二进制日志不准确，复制应从主服务器的数据快照开始。

写入二进制日志文件和二进制日志索引文件的方法与写入MyISAM 表相同。参见A.4.3节，“MySQL处理磁盘满的方式” 。

5.11.4. 慢速查询日志

用--log-slow-queries[=file_name ] 选项启动时，mysqld 写一个包含所有执行时间超过long_query_time 秒的SQL 语句的日志文件。获得初使表锁定的时间不算作执行时间。

如果没有给出file_name 值， 默认未主机名，后缀为-slow.log 。如果给出了文件名，但不是绝对路径名，文件则写入数据目录。

语句执行完并且所有锁释放后记入慢查询日志。记录顺序可以与执行顺序不相同。

慢查询日志可以用来找到执行时间长的查询，可以用于优化。但是，检查又长又慢的查询日志会很困难。要想容易些，你可以使用mysqldumpslow 命令获得日志中显示的查询摘要来处理慢查询日志。

在MySQL 5.1 的慢查询日志中，不使用索引的慢查询同使用索引的查询一样记录。要想防止不使用索引的慢查询记入慢查询日志，使用--log-short-format 选项。参见5.3.1节，“mysqld 命令行选项” 。

在MySQL 5.1 中, 通过--log-slow-admin-statements 服务器选项，你可以请求将慢管理语句，例如OPTIMIZE TABLE 、ANALYZE TABLE 和 ALTER TABLE 写入慢查询日志。

用查询缓存处理的查询不加到慢查询日志中，因为表有零行或一行而不能从索引中受益的查询也不写入慢查询日志。

5.11.5. 日志文件维护

MySQL 服务器可以创建各种不同的日志文件，从而可以很容易地看见所进行的操作。参见5.11节，“MySQL日志文件” 。但是，你必须定期清理这些文件，确保日志不会占用太多的硬盘空间。

当启用日志使用MySQL 时，你可能想要不时地备份并删除旧的日志文件，并告诉MySQL 开始记入新文件。参见5.9.1节，“数据库备份” 。

在 Linux ( Redhat ) 的安装上，你可为此使用mysql-log-rotate 脚本。如果你从RPM 分发安装MySQL ，脚本应该自动被安装了。

在其它系统上，你必须自己安装短脚本，你可从cron 等入手处理日志文件。

你可以通过mysqladmin flush-logs 或SQL 语句FLUSH LOGS 来强制MySQL 开始使用新的日志文件。

日志清空操作做下列事情：

• 如果使用标准日志( --log ) 或慢查询日志( --log-slow-queries ) ，关闭并重新打开日志文件。( 默认为mysql.log 和`hostname`-slow.log ) 。
• 如果使用更新日志( --log-update ) 或二进制日志( --log-bin ) ，关闭日志并且打开有更高序列号的新日志文件。

如果你只使用更新日志，你只需要重新命名日志文件，然后在备份前清空日志。例如，你可以这样做：

shell> 
cd mysql-data-directory

shell> 
mv mysql.log mysql.old

shell> 
mysqladmin flush-logs

然后做备份并删除“mysql.old ” 。