MySQL系列文章（一）整体架构

本系列文章是我对MySQL的一个整理和复习，可能与之前的文章有冲突，但不重要。欢迎访问我的博客，只是懒得更新，东西比较少。

https://www.xpang0.com/

1、体系架构

MySQL整体的体系架构图有很多，这个图就很形象的展示了大致的结构。MySQL Server自顶向下分为网络连接层、服务层、存储引擎层和系统文件层。

1.1、网络连接层

主要提供与MySQL服务器建立连接的支持。

1.2、服务层

• 连接池：负责存储和管理客户端与数据库的连接，一个线程负责管理一个连接。

• 系统管理和控制工具：例如备份恢复、安全管理、集群管理等

• SQL接口：用于接收客户端传来的各种SQL命令，并且返回用户需要查询的结果。比如DML、DDL、存储过程、视图、触发器等

• 解析器：负责将请求的SQL解析生成一个“解析树”。根据MySQL规则进一步检查解析树是否合法

• 查询优化器：当“解析树”通过解析器语法检查后，交由优化器转化为执行计划，然后与存储引擎交互

  常见的优化类型

  • 重新定义关联表的顺序
  • 将外连接转化成内连接
  • 使用等价变换规则
  • 优化COUNT()、MIN()和MAX()

• 缓存：缓存机制是由一系列小缓存组成的。比如表缓存、记录缓存、权限花村、引擎缓存等

1.3、存储引擎层

MySQL存储引擎是插件式的，通过接口屏蔽了不同存储引擎之间的差异。

1.4、系统文件层

该层包括了日志文件、数据文件和配置文件

• 日志文件

  • 错误日志

    show variables like '%log_error%';
    

  • 通用查询日志

    记录一般查询语句

    show variables like '%general%';
    

  • 二进制日志（binlog）

    记录了对MySQL数据库执行的更改操作，并且记录了语句的发生时间、执行时长；但是它不记录select、show等不修改数据库的SQL。主要用于数据库恢复和主从复制。

    show variables like '%log_bin%'; //是否开启
    show variables like '%binlog%'; //参数查看
    show binary logs;//查看日志文件
    

  • 慢查询日志（Slow query log）

    记录所有执行时间超时的查询SQL，默认是10秒。
    show variables like '%slow_query%'; //是否开启
    show variables like '%long_query_time%'; //时长
    

• 数据文件

  存放undo log、redo log、各种存储引擎相关文件

• 配置文件

  存放MySQL配置信息文件，比如my.cnf、my.ini等

• pid文件

  pid 文件是 mysqld 应用程序在 Unix/Linux 环境下的一个进程文件，和许多其他 Unix/Linux 服务端程序一样，它存放着自己的进程 id。

2、运行机制

如上图是整体运行机制的一个流程，这里重点说下查询缓存

2.1、连接器

mysql -uname -p

通常是采用上述的命令输入密码登录到MySQL中，默认自动连接断开时间是8小时

2.2、查询缓存

MySQL判断缓存命中的方法很简单：缓存存放在一个引用表中，通过一个哈希值引用，这个哈希值包括了如下因素，即查询本身、当前要查询的数据库、客户端协议的版本等一些其他可能会影响返回结果的信息。
当判断缓存是否命中时，MySQL不会解析、“正规化”或者参数化查询语句，而是直接使用SQL语句和客户端发送过来的其他原始信息。任何字符上的不同，例如空格、注释——任何的不同——都会导致缓存的不命中。 (18) 所以在编写SQL语句的时候，需要特别注意这点。通常使用统一的编码规则是一个好的习惯，在这里这个好习惯会让你的系统运行得更快。

建议不要使用查询缓存，MySQL也在8.0版本中取消了该特性

查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。因此很可能你费劲地把结果存起来，还没使用呢，就被一个更新全清空了。对于更新压力大的数据库来说，查询缓存的命中率会非常低。除非你的业务就是有一张静态表，很长时间才会更新一次。比如，一个系统配置表，那这张表上的查询才适合使用查询缓存。