mysql decode语句_mysql--日志(8)

1.mysql数据库服务相关的几类日志文件

1.1 错误日志error log:记录mysql服务进程mysqld在启动、关闭或运行过程中遇到的几类日志文件

1.2 查询日志query log：

1.2.1 普通查询日志 general query log:记录客户端连接信息和执行的sql语句信息

1.2.2 慢查询日志 slow query log:记录执行时间超出指定值long_query_time 的sql语句。

1.3 二进制日志binary log:记录数据呗修改的相关信息

2.二进制文件配置在my.cnf中，log-bin参数值。

show variables like '%log_bin%';

log_bin ON 是否打开binlog记录的开关

sql_log_bin ON 临时记录不记录

错误日志文件配置在my.cnf中,log-error参数值。

普通查询日志，执行show variables like 'general%';即可查看开关状态加文件路径。可执行set global general_log=ON,来打开。

慢查询日志文件配置在my.cnf中，超过1秒就写。

long_query_time = 1

#log-slow-queries = /data/3306/slow.log

log_queries_not_using_indexes //没使用索引的语句记录到 log。该参数可通过show variables like '%index%'得到。

3.binlog日志的三种模式

3.1 statement level 模式

每一条会修改数据的sql都会记录到master的binlog中，slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql来再次执行。

优点：解决了row level下的缺点，不需要记录每一行数据的变化，减少binlog日志量，节约io，提高性能，因为只需要记录在master上所执行语句的细节，

以及执行语句时候的上下文的信息。

缺点： 由于MySQL发展快，很多新功能不断加入，使得mysql的复制遇到了挑战，目前已经发现有不少情况会造成复制出现问题，主要是修改数据的时候使用了

特定的函数或者功能的时候会出现，比如sleep()函数在有些版本中不能正确复制，在存储过程中使用了last_insert_id()函数，会使得slave和master得到不一致

的id，

3.2 row level行级模式

日志中会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改, 查看日志文件:mysqlbinlog --base64-output=decode-rows -v mysql-bin.000006

优点：清楚的记录下每一行数据修改的细节，容易立即，而且不会出现某些特定情况下的存储过程或者函数而导致无法被正确复制的问题

缺点：会产生大量的日志内容，尤其是update很多数据的时候，或者是当执行alter table之类的语句的时候，因为mysql对于alter table表结构变更语句的处理是整个表的

每一条记录都需要变动，实际就是重建表，那么该表的每一条记录都会被记录到日志中，

3.3 mixed 模式

前两种的结合，mysql会根据执行的每一条具体的sql语句来区分对待记录的日志形式，新版本的s level还是和以前一样，只记录执行语句，

而新版的r level模式被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候会以 s level来记录，

3.4 调整模式

3.4.1 查看模式

show variables like 'binlog_format';

3.4.2 在线修改立即生效

运行时修改：set session binlog_format='STATEMENT';// ROW/MIXED

全局生效：set global binlog_format='STATEMENT';//ROW/MIXED

永久生效，修改配置文件 binlog_format=mixed