MySQL日志管理

一：日志的组成部分

         1.1错误日志

         1.2一般查询日志

         1.3慢查询日志

         1.4二进制日志

         1.5中继日志

         1.6事务日志

二：存储引擎介绍

         2.1 MyISAM

         2.2 InnoDB

         2.3 MRG_MYISAM

         2.4 CSV

         2.5 ARCHIVE
         2.6 MEMORY

         2.7 BLACKHOLE

1.1错误日志：

    主要是用于记录服务器运行当中的错误信息

    服务器启动或者关闭过程中产生的信息

    从服务器上启动服务器进程时产生的信息

    事件调度器运行一个事件时产生的信息

    警告信息

1.2一般查询日志：

    任何一个查询语句所产生的日志信息都要记录下来，所以信息量比较大，所以一般查询日志默认是不开启的

1.3慢查询日志：

    一般查询日志和慢查询日志都是查询日志，只不过慢查询日志记录的是查询时间比较长的，超出long_query_time定义的时间长度，默认为10秒，慢查询，可以启动慢查询日志，以记录哪些查询的执行速度比较慢，帮我们去定位问题的，定位服务器性能问题，

但是执行查询速度慢，并不意味着，这个查询本身慢，可能是因为其它资源占用导致它无法获取有效的资源而无法执行查询，以为慢查询的查询时间评估是根据它从开始启动这个查询到，查询结束这个时间，而不是在CPU上执行的时间

1.4二进制日志

1.4.1二进制日志当中所记录的每一个信息或者每一个操作，我们称之为一个二进制日志事件

1.4.2二进制日志的主要功能

    1.复制

    2.即时点恢复

1.4.3二进制日志事件是基于什么来实现的呢？

    1.可以基于语句：statement

    2.还可以基于行：row

    3.混合方式（基于语句和基于行）：mixed

1.4.4基于行好？还是基于语句好呢？

    基于语句：可能一条语句会操纵大量数据，但有可能会带来非精确值，例如带当前时间的操作

    基于行：直接复制这个语句的结果，直接复制相关数据而不是语句，以便产生精确值

    混合方式：mixed

1.4.5二进制日志的存放位置

    二进制日志自己会滚动的，默认存放在数据目录下，但是建议一定不要和数据目录放到同一个存储设备上，因为每一次存储设备的IO操作（就是每一次数据的写操作），都会引起二进制日志的写操作，所以两者都会产生IO，那也就意味着，放到同一块磁盘上，两个IO会生成竞争，所以这本身就会带来性能低下的状况，所以建议一定不要存放到同一块磁盘上，

而且为了避免由于数据文件所在是设备损坏，也导致二进制日志文件损坏，所以要分开存储

（总结：两个原因：1性能。2：数据可靠性、安全性）

1.4.6查看当前系统上被服务器识别的二进制日志

mysql> SHOW BINARY logs;

1.4.7当前使用的二进制日志

mysql> SHOW MASTER STATUS;

1.4.8查看某个日志中的事件

语法：mysql>SHOW BINLOG EVENTS IN ‘二进制文件名‘ [FROMPOSITION];

mysql> SHOW BINLOG EVENTS IN ‘mysql-bin.000006‘;

mysql> SHOW BINLOG EVENTS IN ‘mysql-bin.000006‘ FROM 379;

1.4.9在备份以后，需要清除某个日志文件之前的日志文件

mysql> PURGE BINARY LOGS TO ‘mysql-bin.000006‘;

1.4.10手动滚动一下二进制日志

mysql> FLUSH LOGS;

1.4.11详细查看数据库输出二进制日志文件中的内容

mysqlbinlog 
    --start-position
    --stop-position
    --start-datetime ‘yyyy-MM-dd hh:mm:ss‘
    --stop-datetime ‘yyyy-MM-dd hh:mm:ss‘

1.4.12和log相关的服务器变量说明

mysql> SHOW GLOBAL VARIABLES LIKE ‘%log%‘;

binlog_format：二进制日志的格式

binlog_cache_size：二进制日志缓存大小，它的值的上限取决于binlog_stmt_cache_size

binlog_stmt_cache_size：和事务相关的二进制日志语句缓存大小

