1.错误日志（error log）
在配置文件中【mysqld safe】下有设置log-error的存放位置
2.查询日志（query log）
【mysqld】
普通查询日志：记录客户端连接信息和执行的SQL语句信息； #general_log（可以库中set global开启）= off general_log_file
慢查询日志：记录执行时间超出指定值的SQL语句，或没有走索引的语句 #long_query_time = 1（多长时间记录一次慢查询） log-slow-queries=/data/3306/slow.log log_queries_not_using_indexes=off，一般在配置文件中没有打开，否则对数据库的压力比较大
mysql> show variables like '%_log%'; #查看所有关于log的相关变量参数
3.二进制日志（binary log）
【mysqld】
记录对mysql更新的操作，即mysql-bin文件 #log_bin = on（记录binlog） sql_log_bin = on（临时，不记录binlog）
对应着配置文件中的log-bin log-slave-updates
show variables like '%log_bin%';
>>> binlog的三种模式
statement level模式：
每条会修改数据的SQL都会记录到master的bin-log中，slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql再次执行
优点：不需要记录每一行数据的变化，解决了行级模式的缺点，日质量少，减少IO，磁盘性能高，传输也会更快；
缺点：特定情况下SQL语句无法复制，sleep()函数，last_insert_id()存储过程等；
row level模式：
日志会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改
优点：bin-log中可以不记录执行的SQL语句的上下文相关的信息，仅仅只需记录哪一条记录被修改了；
可以解决某些特定情况下（特定情况下的存储过程，或function，或trigger的调用和触发）SQL语句无法复制的问题；
缺点：日志中记录的不是update对应的事件，而是记录每行的记录，bin-log会很大，尤其是alter table这种重建表的过程会产生惊人的日志量；
Mixed模式：
根据SQL语句来区分对待记录的日志形式，即在statement和row之间选一种。如update和delete等语句，还是会选择statement模式
>>> binlog的三种模式的配置方法 #可以在my.cnf中配置，也可在库中配置
mysql> show variables like '%binlog_format%';
+---------------+-----------+
| Variable_name | Value |
+---------------+-----------+
| binlog_format | STATEMENT |
+---------------+-----------+
mysql> set global binlog_format = 'ROW';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW |
+---------------+-------+
可以查看binlog看这种模式带来的影响：mysqlbinlog --base64-output=decode-rows -v mysql-bin.000016
2018年11月2日
祝好！