对MySQL日志操作的一些基本命令总结

MySQL日志主要包含：错误日志、查询日志、慢查询日志、事务日志、二进制日志；

日志是mysql数据库的重要组成部分 。日志文件中记录着mysql数据库运行期间发生的变化；也就是说用来记录mysql数据库的客户端连接状况、SQL语句的执行情况和错误信息等 。当数据库遭到意外的损坏时，可以通过日志查看文件出错的原因，并且可以通过日志文件进行数据恢复 。

错误日志

在mysql数据库中，错误日志功能是默认开启的 。并且，错误日志无法被禁止 。默认情况下，错误日志存储在mysql数据库的数据文件中 。错误日志文件通常的名称为hostname.err 。其中，hostname表示服务器主机名 。

错误日志信息可以自己进行配置的，错误日志所记录的信息是可以通过log-error和log-warnings来定义的，其中log-err是定义是否启用错误日志的功能和错误日志的存储位置，log-warnings是定义是否将警告信息也定义至错误日志中 。默认情况下错误日志大概记录以下几个方面的信息：服务器启动和关闭过程中的信息（未必是错误信息，如mysql如何启动InnoDB的表空间文件的、如何初始化自己的存储引擎的等等）、服务器运行过程中的错误信息、事件调度器运行一个事件时产生的信息、在从服务器上启动服务器进程时产生的信息 。

下面我们来定义mysql错误日志的功能：

一般而言，日志级别的定义没有回话变量都只是在全局级别下进行定义 。

是否启用了日志

mysql>show variables like log_bin;

mysql> show master status;

shell>mysqlbinlog mail-bin.000001

shell>mysqlbinlog mail-bin.000001 | tail

在5.6及以上版本一定要手动指定 。5.6以下版本默认file_name为$datadir/mysqld-binlog
二进制日志用于记录所有更改数据的语句 。主要用于复制和即时点恢复 。
查看二进制日志的工具为：mysqlbinlog
二进制日志包含了所有更新了数据或者已经潜在更新了数据（例如，没有匹配任何行的一个DELETE）的所有语句 。语句以“事件”的形式保存，它描述数据更改 。二进制日志还包含关于每个更新数据库的语句的执行时间信息 。它不包含没有修改任何数据的语句 。
二进制日志的主要目的是在数据库存在故障时，恢复时能够最大可能地更新数据库（即时点恢复），因为二进制日志包含备份后进行的所有更新 。二进制日志还用于在主复制服务器上记录所有将发送给从服务器的语句 。
那么二进制日志是记录执行的语句还是执行后的结果数据呢？
第一种情况：
加入一个表有10万行数据，而现在要执行一个如下语句将amount字段的值全部在原来的基础上增加1000：

UPDATE sales.january SET amount=amount+1000；

此时如果要记录执行后的结果数据的话，日志会非常大 。
因此在这种情况下应记录执行语句 。这种方式就是基于语句的二进制日志 。
第二种情况：
如果向某个字段插入的是当前的时间呢？如下：

INSERT INTO tb SET Birthdate=CURRENT_TIME();

此时就不能记录语句了，因为不同时间执行的结果是不一样的 。这是应该记录这一行的值，这种就是基于行（row）的二进制日志 。
在有些情况，可能会结合两种方式来记录，这种叫做混合方式的二进制日志 。
二进制日志记录时间：
默认情况下，并不是每次写入时都将二进制日志与硬盘同步 。因此如果操作系统或机器(不仅仅是MySQL服务器)崩溃，有可能二进制日志中最后的语句丢失了 。要想防止这种情况，你可以使用sync_binlog全局变量(1是最安全的值，但也是最慢的)，使二进制日志在每N次二进制日志写入后与硬盘同步 。
对非事务表的更新执行完毕后立即保存到二进制日志中 。对于事务表，例如BDB或InnoDB表，所有更改表的更新(UPDATE、DELETE或INSERT) 被缓存起来，直到服务器接收到COMMIT语句 。在该点，执行完COMMIT之前，mysqld将整个事务写入二进制日志 。当处理事务的线程启动时，它为缓冲查询分配binlog_cache_size大小的内存 。如果语句大于该值，线程则打开临时文件来保存事务 。线程结束后临时文件被删除 。

日志恢复：(数据库备份时间：2013-02-30 10:10:10 数据出错前一刻时间:2013-02-30 10:10:10)
利用mysqlbinlog.exe工具
(1)打开cmd，进入到日志目录下
(2)恢复备份数据库
(3)重新执行从备份数据库开始到出错前一刻日志，
例如1：用时间段恢复

mysqlbinlog --start-datetime="2013-02-30 10:10:10" --stop-datetime="2013-02-30 10:10:10" log.00001 | mysql -uroot -p123456

由于在测试中发现，用时间进行恢复，恢复这个时间段sql并不准确，特此标注（待研究）
例如2：用日志位置进行恢复（必须打开日志，确定开始恢复日志位置和出错前日志的位置）
     (A):

mysqlbinlog log.00001 >F:log.sql

-- 把二进制文件log.00001导入文件日志log.sql中
     (B):打开log.sql日志文件，确定恢复点
     (C):

mysqlbinlog --start-position="5230766" --stop-position="5231104" PC-201304011235-bin.000001 | mysql -uroot -p111111

备注：必须加上|后面mysql信息，重新执行这段点之间日志