mysql架构逻辑

前言

上面架构图已经见怪不怪了，我们更多关注客户端->server->存储引擎，我们通过运行机制来了解mysql基础架构

是否发现没有查询缓存？查询缓存其实就是将SELECT的语句和相应的结果缓存起来并发送给客户端，如果同样的SELECT语句之后再过来，就直接返回缓存里面的查询结果，并且查询缓存是客户端共享的，一个客户端生成，其他客户端也有用。

假设一个客户端进程读，另一个客户端进程写同一个数据表，这个时候，查询缓存是读还是不读呢？这一切的控制，让MySQL要花很大的精力去处理这种情况，比如引入锁，有变化了，就锁起来，不让读，然后变化完了，再重新生成缓存，给读端。高并发下完全成为鸡肋。

解析器

负责将请求的SQL解析生成一个"解析树"。然后根据一些MySQL规则进一步检查解析树是否合法。

查询优化器

当“解析树”通过解析器语法检查后，将交由优化器将其转化成执行计划。我们写的sql语句并不一定是性能最好的，mysql会自动优化，最明显的感受一下in子查询的半连接优化。

系统文件层

将数据库的数据和日志存储在文件系统之上。并完成与存储引擎的交互，是文件的物理存储层。含日志文件，数据文件，配置文件，pid 文件，socket 文件

日志文件

对错误、查询、修改、慢查询进行记录。

• 错误日志（Error log）默认开启，show variables like ‘%log_error%’
• 通用查询日志（General query log）记录一般查询语句，show variables like ‘%general%’;
• 二进制日志（binary log） 记录了对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%'; //时长

配置文件

用于存放MySQL所有的配置信息文件，比如my.cnf(unix)、my.ini(windows)等

数据文件

• frm 文件：存储与表相关的元数据（meta）信息，包括表结构的定义信息等，每一张表都会有一个frm 文件。8.0之后放到了idb中。
• ibd文件和 IBDATA 文件：存放 InnoDB 的数据文件（包括索引）。InnoDB 存储引擎有两种表空间方式：独享表空间和共享表空间。独享表空间使用 .ibd 文件来存放数据，且每一张InnoDB 表对应一个 .ibd 文件。共享表空间使用 .ibdata 文件，所有表共同使用一个（或多个，自行配置）.ibdata 文件。
• ibt文件，innoDB临时表空间数据文件。
• ibdata1 文件：系统表空间数据文件，存储表元数据。
• ib_logfile0、ib_logfile1 文件：Redo log 日志文件。
• MYD 文件：MyISAM 存储引擎专用，存放 MyISAM 表的数据（data)，每一张表都会有一个MYD 文件。
• MYI 文件：MyISAM 存储引擎专用，存放 MyISAM 表的索引相关信息，每一张 MyISAM 表对应一个 .MYI 文件。
• pid 进程文件(unix)
• socket文件(unix)

存储引擎

• InnoDB：支持事务，具有提交，回滚和崩溃恢复能力，事务安全
• MyISAM：不支持事务和外键，访问速度快
• Memory：利用内存创建表，访问速度非常快，因为数据在内存，而且默认使用。

由上面看出常见的三种存储引擎特点就看出Memory代价很高昂，硬件换性能。redis缓存就可以替代它。
MyISAM：不需要事务支持（不支持），并发相对较低（锁定机制问题），数据修改相对较少，以读为主，数据一致性要求不高。
InnoDB：需要事务支持，行级锁定对高并发有很好的适应能力，数据更新较为频繁的场景。
InnoDB数据库保存最近一个月的监测数据(因为修约有效期为1个月)，固化任务每晚把一个月之前的数据转移至MyISMA数据库，并且计算日数据、月数据。查询从MyISMA。