所有跨存储引擎的功能都在这一层实现,比如存储过程、触发器、视图等.
连接到数据库,负责跟客户端建立连接、获取权限、维持和管理连接,命令通常是mysql -h$ip -P$port -u$user -p
.
为了安全起见,通常在上述命令后再输入密码,而不是将密码紧跟在-p
后,这样可能会导致密码泄露.
若用户名或密码错误,则会收到Access denied for user
的错误,然后客户端程序结束执行.
若用户名密码认证通过,则连接器会到权限表中查询所拥有的权限,之后在这个连接中的权限判断逻辑,都将依赖于此时读到的权限。
因此当一个用户建立连接之后,即使用管理员账号对该用户的权限做了修改,也不会影响到已经存在的连接的权限.
连接完成后,若没有后续的动作,则这个连接就处于空闲状态,可以用show processlist
命令看到它,Sleep
表示系统里有一个空闲连接.
若客户端很长时间没有动静,连接器就会自动将其断开,由参数wait_tieout
控制,默认时间时8小时.
如果在连接被断开之后,客户端再次发送请求,就会收到错误提醒Lost connection to MySQL serv
,就需要重连再执行请求.
长连接是指若客户端持续有请求,则一直使用同一个连接.
短连接是指每次执行完很少的几次查询就断开连接,下次查询重新建立.
由于建立连接的过程比较复杂,因此在使用过程中尽量减少建立连接的动作,即尽量使用长连接.
全部使用长连接时,有时候MySQL占用内存涨得很快,这是因为MySQL在执行过程中临时使用的内存时管理在连接对象中得,这些资源会在断开连接时才释放,因此如果长连接累积下来,可能导致内存占用太大,被系统强行杀掉(OOM),导致MySQL异常重启.
解决方案如下:
mysql_reset_connection
来重新初始化连接资源,这个过程不需要重连和权限验证,但会将连接恢复至刚创建完成的状态.连接建立完成后,就可以执行select
语句了,执行逻辑会来到第二步:查询缓存.
MySQL拿到一个查询请求后,会先到查询缓存中看看之前是否执行过该语句,之前执行的语句及其结果可能以key-value
对的形式,被直接缓存在内存中,key
是查询的语句,value
是查询的结果,若该查询能在缓存中找到对应的key
,则value
就会直接返回给客户端.
若语句不在查询缓存中,就会继续后续的执行阶段,执行完成后,执行结果会被存入查询缓存中. 因此若查询命中缓存,MySQL不需要执行后面的复杂操作,就可以直接返回结果.
但大多数情况下不要使用查询缓存,因为查询缓存往往弊大于利
查询缓存的失效非常频繁,只要有一个对表的更新,这个表上所有的查询缓存都会被清空. 对于更新压力大的数据库来说,查询缓存的命中率会非常低,除非你的业务只有一张静态表,很长时间才更新一次.如一个系统配置表.
MySQL提供了这种按需使用的方式,可以将参数query_chache_type
设置为DEMAND
,这样对于默认的SQL语句都不使用查询缓存,对于要使用查询缓存的语句,可以使用SQL_CACHE
显示指定,如
select SQL_CACHE * from T where ID=10;
MySQL8.0版本直接将查询缓存功能删除了.
若没有命中查询缓存,就要开始真正执行语句,首先需要对SQL语句进行解析.
分析器先做词法分析,识别出关键字等,再做语法分析,根据词法分析的结果,语法分析器会根据语法规则,判断输入的SQL语句是否满足MySQL语法.
若语法有问题,则会收到You have an error in your SQL syntax
的错误提醒. 一般语法错误会题是第一个出现错误的位置.
在开始执行语句之前,还要经过优化器的处理.
优化器是在表里面有多个索引时,决定使用哪个索引;或在一个语句有多表关联(join)的时候,决定各个表的连接顺序,比如执行下面的语句,
mysql> select * from t1 join t2 using(ID) where t1.c=10 and t2.d=20;
这两种执行方法的逻辑结果是一样的,但执行效率会有所不同,优化器的作用就是决定是用哪一个方案.
优化器阶段完成后,语句的执行方案就确定下来,然后进入执行器阶段.
MySQL通过分析器知道了语句要做什么,通过优化器知道了该怎么做,随后进入执行阶段,开始执行语句.
开始执行时,先判断你对该表T有没有执行查询的权限,若没有则会返回没有权限的错误,(在工程实现上,若命中查询缓存,会在查询缓存返回结果时做权限验证,也会在优化器之前调用precheck验证权限.)
若有权限,则打开表继续执行,打开表的时候执行器会根据表的引擎定义,使用引擎提供的接口.
mysql> select * from T where ID=10;
在表T中,ID字段若没有索引,则执行器的执行流程如下:
对于有索引的表,执行的逻辑也是类似的,第一次调用的是’取满足条件的第一行’,循环取’满足条件的下一行’,这些接口都是引擎中已经定义好的.
在数据库的慢查询日志中看到rows_examined
字段,表示这个语句执行过程中扫描了多少行,这个值是在执行器每次调用引擎获取数据行的时候累加的.
在某些场景下,执行器调用一次,在引擎内部则会扫描多行,因此引擎扫描行数和rows_examined
并不是完全相同的.
负责数据的存储和提取,架构模式是插件式的,支持InnoDB、MyISAM、Memory等多个存储引擎,最常用的存储引擎是InnoDB.
即创建表时,若不指定引擎类型,默认使用的是InnoDB.