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

重复是有必要的。

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

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

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

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

还没看完。。

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

​

一、驱动是干嘛的？

以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是怎么知道要删除还是要增加的？

你肯定要说，这还不简单，这不是有insert和delete语法上的区别吗，是，然后那？

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

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

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

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

上面说执行器调用存储引擎真正执行SQL语句，但是，比如说执行update，万一MySQL崩溃了怎么办，这数据到底有没有更新成功？数据库的设计师们做了一系列的东西来保证这个。

1、缓冲池

为什么要有缓冲池？因为快，缓冲池在内存中，数据库最终存储在磁盘中，对磁盘进行增删改查和对内存进行增删改查肯定不在一个级别。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日志，这个日志就是记录对内存中的数据做了什么更改。

这里分两个情况：

1、提交事务之前，如果崩溃了，其实并不怎么影响，磁盘中还是原来的数据。

2、提交事务之后。

可是，你要注意，“nnodb在内存中还有一块叫做redo log buffer的地方” redo log buffer在内存里，程序崩了，内存中的数据不没了吗？

4.innodb_flush_log_at_trx_commit

这个参数是用来控制如何把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中修改的数据刷回磁盘。

系列学习笔记： 从零开始带你成为MySQL实战优化高手学习笔记（一） 从零开始带你成为MySQL实战优化高手学习笔记（二） 关于buffer pool的相关知识 从零开始带你成为MySQL实战优化高手学习笔记（三）MySql byffer pool的运行过程

​