从零开始带你成为MySQL实战优化高手学习笔记（一）boyang的博客-

我看到有个网站爬取csdn的文章，我是16:41发布的，那上面16:52就有了，这效率还不错，有兴趣的可以搞他一下。网站标题叫这个：

之前看过一个学习方法：如何才能加深记忆？学之后再复述出来。

重复是有必要的！

很多新入职的小朋友可能和当时的我一样，对数据库的了解仅仅停留在建库建表增删改查这些操作，日常工作也都是用封装好的代码，别说底层原理了，数据库和系统之间是如何工作都不是很懂。

长此以往，当你的老大哥让你去优化sql提升性能的时候，绝对是一脸懵逼。毕竟优化并不仅仅建个索引就能完事的。

所以我们需要去了解底层的东西。

推荐《MySQL技术内幕InnoDB存储引擎  第2版》、《高性能mysql第三版》、《深入理解MySQL核心技术》

我还没看，听大佬介绍的。。。

提示：刚开始会接触很多概念，之后会细讲，先了解即可。

目录

一、驱动是干嘛的？

二、数据库连接池又是什么鬼？

三、MySQL是怎么执行sql语句的？

四、初步了解InnoDB存储引擎架构设计

1、缓冲池

2、undo日志

3.redo log buffer

4.innodb_flush_log_at_trx_commit

一、驱动是干嘛的？

以MySQL为例，还记得JDBC连接数据库的步骤吗？

 1.导入驱动jar包  2.注册驱动  3.获取数据库连接对象Connection  3.对JDBC中各个接口和类的详解  4.定义sql  5.获取执行sql语句的对象Statement  6.执行sql，接受返回结果  7.处理结果  8.释放资源

第一步就是导入驱动jar包，我们都知道，系统要想对数据库进行操作，肯定要与数据库建立一个链接，谁建？

驱动。

二、数据库连接池又是什么鬼？

现在有个查询任务，系统建立一个链接，查询完毕处理结果，然后释放链接，完事了。

假如有多个线程都要对数据库进行操作，怎么办？等一个任务执行完毕再进行下一个？

等不起，再一个，假如有几百个线程都要操作呐？那是不是就要建立链接+释放几百次？这效率忒低了。

所以聪明的人出现了，建立一个线程池，池子里维持多个链接，来一个线程给他一个链接，用完了再放回到池子里而不是释放，这样就省去了频繁创建、释放的时间

三、MySQL是怎么执行sql语句的？

我们日常对sql的操作就是写sql语句，使用封装好的方法去执行获取结果并处理，完事了。

我们只知道写insert，表里就多了一条数据，写delete，表里就少了一条数据，但MySQL是怎么知道我要干啥的？

数据库其实就是一个系统，数据库的一个简单任务就是拿到业务系统发给它的数据，解析、执行并返回结果。这里面涉及到SQL接口、查询解析器、查询优化器、调用存储引擎接口、执行器。

首先，在数据库这边，分配线程去监听请求并读取请求数据，转交给SQL接口，然后由查询解析器根据SQL语法去解析这条SQL语句表达的是什么意思，解析之后由查询优化器生成查询路径树，选出一条最优查询路径调用存储引擎接口真正执行SQL语句。

但是，谁调用存储引擎接口啊？执行器。（这个过程后面会有细讲）

四、初步了解InnoDB存储引擎架构设计

1、缓冲池

上面说执行器调用存储引擎真正执行SQL语句，但是，比如说执行update，万一MySQL崩溃了怎么整，这数据到底有没有更新？

InnoDB存储引擎在内存中设置了缓冲池（Buffer Pool），这里面会缓冲很多数据，当查询的时候先去缓冲池中查，如果有就不用去磁盘文件中读取，毕竟内容快多了。

比如，要执行下面这条语句

 update devices set devicename='xxx' where id=1 

InnoDB会先去缓冲池去找id为1的这条数据，如果不在，就会从磁盘文件加载到缓冲池中，万一这时候又有别人也想更新这条数据咋整？加独占锁。什么鬼？我哪知道，往后看。。

2、undo日志

搞个图先，这两个图都是InnoDB架构图，有很多东西，先不讲。

还是上面那个更新，更新失败，要回滚对吧？说的简单，我拿什么回滚？你看上图是不是在缓冲池中有个undo块，这就是undo日志。

把更新前的值保存到undo日志中，等到需要回滚的时候，去这里取。

好，现在数据也加到缓冲池了，也加独占锁了，也能确保正常回滚了，下面就开始更新了，首先会去缓冲池中更新这条记录，加入这时候数据库又崩了怎么办？你要注意现在磁盘中的数据还是原来的，数据库崩了，内容中的数据就没了啊！

3.redo log buffer

innodb在内存中还有一块叫做redo log buffer的地方，用来存放redo日志，这个日志就是记录对数据做了什么更改，如果数据库发生意外，用这个来恢复更新过的数据。

4.innodb_flush_log_at_trx_commit

如果提交事务之后，数据还没写到磁盘上，数据库又崩了怎么办？提交事务，我希望得到更新之后的结果，但是如果崩了，磁盘中数据还是原来的数据啊，这时候redo log buffer就用上了。

通过设置innodb_flush_log_at_trx_commit的参数来指定redo日志如何从redo log buffer里刷入到磁盘文件。

• 设为0的时候，提交事务之后，不会把redo log buffer里的数据刷入磁盘文件，如果mysql崩了，内容中的数据全部丢失，也就没办法恢复了。
• 设为1的时候，提交事务之后，会从redo log buffer 刷入磁盘文件，只要事务提交成功，redo log就会保存到磁盘中，如果此时数据库崩了，可以根据磁盘中的redo log恢复。
• 设为2，会把redo日志刷入系统的cache缓存中，每隔一段时间MySQL再主动将系统Cache中的数据批量同步到磁盘。这种情况就和0差不多了。

这三种策略选哪一种还需要根据不同情况做取舍。

当这一切都准备完毕之后，什么时候更新数据到磁盘那？

MySQL自己还有一个日志文件，叫做binlog，在提交事务的时候还会把这次更新对应的binlog日志写到磁盘中，它也是有一个刷盘策略的，可以通过sync_binlog参数控制。

当把binlog日志写入到磁盘后，就会完成最终的事务提交，会把这次更新对应的binlog日志文件名和本次更新在binlog日志中的位置写入redo log日志文件中，同时在redo log日志文件中写入commit标记。

MySQL会有一个后台IO线程，会在之后随机把内存中的buffer pool中修改的数据刷回磁盘。