MySQL Binary Log也就是常说的bin-log,是mysql执行改动产生的二进制日志文件，其主要作用有两个：
- Replication（主从数据库）:在master端开启binary log后，log会记录所有数据库的改动，然后slave端获取这个Log文件内容就可以在slave端进行同样的操作。
- 备份（数据恢复 ）：在某个时间点a做了一次备份，然后利用binary log记录从这个时间点a后的所有数据库的改动，然后下一次还原的时候，利用时间点a的备份文件和这个binary log文件，就可以将数据还原。
查看log文件：show binary logs, show master logs
重置log: reset master
删除部分日志： purge binary logs to 'log_name'|'date'
binlog三种格式的优缺点：
binlog模式总共可分为以下三种：row，statement，mixed
1.Row
日志中会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改，只记录要修改的数据，只有value，不会有sql多表关联的情况。
优点：在row模式下，bin-log中可以不记录执行的sql语句的上下文相关的信息，仅仅只需要记录那一条记录被修改了，修改成什么样了，所以row的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程和function，以及trigger的调用和出发无法被正确复制问题。
缺点：在row模式下，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。
mysql> insert into username(username) select * from aa;
ERROR 1146 (42S02): Table 'test.username' doesn't exist
mysql> insert into user(username) select * from aa;
Query OK, 1 row affected (0.01 sec)
Records: 1 Duplicates: 0 Warnings: 0
查看binlog
root@xuebinbin:/vobiledata/mysqllog# mysqlbinlog mysql-bin.000017
BINLOG '
63EfUBNQAAAALgAAAA8CAAAAAA8AAAAAAAEABHRlc3QABHVzZXIAAgIPAi0AAA==
63EfUBdQAAAAJgAAADUCAAAAAA8AAAAAAAEAAv/8BAAFYmFveXU=
'/*!*/;
### INSERT INTO test.user
### SET
### @1=4 /* SHORTINT meta=0 nullable=0 is_null=0 */
### @2='baoyu' /* VARSTRING(45) meta=45 nullable=0 is_null=0 */
# at 565
#120806 0:27:39 server id 80 end_log_pos 592 Xid = 20
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
由此可见，row模式是针对每一行的数据，而于关联表无关，它把关联中的相应数据记录在log中。这样一来会产生大量的数据。
2.statement
每一条会修改数据的sql都会记录到master的binlog中，slave在复制的时候sql进程会解析成和原来master端执行多相同的sql再执行。
优点：在statement模式下首先就是解决了row模式的缺点，不需要记录每一行数据的变化减少了binlog日志量，节省了I/O以及存储资源，提高性能。因为他只需要激励在master上所执行的语句的细节一届执行语句时候的上下的信息。
缺点：在statement模式下，由于他是记录的执行语句，所以，为了让这些语句在slave端也能正确执行，那么他还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以保证所有语句在slave端被执行的时候能够得到和在master端执行时候相同的结果。另外就是，由于mysql现在发展比较快，很多的新功能不断的加入，使mysql的复制遇到了不小的挑战，自然复制的时候涉及到越复杂的内容，bug也就越容易出现。在statement中，目前已经发现不少情况会造成Mysql的复制出现问题，主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现，比如：sleep()函数在有些版本中就不能被正确复制，在存储过程中使用了last_insert_id()函数，可能会使slave和master上得到不一致的id等等。由于row是基于每一行来记录的变化，所以不会出现，类似的问题。
mysql> insert into user(username) values('xuebinbin');
ERROR 1598 (HY000): Binary logging not possible. Message: Transaction level 'READ-COMMITTED' in InnoDB is not safe for binlog mode 'STATEMENT'
mysql> SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
-> ;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into user(username) values('xuebinbin');
Query OK, 1 row affected (0.00 sec)
查看binlog
root@xuebinbin:/vobiledata/mysqllog# mysqlbinlog mysql-bin.000008
BEGIN
/*!*/;
# at 174
#120806 14:47:35 server id 80 end_log_pos 202 Intvar
SET INSERT_ID=2/*!*/;
# at 202
#120806 14:47:35 server id 80 end_log_pos 311 Query thread_id=5 exec_time=0 error_code=0
use test/*!*/;
SET TIMESTAMP=1344235655/*!*/;
insert into user(username) values('xuebinbin')
/*!*/;
# at 311
#120806 14:47:35 server id 80 end_log_pos 338 Xid = 20
COMMIT/*!*/;
# at 338
#120806 14:53:18 server id 80 end_log_pos 357 Stop
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
结果发现statement是以sql记录形式记录的。这样的话一个sql就只记录一条，减少了大量的数据存储。
3.Mixed（该模式是STATEMENT和ROW的混合使用。）
早起的MySQL一直都只有基于statemen 的复制模式，直到5.1.5版本的MySQL才开始支持row 复制。从5.0 开始，MySQL的复制已经解决了大量老版本中出现的无法正确复制的问题。但是由于存储过程的出现，给 MySQL Replication 又带来了更大的新挑战。
从5.1.8 版本开始，MySQL 提供了除 Statement 和 Row 之外的第三种复制模式：Mixed，实际上就是前两种模式的结合。
在 Mixed 模式下，MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式，也就是在 statement 和 row 之间选择一种。
新版本中的 statment 还是和以前一样，仅仅记录执行的语句。而新版本的 MySQL 中对 row 模式也被做了优化，并不是所有的修改都会以 row 模式来记录，比如遇到表结构变更的时候就会以 statement 模式来记录，如果 SQL 语句确实就是 update 或者 delete 等修改数据的语句，那么还是会记录所有行的变更。
示例：
1.开启binary log功能
需要修改mysql的配置文件，本篇的实验环境是win7，配置文件为mysql安装目录MySQL Server 5.1下的my.ini，添加一句log_bin = mysql_bin即可
eg：
[mysqld]
......
log_bin = mysql_bin
......
log_bin是生成的bin-log的文件名，后缀则是6位数字的编码，从000001开始，按照上面的配置，生成的文件则为：
mysql_bin.000001
mysql_bin.000002
......
命令行登录mysql:(密码之间不要有空格)
./usr/local/bin/mysql -h 192.168.9.65 -P 3306 -u root -p12345678
配置保存以后重启mysql的服务器，用show variables like '%bin%'查看bin-log是否开启，如图： 
2.查看产生的binary log
bin-log因为是二进制文件，不能通过记事本等编辑器直接打开查看，mysql提供两种方式查看方式，在介绍之前，我们先对数据库进行一下增删改的操作，否则log里边数据有点空。
示例：
create table bin( id int(10) primary key auto_increment,name varchar(255));#(测试前我已经建表) insert into bin(name) values ('orange');
1.show master status;查看当前的binlog文件是哪个
2.在客户端中使用 show binlog events in 'mysql_bin.000002' 语句进行查看,为了排序美观，可以在结尾加G使结果横变纵，此时结尾无需加；语句结束符。
mysql> show binlog events in 'mysql_bin.000002'G ...............省略............... *************************** 3. row *************************** Log_name: mysql_bin.000002 Pos: 174 Event_type: Intvar Server_id: 1 End_log_pos: 202 Info: INSERT_ID=2 *************************** 4. row *************************** Log_name: mysql_bin.000002 Pos: 202 Event_type: Query Server_id: 1 End_log_pos: 304 Info: use `test`; insert into bin(name) values ('orange') *************************** 5. row *************************** ...............省略...............
说明：
Log_name:此条log存在那个文件中，从上面可以看出这2条log皆存在与mysql_bin.000001文件中。
Pos:log在bin-log中的开始位置
Event_type:log的类型信息
Server_id:可以查看配置中的server_id,表示log是那个服务器产生
End_log_pos：log在bin-log中的结束位置
Info:log的一些备注信息，可以直观的看出进行了什么操作
3.用mysql自带的工具mysqlbinlog,这是我们就需要知道bin-log存在硬盘的什么位置，win7默认存在C:ProgramDataMySQLMySQL Server 5.1data文件夹下面，如果没有此文件夹，那我们可以通过配置文件中的 datadir="C:/ProgramData/MySQL/MySQL Server 5.1/Data/" 定位，如果还没有，那我就会说“各个系统的搜索功能都做的不错！”。这种查看方式就没那个美观了，如下
C:ProgramDataMySQLMySQL Server 5.1data>mysqlbinlog mysql_bin.000001
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#140215 16:35:56 server id 1 end_log_pos 106 Start: binlog v 4, server v 5.1.51-community-log created 140215 16:35:56 at startup
ROLLBACK/*!*/;
BINLOG '
7Mp7UA8BAAAAZgAAAGoAAAAAAAQANS4xLjUxLWNvbW11bml0eS1sb2cAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAADsyntQEzgNAAgAEgAEBAQEEgAAUwAEGggAAAAICAgC
'/*!*/;
# at 106
#140215 16:36:51 server id 1 end_log_pos 174 Query thread_id=2 exec_time=0 error_code=0
SET TIMESTAMP=1350290211/*!*/;
SET @@session.pseudo_thread_id=2/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=1, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1344274432/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 174
#140215 16:36:51 server id 1 end_log_pos 202 Intvar
SET INSERT_ID=3/*!*/;
# at 202
#140215 16:36:51 server id 1 end_log_pos 309 Query thread_id=2 exec_time=0 error_code=0
use test/*!*/;
SET TIMESTAMP=1350290211/*!*/;
insert into bin(name) values('xishizhaohua')
/*!*/;
# at 309
#140215 16:36:51 server id 1 end_log_pos 336 Xid = 28
COMMIT/*!*/;
# at 336
#140215 16:37:25 server id 1 end_log_pos 379 Rotate to mysql_bin.000002 pos: 4
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
虽然排版有点乱，但从图中我们可以得到更多信息，如时间戳，自增的偏移，是否自动提交事务等信息。如下图为从中提取的一部分。 
3.利用bin_log恢复数据(date与position)
1.最长用的就是恢复指定数据端的数据了，可以直接恢复到数据库中：
mysqlbinlog --start-date="2014-02-18 16:30:00" --stop-date="2014-02-18 17:00:00" mysql_bin.000001 |mysql -uroot -p123456
亦可导出为sql文件，再导入至数据库中：
mysqlbinlog --start-date="2014-02-18 16:30:00" --stop-date="2014-02-18 17:00:00" mysql_bin.000001 >d:1.sql
source d:1.sql
2.指定开始结束位置，从上面的查看产生的binary log我们可以知道某个log的开始到结束的位置，我们可以在恢复的过程中指定回复从A位置到B位置的log.需要用下面两个参数来指定：
--start-positon="50" //指定从50位置开始
--stop-postion="100"//指定到100位置结束
最后介绍几个bin_log的操作：
1.查看最后一个bin日志文件是那个，现在位置。
show master status;
2.启用新的日志文件，一般备份完数据库后执行。
flush logs;
3.清空现有的所用bin-log
reset master;
