MySQL存储引擎与架构

MySQL存储引擎与架构

1.1详细了解数据库类型

1.1.1关系型数据库

常见产品：MySQL（免费）、Oracle

关系型数据库模型是把复杂的数据结构归结为简单二维表格形式 。通常该表第一行为字段名称，描述该字段的作用，下面是具体的数据。在定义该表时需要指定字段的名称及类型。

在关系型数据库中，对数据的操作几乎全部建立在一个或多个关系表格上。在大型系统中通常有多个表，且表之间有各种关系。实际使用就是通过对这些关联的表格分类、合并、连接或选取等运算来实现数据库的管理

1.1.2非关系型数据库

常见产品：Redis、MongoDB

键值数据库是一种非关系数据库，它使用简单的键值方法来存储数据。键值数据库将数据存储为键值对集合，其中键作为唯一标识符

1.1.3列存储数据库

常见产品：HBase

对于行存储数据库，表中的数据是以行为单位逐行存储在磁盘上的；而对于列存储数据库，表中的数据则是以列为单位逐列存储在磁盘中。

平时的查询大部分都是条件查询，通常是返回某些字段（列）的数据。对于行存储数据，数据读取时通常将一行数据完全读出，如果只需要其中几列数据的情况，就会存在冗余列，出于缩短处理时间的考量，消除冗余列的过程通常是在内存中进行的。而列存储，每次读取的数据是集合的一段或者全部，不存在冗余性问题。这样，通过这种存储方式的调整，使得查询性能得到极大的提升。

1.1.4搜索引擎存储

常见产品：ElasticSearch

搜索引擎数据库是应用在搜索引擎领域的数据存储形式，由于搜索引擎会爬取大量的数据，并以特定的格式进行存储，这样在检索的时候才能保证性能最优

原理：用ik分词器将文档分为词条，对词条创建索引，记录词条所在id，查询时先根据词条查询文档id，再根据文档id查询文档

1.2图解MySQL 内部架构及作用

Mysql架构主要分为连接层、server层和存储引擎层，每一层 中都含有各自的很多小模块，尤其是第二层，结构相当复杂的。下面我们就分别 针对 这三层做一个简单的分析。我们看下图体系结构：

1.2.1.Connectors

指的是不同语言中与SQL的交互，如php、java等。

1.2.2 系统管理和控制工具

系统管理和控制工具、内置工具和服务，专为数据库的全生命周期管理设计，涵盖 运维监控、数据维护、性能优化、安全管控 四大核心场景，旨在降低人工运维成本，提升系统稳定性与效率。

1.2.3 连接层

• 在连接建立时，MySQL通常会优先加载全局权限和数据库级权限，因为这些权限最常用。
• 对于更细粒度的权限（如表级、列级权限），只有在执行具体的SQL操作时才会被加载。

• 用来客户端连接器请求过来以后，Connection Handler验证账户和密码，不正确，立马返回Access denied for user，此外还会验证ip，若都验证通过，则连接成功，缓存全局权限和数据库级权限。
• 连接过程其实就是一个TCP连接的过程，此连接是一个长连接，注意，MySQL服务器与客户端之间的通信是"半双工"的，意味着任意时刻，要么是服务器向客户端发送数据，要什么是客户端向服务器发送数据（请求），不能同时进行。MySQL也不会让你啥也不干一直连着，所以就有了超时时间，由wait_timeout控制(断开是服务器端断开，客户端再请求过来就报Lost
  connection to MySQL server during query)
• 连接器采用池化技术，节省了创建和销毁的成本；
• 默认只能连接151个客户端，一个客户端请求服务端分配一个线程（从线程里取），把线程池占满了，再连就报连接满了；
• 客户端一般也采用池化技术，优化请求，防止每次执行SQL都需要建立连接，减少开销；
• 长连接带来一个问题，有些SQL在执行的过程中创建临时表占用内存，连接不释放，内存不回收，会导致MySQL占用内存涨的特别快，可以通过以下方式解决：
  • 定期断开长连接（需要重连和权限验证）
  • Druid会定期检测空闲连接，默认的timeBetweenEvictionRunsMillis是60秒，minEvictableIdleTimeMillis是30分钟，所以默认情况下，空闲超过30分钟的连接会被释放。

