mysql执行一条sql语句的完整过程，sql语句在mysql中的执行过程

1. SQL语句在mysql的执行过程

一条更新语句完整流程图如下所示：

步骤：

一：客户端层

id为1的name字段原来的值是zhuge。

• ①：mysql的客户端执行sql

 update t set name = 'zhuge666' where id = 1;

        

二：mysql服务器层

• ②： 进入mysql服务器，由连接器验证账号密码等身份信息，验证通过去查mysql缓存，如果有，直接返回。没有进入分析器。
• ③：进入mysql的分析器，分析sql语句是否符合mysql规范。
• ④：进入sql优化器，mysql底层优化sql，比如调换索引列等。
• ⑤：进入执行器，执行sql。
          

三：innoDB引擎层

mysql服务层后边连接了很多引擎层，如MyIsam、innoDB等，这里只分析innoDB引擎。

以一个update语句为例，看一下inndb是如何执行，并实现底层事务的！

• ⑥：加载磁盘上id为1的整页数据到 buff pool缓存池中，此时buff pool中的name值为zhuge，为什么加载整页，因为磁盘上存储数据都是整页整页存的。这里要注意：mysql加载数据是整页整页加载的！！
• ⑦：把buff pool中的 旧值 zhuge 写入undo日志版本链，方便事务提交失败后回滚，回滚时直接从undo日志版本链中取值即可。
• ⑧：在buff pool中把新的值 zhuge666 赋给 name，注意此时只有buff pool中的name属性做了更新，磁盘上的文件还是原来的旧值 zhuge。
• ⑨：执行器把更新的操作先写入内存中的Redo Log buffer（Redo日志缓冲区）
• ⑩：把Redo日志缓冲区分批次顺序写入inndb独有的redo磁盘日志文件中，此时准备提交事务
• ⑪：把更新操作写入binlog日志，内容与redo日志差不多，属于mysql服务层，所有引擎层都有这一步操作。此时还是准备提交事务中，还没提交 。
• ⑫：写一个commit标记到redo日志中去，该标记为了保证事务提交后，redo日志和binlog日志数据一致。此时才标志着提交事务完成

问题一：binlog为什么要给redo日志中写一个commit标记？

        binlog主要用于恢复数据，提交事务时，要给redo日志中写一个commit标记可以保证binlog日志中的数据与redo日志中的数据保持一致性

问题二：磁盘文件的数据什么时候更新？

        不确定，有一个后台io线程从Buffer pool缓存池中随机以页为单位写入磁盘。

问题三：如果事务提交后，数据库服务挂了，此时buff pool的数据还没来得及更新到磁盘上，怎么办？

        当再次重启服务器时，可以使用redo日志里的数据恢复buff pool中的数据，后台线程再把数据从buff pool中写入磁盘，这也是redo日志的最主要作用

问题四：为什么Mysql不能直接更新磁盘上的数据，而是设置这么一套复杂的机制来执行SQL？

• ①：内存操作，异步刷盘：如果每个请求都要来更新磁盘，数据库性能将特别差。利用buff poll缓存池在内存中操作数据，定时写入磁盘，大大提高了数据库性能。
• ②：redo日志顺序写入磁盘：redo日志虽然也使用磁盘存储，但相对与直接随机读写磁盘来说，redo日志是顺序写磁盘日志文件的。顺序写入的速度远高于随机写入，同时redo日志还能保证各种异常情况下的数据一致性。

        正是通过这套机制，才能让我们的MySQL数据库在较高配置的机器上每秒可以抗下几干的读写请求。
        

2. undo日志、redo日志、binlog日志的区别？

三种日志都写入磁盘！不过undo日志和redo日志是innoDB存储特有的，binlog日志是所有存储引擎都有的！

• undo日志：主要用于mvcc机制的实现，还有事务回滚也可直接从undo日志中取到原始值
• redo日志：主要用于防止mysql宕机时，buff pool中的数据还未来得及写入磁盘，导致数据丢失。使用redo日志可在mysql宕机后再启动时，把数据恢复到buff pool中。第二点就是等待binlog日志发送commit标记后才提交事务，保证与binlog日志文件数据一致！
• binlog日志：主要用于数据库数据误删恢复，主从复制