log_bin：是否启用二进制日志，所以上面的缓存大小（binlog_stmt_cache_size）是否生效还要取决于此指令

注意，二进制日志功能的开启，并不意味着它就一定会记录二进制日志，它是总开关，是要不要记录二进制日志，如果要记录的话，它就可能给我们所指定的二进制日志文件中记录日志了。这个log_bin它还可以接受一个文件路径，表示把二进制日志文件记录到另外一个位置，否则只写个on它就表示记录在mysql的数据目录下，叫mysql-bin0001  0002，它指定了二进制文件是否启用，到底记录在哪个文件中，而是否真正的记录日志，还要取决于另外一个指定sql_log_bin

sql_log_bin：是用于控制是否记录二进制日志文件的，而log_bin是指定二进制文件的输出路径的，如果把它的值设置为off，就算你写了很多DML或者DDL语句，它也不会记录相关信息。这个指令非常重要，尤其是在将来实现数据库恢复的时候，比方说，mysql服务器奔溃了，我做了逻辑备份，需要把备份文件导入到数据库中，将数据恢复到某一个时刻在这个恢复的过程当中，应该把二进制日志的功能关掉了，当恢复结束之后，再开启

sync_binlog:多长时间同步一次二进制日志

expire_logs_days：日志的过期天数，例如值为30，那么日志文件超过30天以后会自动删除，所以二进制日志是可以自动的去清理的

1.4.13二进制日志为什么要做缓存呢？

1.5中继日志

    从服务器上，从主服务器的二进制日志文件中复制而来的事件并保存为的日志文件

1.6事务日志：ACID将随机IO转换为顺序IO

    事务性存储引擎用于保证原子性、一致性、隔离性和持久性

    innodb_flush_log_at_trx_commit={0|1|2}

        0:没秒同步，并执行磁盘flush操作

        1:每事务同步，并执行磁盘flush操作

        2:每事务同步，但不执行磁盘flush操作

    innodb_log_buffer_size：内存缓存大小

    innodb_log_file_size：日志文件大小

    innodb_log_files_in_group：日志写满了，需要向另外一个文件去写，这些文件就构成事务日志组，这里的值为2表示，有两个日志文件

    innodb_log_group_home_dir：事务日志存放的位置，默认为“./”，这个当前目录指的是数据目录

    innodb_mirrored_log_groups：是否为日志组做镜像

2.存储引擎介绍

2.1MyISAM：mysql5.5.8之前默认的存储引擎

    数据存储格式：

        表格式.frm

        数据文件.MYD

        索引文件.MYI

    特点：

        1.不支持事务，所以也没有基于事务的特性ACID，所以就少了很多额外的开销所以性能好，但是未必就一定性能好，也就是说事务性存储引擎未必就性能差

        2.由于它不支持事务，导致它的很多操作都比较粗糙，比如，不支持外键。

        3.MyISAM默认情况下只支持表锁，锁粒度比较大，导致并发能力不强。锁本身有些是共享的，比如读锁，所以在读操作非常多的场景下，MyISAM有很好的表现而对于读写操作都一样多的时候，MyISAM性能很差

        4.支持索引类型比较多，B树索引，全文（FULLTEXT）索引，空间索引，表压缩

2.2InnoDB：

    表格式.frm

    表空间.ibd 默认情况下MySQL将所有的事务表放到一个表空间中，我们要想使用很多InnoDB的高级特性，比如表压缩，单表导入导出，备份  比如每表一个表空间

    事务性引擎

    行级锁

    支持B树索引，聚簇索引，自适应hash索引

    使用表空间，支持使用raw磁盘设备，它可以将数据放在没有文件系统的磁盘分区上

2.3MRG_MYISAM：

         能够将两个或两个以上的MyISAM表合并成一张表处理

2.4CSV：利用文本文件来存储数据，方便移植，但不管理起来性能比较差

2.5ARCHIVE：归档的，主要目的是可以将表中的数据压缩存放，只为了做数据挖掘的

2.6MEMORY：内存存储引擎，将表中的所有数据都放到内存里面，性能特别好，但是数据安全性没有保证

2.6BLACKHOLE：黑洞存储引擎

本文出自 “凡夫俗子” 博客，请务必保留此出处http://caoyt.blog.51cto.com/9978141/1652007