mysql的日志

1. mysql的执行过程

1.1 mysql的内部组件架构

1.1.1 server层

•         连接器

         当有客户端与MySQL发起通信必须先跟server端建立通信连接，而建立连接的工作就是有连接器来完成。

        在完成TCP握手连接后，连接器会进行认证用户和密码，认证通过后连接器会从权限表中获取用户拥有的操作权限。

         注：当一个用户成功建立连接之后，即使你用管理员账号对用户的权限进行了修改，连接中的用户权限也不会变更；权限修改完成后，只有新建立的连接才会生效。

• 查询缓存

        当发起一个sql查询的时候，会先到查询缓存是否执行过者sql语句。之前执行过的语句和结果会以key-value的形式存储在查询缓存中，如果缓存中不存在才会去执行下面的执行流程。

        一般建议只对极少更新的表进行缓存查询。

• 词法分析器

        对语句进行分析。包括：词法分析、语法分析、语义分析、构造执行树、生成执行计划和计划的执行几个步骤。

• 优化器

        优化器是在表中存在几个索引的时候，决定使用哪个索引；或者在一个语句中存在多个表连接查询的时候，确定表的先后连接顺序。

• 执行器

        开始sql语句的执行，会先判断用户对执行表是否有权限，无权限则直接失败，有权限，执行器会更加表定义的引擎，去使用这引擎提供的接口。

1.1.2 store层

        存储引擎层负责数据的提取和存储。支持innoDB、MyISAM、Memory等多个执行引擎。现在用的最多的是innoDB。

2. Mysql的日志文件

• 错误日志（error log）：对MySQL的启动、运行、关闭过程进行了记录，能帮助定位MySQL问题。

• 慢查询日志（slow query log）：用来记录执行时间超过 long_query_time 这个变量定义的时长的查询语句。通过慢查询日志，可以查找出哪些查询语句的执行效率很低，以便进行优化。

• 一般查询日志（general log）：记录了所有对MySQL数据库请求的信息，无论请求是否正确执行。

• 二进制日志（bin log）：记录了数据库所有执行的DDL和DML语句（除了数据查询语句select、show等），以事件形式记录并保存在二进制文件中。

        innoDB特有引擎：

• 重做日志（redo log）：记录了对于InnoDB存储引擎的事务日志。

• 回滚日志（undo log）：回滚日志的作用就是对数据进行回滚。当事务对数据库进行修改，InnoDB引擎不仅会记录redo log，还会生成对应的undo log日志；如果事务执行失败或调用了rollback，导致事务需要回滚，就可以利用undo log中的信息将数据回滚到修改之前的样子。

2.1 bin-log日志文件

        binlog是server层实现的二进制日志文件，会记录crud的操作。用于保证数据的一致性，提供给主从同步，恢复数据以及数据同步等用途。

        特性：

        a. binlog是在Mysql的Server层实现的（引擎公用）

        b. binlog是逻辑日志，记录的是一条数据的原始逻辑

        c. binlog不限大小，通过追加写入，不会覆盖以前的日志。

        开启日志记录，需配置my.cnf文件

        log-bin=/usr/local/mysql/data/binlog/mysql-bin

        binlog-format=row

        sync-binlog=1(表示每次写入就与硬盘同步，会影响性能，为0时表示，事务提交时不进行刷盘操作，有系统决定。)

        binlog模式有三种（row、statement，mixed）

2.2 undo-log日志文件

        undolog是引擎层日志，innoDB引擎提供，逻辑日志，用于事务回滚，MVCC多版本控制等。保障数据的【原子性】。

        在数据修改的时候，不仅记录了redo log，还记录undo log，如果因为某些原因导致事务失败或回滚了，可以用undo log进行回滚。

2.3 redo-log日志文件

        redolog是引擎层日志，innoDB引擎提供，物理日志，物理修改内容（xxxx页修改了xxx）。用于保证数据的持久性，数据保存等逻辑。

        其实写redo log的时候，也会有buffer，是先写buffer，再真正落到磁盘中的。至于从buffer什么时候落磁盘，会有配置供我们配置。写redo log也是需要写磁盘的，但它的好处就是顺序IO（我们都知道顺序IO比随机IO快非常多）。

        redo log的存在为了：当我们修改的时候，写完内存了，但数据还没真正写到磁盘的时候。此时我们的数据库挂了，我们可以根据redo log来对数据进行恢复。因为redo log是顺序IO，所以写入的速度很快，并且redo log记载的是物理变化（xxxx页做了xxx修改），文件的体积很小，恢复速度很快。

       数据库事务提交的时候：redolog有两次阶段提交，binlog写入前的prepare状态的写入，binlog日志写入后的commit状态的写入。

   binlog与redolog的区别：

• binlog存的是数据的逻辑变化，所有执行的DDL和DML语句；redolog记载的是数据的物理变化，物理修改内容（xxxx页修改了xxx）。
• 功能不同，binlog用于主从复制和恢复数据。
  • 主从服务器需要保持数据的一致性，通过bin log来同步数据。
  • 如果整个数据库的数据都被删除了，bin log存储着所有的数据变更情况，那么可以通过bin log来对数据进行恢复。

        redolog用于持久化。

• 写完内存，如果数据库挂了，那我们可以通过redo log来恢复内存还没来得及刷到磁盘的数据，将redo log加载到内存里边，那内存就能恢复到挂掉之前的数据了。

• 写入时间不同。

  • bin log：仅在事务提交前进行提交，也就是只写磁盘一次。
  • redo log：事务进行的过程中不断写入。

• 写入方式不同。

  • bin log：追加写入，不会覆盖已经写的文件。
  • redo log：循环写入和擦除。