京东面试:说说 MySQL 的架构体系
关注“Java 后端技术全栈”
回复“面试”获取全套面试资料
字数:3620,阅读耗时:4 分 35 秒
最近群里一位兄弟在面试中被问到:「MySQL 的架构体系是什么」。
虽然他搞 java 开发好几年了,也一直使用的是 MySQL 数据库,但是面对这个问题依然是一脸懵逼,还以为面试官要问索引、慢查询、性能优化之类的(因为这些都是网上找点面试题背过了)。
但这位面试官不按套路出牌,这位兄弟当场就是脸红耳赤的,心想 nnd 居然会这么问。其实面试中面试官的问题有千千万,有的问题确实背背面试题就能应对,但不是所有的面试题咱们都能背下来的。
今天我们就来聊聊 MySQL 的架构体系,尽管咱们是 java 开发人员,但是在日常开发过程中也会经常和 MySQL 数据库打交道。如果公司有 DBA 能干点事还稍微好点,如果是没有 DBA 或者 DBA 没什么卵用的情况下,我们还是很有必要了解 MySQL 的整个体系的,况且在面试中遇到了也是一个加分项。
想要知道一条 SQL 是怎么查询的,只要对 MySQL 整个体系搞清楚了,才能说出个 123。
所以于情于理,我们很有必要学习一下 MySQL 的架构体系的。
平时,和小伙伴们聊天的时候,经常会把 MySQL 当做我们开发的一个软件系统,既然是软件系统,那么就有个架构图,以及架构是如何分层的,每一层的功能是什么。
下面我们就来看看 MySQL 的整体架构图。
MySQL 架构图
再来看看我们开发的系统架构图:
其实还是蛮相似的。都有分层的概念。既然我们开发的软件系统能进行分层,那么 MySQL 能分层吗?
答案是:能,下面我们就来聊聊 MySQL 的分层情况以及每一层的功能。
架构图分层
上面的架构图我们可以对其进行拆分,并做简要的说明。
连接层
与客户端打交道,上面已经写明了能支持的的语言。客户端的链接支持的协议很多,比如我们在 Java 开发中的 JDBC。
服务层
连接池
主要是负责存储和管理客户端与数据库的链接,一个线程负责管理一个连接。自从引入了连接池以后,官方报道:当数据库的连接数达到 128 后,使用连接池与没有连接池的性能是提升了 n 倍(反正就是性能大大的提升了)。
连接建立完成后,就可以执行 select 语句了。执行逻辑就会先来到缓存模块。
缓存
MySQL 拿到一个查询请求后,会先到查询缓存看看,之前是不是执行过这条语句。之前执行过的语句及其结果会以 key-value 对的形式存储在内存中。key 是查询的语句,value 是查询的结果。如果你的查询能够直接在这个缓存中找到 key(命中),那么这个 value 就会被直接返回给客户端。
如果在缓存中未命中,就会继续后面的执行阶段。执行完成后,执行结果会被存入查询缓存中。这里可以看到,如果查询命中缓存,MySQL 不需要执行后面的复杂操作,就可以直接返回结果,这个效率会很高。
但是大多数情况下我会建议你不要使用查询缓存,为什么呢?因为查询缓存往往弊大于利。
查询缓存的失效非常频繁,只要有对一个表的某一条数据更新,这个表上所有的查询缓存都会被清空。
因此可能很费劲地把结果存起来,还没使用呢,就被一个更新全清空了。对于更新压力大的数据库来说,查询缓存的命中率会非常低。除非你的业务就是有一张静态表,很长时间才会更新一次。
比如:一个系统配置表,那这张表上的查询才适合使用查询缓存。
好在 MySQL 也提供了这种“按需使用”的方式。你可以将参数 query_cache_type 设置成 DEMAND,这样对于默认的 SQL 语句都不使用查询缓存。
「注意」:MySQL 8.0 版本直接将查询缓存的整块功能删掉了,标志着 MySQL8.0 开始彻底没有缓存这个功能了。
解析器
如果没有命中查询缓存,就要开始真正执行语句了。首先,MySQL 需要知道你要做什么,因此需要对 SQL 语句做解析。
分析器先会做“词法分析”。你输入的是由多个字符串和空格组成的一条 SQL 语句,MySQL 需要识别出里面的字符串分别是什么,代表什么。
做完了词法分析以后,就要做“语法分析”。根据词法分析的结果,语法分析器会根据语法规则,判断你输入的这个 SQL 语句是否满足 MySQL 语法。
如果我们在拼写 SQL 时候,少了或者写错了某个字母,,就会收到“You have an error in your SQL syntax”的错误提醒。
比如下面这个案例:
错误在于 WHERE 关键字中差了一个 E。
同样,我们使用的 SQL 如果某个字段不存在。
一般语法错误会提示第一个出现错误的位置,所以你要关注的是紧接“use near”的内容,仅供参考,有时候这个提示也不是非常靠谱。
经过分析器对 SQL 进行了分析,并且没有报错。那么此时就进入优化器中,对 SQL 进行优化。
优化器
优化器主要是在我们的数据库表中,如果存在多个多个索引的时候,决定使用哪个索引;或者在一个语句有多表关联(join)的时候,决定各个表的连接顺序 。
比如说:
它会在条件查询上进行优化处理。
优化器处理完成过后,此时就已经确定了 SQL 的执行方案。然后继续进入执行器中。
执行器
首先,肯定是要判断权限,就是有没有权限执行这条 SQL。工作中可能会对某些客户端进行权限控制。
比如说:生产环境中,对于大部分开发人员都只开查询权限,没有增删改权限(部分小公司除外)。
如果有权限,就打开表继续执行。打开表的时候,执行器就会根据表的引擎定义,去使用这个引擎提供的接口。
存储引擎层
存储引擎的概念是 MySQL 里面才有的,不是所有的关系型数据库都有存储引擎这个概念 。
数据库存储引擎是数据库底层软件组织,数据库管理系统(DBMS)使用数据引擎进行创建、查询、更新和删除数据。不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能,使用不同的存储引擎,还可以获得特定的功能。现在许多不同的数据库管理系统都支持多种不同的数据引擎。
因为在关系数据库中数据的存储是以表的形式存储的,所以存储引擎也可以称为表类型(Table Type,即存储和操作此表的类型)。
MySQL5.5 版本(mysql 版本 < 5.5 版本) 以前,默认使用的存储引擎是 MyISAM 。
MySQL5.5 版本(mysql 版本 >= 5.5 版本) 以后,默认使用的存储引擎是 InnoDB 。
下面对部分相对使用多的引擎进行一个对比:
在实际项目中,大多数使用 InnoDB,然后是 MyISAM,至于其他存储引擎使用的非常至少。
MyISAM 与 InnoDB 引擎的区别
Mysql5.5 版本之前默认的存储引擎就是 MyISAM 存储引擎,MySQL 中比较多的系统表使用 MyISAM 存储引擎,系统临时表也会用到 MyISAM 存储引擎,但是在 Mysql5.5 之后默认的存储引擎就是 InnoDB 存储引擎了。
两个主要原因:
第一个原因是 MyISAM 是表级锁定,限制了数据库读/写的性能;
另外一个原因是 MyISAM 不支持事务,基于以上两点,InnoDB 引擎可以锁到行。
如何在两种存储引擎中进行选择?
是否有事务操作?有,InnoDB。
是否存储并发修改?有,InnoDB。
是否追求快速查询,且数据修改较少?是,MyISAM。
是否使用全文索引?如果不引用第三方框架,可以选择 MyISAM,但是可以选用第三方框架和 InnDB 效率会更高。
系统文件存储层
系统文件存储层主要是负责将数据库的数据和日志存储在系统的文件中,同时完成与存储引擎的之间的打交道,是文件的物理存储层。
比如:数据文件、日志文件、pid 文件、配置文件等。
数据文件
「db.opt 文件」:记录这个数据库的默认使用的字符集和校验规则。
「frm 文件」:存储于边相关的元数据信息,包含表结构的定义信息等,每一张表都会有一个 frm 文件与之对应。
「MYD 文件」:MyISAM 存储引擎专用的文件,存储 MyISAM 表的数据信息,每一张 MyISAM 表都有有一个.MYD 文件。
「MYI 文件」:也是 MyISAM 存储引擎专用的文件,存放 MyISAM 表的索引相关信息,每一张 MyISAM 表都有对应的.MYI 文件。
「ibd 文件和 ibdata 文件」:存放 InnoDB 的数据文件(包括索引)。InnoDB 存储引擎有两种表空间方式:独立表空间和共享表空间。
独享表空间使用 ibd 文件来存放数据,并且每一张 InnoDB 表存在与之对应的.ibd 文件。
共享表空间使用 ibdata 文件,所有表共同使用一个或者多个.ibdata 文件。
「ibdata1 文件」:系统表空间数据文件,存储表元数据、Undo 日志等。
「ib_logfile0、ib_logfile0 文件」:Redo log 日志文件。
日志文件
错误日志:默认是开启状态,可以通过命令查看:
二进制日志 binary log:记录了对 MySQL 数据库执行的更改操作,并且记录了语句的发生时间、执行耗时;但是不记录查询 select、show 等不修改数据的 SQL。主要用于数据库恢复和数据库主从复制。也是大家常说的 binlog 日志。
慢查询日志:记录查询数据库超时的所有 SQL,默认是 10 秒。
通用查询日志:记录一般查询语句;
配置文件
用于存放 MySQL 所有的配置信息的文件,比如:my.cnf、my.ini 等。
「pid 文件」
pid 文件是 mysqld 应用程序在 Linux 或者 Unix 操作系统下的一个进程文件,和许多其他 Linux 或者 Unix 服务端程序一样,该文件放着自己的进程 id。
「socket 文件」
socket 文件也是 Linux 和 Unix 操作系统下才有的,用户在 Linux 和 Unix 操作系统下客户端连接可以不通过 TCP/IP 网络而直接使用 Unix socket 来连接 MySQL 数据库。
SQL 查询流程图
总结
MySQL 整个系统我们可以看成是我们日常开发的软件系统,也有接入层,专门对接外面客户端的,和我们系统的网关就很像,缓存也就类似我们业务代码中使用的缓存,解析器可以理解为业务系统中参数解析以及参数校验,优化层可以当做我们开发代码优化的手段,然后存储引擎就相当于我们的持久层,文件系统相当于整个业务系统中的数据库。
可能比喻不是非常的恰当,但是希望大家能领略轻重的含义,目的只有一个,那就是让大家能轻松掌握 MySQL 的整体情况。
不要天天羡慕什么大牛,什么大神,他们也是一步一步来的(个例除外)。自信点,只要你一点一点搞,踏踏实实的干,你也会成为大神的。
文中图片来源于网络,侵删!
推荐阅读
版权声明: 本文为 InfoQ 作者【田维常】的原创文章。
原文链接:【http://xie.infoq.cn/article/a388d772845c17a3ee326529d】。文章转载请联系作者。
评论