MySQL 架构设计
MySQL 架构设计
系统只要能从数据库连接池获取到一个数据库连接,就能执行 CRUD。可通过数据库连接将待执行 SQL 发给 MySQL。
大部分 crud boy 只知道:
执行 insert 语句后,在表里会多条数据
执行 update 后,会更改表数据
执行 delete 后,会删除表里数据
执行 select 后,会查询表里数据出来
要是 SQL 性能丢人,建几个索引解决
...
这应该是目前行业内很多工程师对数据库的一个认知,完全当他是个黑盒来建表及执行 SQL。
网络连接必须有线程处理
假设数据库服务器的连接池中的某个连接,接收到一条 SQL 网络请求,请思考:
谁负责从这个连接中去监听网络请求?
谁负责从网络连接里把请求数据读取出来?
网络连接得有一个线程来监听请求及读取请求数据,比如从网络连接中读取和解析出来一条业务系统发的 SQL 语句:
SQL 接口
负责处理接收到的 SQL 语句。
MySQL 的工作线程从一个网络连接中读出一个 SQL 语句后,会如何执行该 SQL 呢?
MySQL 提供了 SQL 接口(SQL Interface),一套执行 SQL 语句的接口,专门执行业务系统发送的那些 CRUD 语句
因此 MySQL 的工作线程接收到 SQL 语句之后,就会转交给 SQL 接口去执行:
查询解析器
那 SQL 接口怎么执行 SQL 语句的?这玩意能懂这些 SQL 语句?
假设有如下 SQL:
这就需要查询解析器(Parser),负责解析 SQL 语句,比如对那个 SQL 拆解成:
要从“users”表里查询数据
查询“id”字段的值等于 1 的那行数据
对查出来的那行数据要提取里面的“id,name,age”三字段
SQL 解析也就是按 SQL 语法来解析 SQL 语句意欲何为:
查询优化器
通过解析器知道 SQL 要干啥了,然后就得找查询优化器(Optimizer)选择一个最优查询路径。
啥叫最优查询路径呢?
之前的那个 SQL:从“users”表里查询数据,查“id”字段的值等于 1 的那行数据,对查出来的那行数据要提取里面的“id,name,age”三个字段。
要完成此事有如下查询路径:
直接定位到 users 表中的 id 字段等于 1 的那行数据,查出来那行数据的 id、name、age 三个字段值
先把 users 表中的每行数据的“id,name,age”三个字段的值都查出来,然后从这批数据里过滤出来“id”字段等于 1 的那行数据的“id,name,age”三个字段
可见,完成该 SQL,两条路径都能实现,那到底选哪个呢?显然第一种性能更好。
所以查询优化器大概就是这个意义,他会针对你的 SQL 生成查询路径树,选择最优查询路径。
调用存储引擎接口,真正执行 SQL 语句。
把查询优化器选择的最优查询路径,即到底应该按照一个什么样的顺序和步骤去执行这个 SQL 语句的计划,把该计划交给底层的存储引擎去真正执行。
假设我们的数据有的存在内存,有的存在磁盘文件,那到底怎么知道
哪些数据在内存?
哪些在磁盘?
执行时:
是更新内存数据?
还是更新磁盘数据?
若更新磁盘数据:
先查询哪个磁盘文件
再更新哪个磁盘文件?
这就需要存储引擎,就是个执行 SQL 语句的,会按步骤查询内存缓存数据,更新磁盘数 据,查询磁盘数据等,执行此类的一系列的操作:
MySQL 架构设计中,SQL 接口、SQL 解析器、查询优化器都是通用的,属于一套组件。但支持各种存储引擎,如 InnoDB、MyISAM、Memory 等,可以选择具体使用哪种存储引擎来负责执行 SQL。
执行器
根据执行计划调用存储引擎的接口。
存储引擎可帮助我们去访问内存及磁盘上的数据,那谁来调存储引擎的接口?
那就是执行器,会根据优化器选择的执行方案,按照一定的顺序和步骤调用存储引擎的接口,执行 SQL 逻辑。
比如执行器可能先调用存储引擎的一个接口,获取“users”表中的第一行数据,然后判断一下这个数据的“id”字段的值是否等于我们期望的一个值,如果不是的话,那就继续调用存储引擎的接口,去获取“users”表的下一行数据。
也就这套操作,执行器会根据优化器生成的执行计划,不停调用存储引擎的接口们,去完成 SQL 语句的执行计划,即不停的更新或提取一些数据:
版权声明: 本文为 InfoQ 作者【JavaEdge】的原创文章。
原文链接:【http://xie.infoq.cn/article/1c1603121c8d7f50cf3886f47】。文章转载请联系作者。
评论