重复是有必要的。
很多新入职的小朋友可能和现在的我一样,对数据库的了解仅仅停留在建库建表增删改查这些操作,日常工作也都是用封装好的代码,别说底层原理了,数据库和系统之间是如何工作都不是很懂。
长此以往,当你的老大哥让你去优化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.获取数据库连接对象Connection3.对JDBC中各个接口和类的详解4.定义sql5.获取执行sql语句的对象Statement6.执行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的运行过程
欢迎关注微信公众号,公众号的好处是可以持续保持联系。