1.2.4 SQL接口

接受用户的SQL命令，并且返回用户需要查询的结果。

1.2.5解析器

• MySQL在真正执行语句之前，会去parser你的查询语言，了解你要做什么
• 在这个过程会判断你的语法是否正确，不正确会报错：You have an error in your SQL syntax;
• 将查询字段，表，条件封装到内部的数据结构上形成解析树

1.2.6.查询缓存

MySQL 8 将这块删除了，因为很鸡肋：

• 缓存匹配条件严格：需 SQL 完全一致（包括空格、注释），解析后即可确定是否匹配。
• 任何对表的写操作（INSERT/UPDATE/DELETE）会标记该表关联的所有缓存为无效。

• MySQL接收到请求后，会先看缓存中有没有（之前查询的结果会以k-v的方式存储在内存里，k是语句，v是结果）
• 一般情况下查询缓存的命中率是非常低的（除非你的数据是静态的）
• 可以通过在select 后加 SQL_CACHE 来显示指定使用查询缓存

1.2.7 Optimizer: 查询优化器。

• 通过语法解析,MySQL知道你的真实意图了，但你写的SQL不一定是高效的
• 这个时候MySQL会给我们的SQL做些优化调整（基于成本去优化），比如：使用哪个索引，外连接转换为内连接，多表连接的时候，表的连接顺序从而确定最终的执行计划
• 例如：等价变换策略：比如 x<y and x=5 优化为y>5 and x=5
  联合索引的位置调整：比如a，c，b联合索引，b=3and a=5调整为a=5andb=3
  函数查询优化：比如：min 直接从索引的左侧开始查，max从右；

1.2.8.执行

• 执行器
  • 解析完了，也优化完了，那就该执行了
  • 别急，还没完，你有权限吗？没有，直接拒绝执行，有才可以执行
  • 执行器操作的是下一层的存储引擎

1.2.9 存储引擎接口

• MySQL将操作封装成了接口，屏蔽了不同存储引擎的差异，各种存储引擎实现了这些操作接口，内部又差异化的做了各种扩展；
• 比如InnoDB锁的粒度到行级，InnoDB的事务，都是差异性的
• 我们可以通过show engines来查看支持的存储引擎
• 存储引擎同一个实例只能启用一种

1.2.10文件系统层

• 文件系统由各操作系统提供
• MySQL将其持久化的数据物理存储在磁盘上，持久化保存数据、索引、binlog、redolog、undolog、error日志、慢sql等；

1.3说明一条SQL请求的过程

1.3.1 连接

SQL客户端与与服务器建立连接，该请求被发送到连接器，连接器鉴权，

1.3.2 语法解析

首先通过mysql关键字将语句解析，会生成一个内部解析树，mysql解析器将对其解析，查看是否是有错误的关键字，关键字顺序是否正确等；

1.3.3 查询缓存

如果查询命中缓存（一个大小写敏感的哈希查找实现的）则直接返回结果，如果查询没有命中缓存，则进行下一步sql解析。

1.3.4 生成执行计划

mysql是基于成本的优化器，他将预测执行此计划的成本，并选择成本最小的那条

1.3.5 调用存储引擎接口执行

在解析和优化阶段，MySQL将生成查询对应的执行计划，由执行计划调用存储引擎的API来执行查询MySQL就行，将结果返回给客户端；即使查询不需要返回结果，MySQL也会返回影响到的行数。

1.4了解主流存储引擎特性及选择策略

1.4.1 InnoDB 引擎（默认）

1. 特性与优势
   • 支持事务处理，具备 ACID 特性（原子性、一致性、隔离性、持久性），保证数据的完整性和可靠性。
   • 采用行级锁，在高并发场景下能够有效减少锁冲突，提高并发处理能力。
   • 支持外键约束，便于维护表之间的关系，确保数据的一致性。
   • 具备良好的崩溃恢复能力，在数据库发生故障时能够快速恢复数据。
