## **Mysql binlog 日志有三种格式：** * Statement：语句 * MIXED：混合 * ROW：行 ***** ## **查看当前模式：** ``` show variables like '% format%'; ```  ## **如需更改模式：** vim my.cnf（在[mysqld] 模块中配置） ``` binlog_format=STATEMENT binlog_format=ROW binlog_format=MIXED ``` ***** ## **详细解释：** 1. row level 模式： 日志中会记录成每一行数据的修改，然后在 slave 端再对相 同的数据进行修改。 **优点：** bin‐log 中可以不记录执行的 sql 语句的上下文相关的 信息，仅仅只需要记录哪一条记录被修改了，修改成什么样 了。所以 row level 的日志的内容会非常清楚的记录下每一行 数据修改的细节。 **缺点：** row level 下，所有的执行的语句当记录到日志中的时 候，都将以每行记录的修改记录，这样可能会产生大量的日 志内容，比如有这样一条 update 语句：update product set owner\_member\_id='d',执行之后，日志中记录的不是这条 update 语句所对应的 event 事件(mysql 是以事件的形式来记 录 bin‐log 日志)，而是这条语句所更新的每一条记录的变化 情况，这样就记录了很多条记录被更新的事件。因此，bin‐log 日志的量会很大。 ***** 2. statement level 模式 每一条修改数据的 sql 都会记录到 master 的 bin‐log 中。slave 在复制的时候 sql 进程会解析成和原来 master 端执行过的相 同的 sql 来再次执行。 **优点：** statement level 下的优点，首先就是解决了 row level 下的缺点，不需要记录每一行数据的变化，减少 bin‐log 日志 量，节约 io，提高性能。因为他只需要记录在 master 上所执 繁星老师作品 繁星老师作品 行的语句的细节，以及执行语句时候的上下文的信息。 **缺点：** 由于它是记录的执行语句，所以为了让这些语句在 slave 端也能正确执行，那么他还必须记录每条语句在执行的 时候的一些相关信息，也就是上下文信息，以保证所有语句 在 slave 端被执行的时候能够得到和在 master 端执行时候相 同的结果。另外就是,由于 mysql 现在发展比较快，很多的新 功能加入，使 mysql 的复制遇到了不小的挑战,自然复制的时 候涉及到越复杂的内容，bug 也就越容易出现。在 statement level 下，目前已经发现的就有不少情况会造成 mysql 的复制 问题，主要是修改数据的时候使用了某些特定的函数或者功 能的时候会出现，比如 sleep()在有些版本就不能正确复制。 ***** 3. mixed 模式 实际上就是前两种模式的结合，在 mixed 模式下，mysql 会 根据执行的每一条具体的 sql 语句来区分对待记录的日志形 式，也就是在 statement 和 row 之间选一种。新版本中的 statement level 还是和以前一样，仅仅记录执行的语句。而 新版本的 mysql 中对 row level 模式被做了优化，并不是所有 的修改都会以 row level 来记录，像遇到表结构变更的时候就 会以 statement 模式来记录，如果 sql 语句确实就是 update 或者 delete 等修改数据的语句，那么还是会记录所有行的变更。 ***** ## **查看 binlog日志内容：** ``` // 去掉里面加密密文：‐‐base64‐output=DECODE‐ROWS mysqlbinlog  mysql‐bin.000002 –v ```