2. 劣势
   • 相对 MyISAM 引擎，其读写性能在一些简单查询场景下可能稍逊一筹。
   • 数据存储和索引占用空间相对较大。
3. 适用场景
   • 对事务完整性要求较高的应用，如电子商务系统、金融交易系统等。
   • 高并发读写的场景，例如在线事务处理（OLTP）系统。

1.4.2 MyISAM 引擎

1. 特性与优势
   • 读取速度快，特别适合执行大量的 SELECT 查询操作，其表结构简单，数据存储紧凑。
   • 不支持事务和行级锁，但支持表级锁，在对数据一致性要求不高的读多写少场景下性能较好。
   • 支持全文索引，可用于高效的文本搜索，如博客系统、新闻网站等。
2. 劣势
   • 不支持事务，无法保证数据的原子性和一致性，在数据更新频繁的场景下可能导致数据问题。
   • 不支持外键约束，不利于表间关系的维护。
3. 适用场景
   • 以读为主的应用，如 Web 应用中的静态数据查询，如用户信息查询、文章内容查询等。
   • 对全文搜索有需求的场景，如文档管理系统、论坛等。

1.4.3 Memory 引擎

1. 特性与优势
   • 数据存储在内存中，读写速度极快，适用于对读写性能要求极高的临时数据存储场景。
   • 支持哈希索引，能够快速定位数据，提高查询效率。
2. 劣势
   • 数据存储在内存中，一旦服务器关闭或重启，数据将丢失，因此不适合存储重要的持久化数据。
   • 内存资源有限，对数据量有一定限制，不适合存储大量数据。
3. 适用场景
   • 用于存储临时数据或缓存数据，如会话数据、临时计算结果等。
   • 对读写性能要求极高且数据量不大的场景，如一些实时统计系统中的中间计算结果存储。

1.4.4 选择策略

（一）根据应用需求选择

1. 如果应用需要处理大量的事务操作，确保数据的完整性和一致性至关重要，那么 InnoDB 引擎是首选。例如，银行系统中的账户交易处理，必须保证每一笔交易的原子性和数据的持久可靠，InnoDB 的事务支持和崩溃恢复能力能够满足这一需求。
2. 对于主要以读取数据为主，对数据一致性要求不高，且数据更新较少的应用，如新闻网站的文章浏览功能，MyISAM 引擎可以提供快速的查询性能，并且其全文索引功能可以方便用户进行文章搜索。
3. 在需要临时存储和快速处理数据的场景，如在一个大型电子商务网站的购物车功能中，存储用户购物车中的商品信息（在用户未结算前），Memory 引擎能够快速读写数据，提升用户体验，不过需要注意数据的备份和在合适时机将数据持久化到其他存储引擎中。

（二）考虑数据量和硬件资源

1. 如果数据量较大且硬件资源有限，InnoDB 引擎的高效存储和良好的空间管理能力可能更适合。例如，一个大型企业的客户关系管理系统，数据量随着业务增长不断增加，InnoDB 能够在有限的硬件条件下较好地处理数据存储和查询。
2. 对于内存资源充足且数据量较小的场景，Memory 引擎可以充分利用内存的高速读写特性。比如，在一个小型实时监控系统中，用于存储最近几分钟的监控数据，Memory 引擎可以快速处理这些数据，及时提供监控结果。

（三）权衡性能与功能

1. 如果对并发性能要求较高，InnoDB 的行级锁可以有效减少锁冲突，提高系统的并发处理能力。例如，在一个高并发的在线票务系统中，多个用户同时查询和预订票务，InnoDB 能够确保系统的高效运行。
2. 若应用对全文搜索功能有强烈需求，MyISAM 的全文索引支持可以提供高效的文本搜索能力。如在一个内容丰富的知识管理系统中，用户需要快速搜索文档内容，MyISAM 引擎可以满足这一功能需求。