目录
MySQL体系结构
- 连接层
- 这是最上面的一层，是一些客户端和连接服务，主要完成一些类似于连接处理、授权认证、及相关的安全方案，服务器也会对安全连接的用户进行一些权限校验的操作
- 解释：这一层就像是一个 “门卫” 或者 “接待处”。当你（客户端）想要访问 MySQL 数据库时，连接层先接待你。它会检查你是不是被允许访问这个数据库，就像检查你有没有进入大楼的权限一样。只有通过了身份验证（授权认证），你才能进入下一层去获取数据库里面的信息。例如，当你用数据库管理工具或者编程语言去连接 MySQL 数据库时，你需要提供用户名和密码，连接层就会验证这些信息，确定你是不是合法用户。
- 例子：假设你要进入一个高级会员制的图书馆（数据库），在门口（连接层），工作人员会检查你的会员卡（用户名和密码），看看你是不是会员，有没有借阅图书（访问数据）的权限。如果你的信息正确，才会让你进去找书。
- 服务层
- 第二层架构主要完成大多数的核心服务功能，如SQL接口，并完成缓存的查询，SQL的优化和分析，部分内置函数的执行。所有跨存引擎的功能也在这一层完成，比如过程、函数等
- 解释：服务层就像是一个 “图书馆管理员”，它知道图书馆（数据库）里大部分的事情。当你（客户端）提出查找某本书（执行 SQL 查询）的请求后，它会先看看自己的 “小本子”（缓存），如果之前有人找过同样的书（相同的查询），它可以直接告诉你位置（从缓存中返回结果）。如果没有，它会根据图书馆的分类规则（SQL 优化和分析）来确定最快找到这本书的方法。而且它还能提供一些其他服务，比如帮你计算书本的总价（执行部分内置函数），或者执行一些图书馆的规定流程（过程、函数等跨存储引擎的功能）。
- 例子：你想找一本特定主题的书，管理员先看了一下记忆（缓存），如果没有相关信息，就会根据图书馆的布局（SQL 优化），比如先找哪个区域，再找哪个书架，来快速找到你要的书。同时，如果图书馆有计算借书逾期费用的规定（内置函数），管理员也可以帮你计算。
- 引擎层
- 存储引擎真正的负责对mysql中数据的存储和提取，服务器通过API和存储引擎进行通信。不同的存储引擎具有不同的功能，可以根据需要来选取合适的存储引擎。
- 解释：这一层就像是图书馆里不同类型的书架。不同的书架（存储引擎）有不同的特点。有些书架（存储引擎）可能适合放小说，按照作者名字排序（一种存储和提取数据的方式）；有些书架可能适合放工具书，按照主题分类（另一种存储和提取数据的方式）。服务器就像是知道所有书架位置和特点的人，通过一定的规则（API）来和这些书架打交道，找到你想要的书（数据）。
- 例子：如果图书馆有普通木质书架和电子书架。木质书架适合存放古籍，按年代摆放；电子书架适合存放电子资料，按文件类型存放。当管理员（服务器）收到找一本书的请求后，会根据书的类型（数据特点）决定去哪个书架（存储引擎）找，并且知道怎么从这个书架上找到书（通过存储引擎的 API 进行存储和提取）
- 存储层
- 主要将数据存储在文件系统上，并完成与存储引擎的交互。
- 解释：存储层是真正放书（数据）的地方，就像是书架所在的房间（文件系统）。它和书架（存储引擎）紧密配合，书（数据）从书架（存储引擎）来，最后也存到这个房间（文件系统）里。存储引擎从这里获取要存储的数据，也把提取的数据返回给上一层。
- 例子：图书馆的房间（存储层）里有很多书架（存储引擎），这些书架用来存放图书（数据）。当新书进来（数据要存储），会根据书架（存储引擎）的规则存放到房间里相应的位置；当要找书（提取数据）时，也是从房间里的书架上获取。
存储引擎
简介
- 存储引擎就是建立索引、更新查找数据、存储数据等技术的实现方式。它是基于表的，而不是基于库的，所有也被称之为表类型
- 查询建表的语句可以看到具体的存储引擎类型，下图中的engine就是指存储引擎，默认是InnoDB类型的，也可以在创建表的时候在后面直接加上指定的存储引擎来达到想要的效果
- 也可以查看数据库的引擎支持哪些，如下方照片，engine是所支持的存储引有哪些，support表示是否支持，default表示默认，在早期的数据库版本是以MyISAM来设置为默认的，后面才渐渐改为了InnoDB，因为其支持事务回滚，就被设置为默认的，便于数据库的数据恢复和修复，增强了可靠性，下面会对不同存储引擎的特点来进行分析
不同存储引擎的特点
-
InnoDB
- InnoDB是指一种兼顾高可靠性和高性能的通用存储引擎，在MySQL5.5版本后，InnoDB是默认的MySQL存储引擎
- 特点
- 支持事务：DML 操作遵循 ACID 模型，这在处理复杂业务逻辑时非常关键。例如，在银行转账系统中，从一个账户扣款并在另一个账户入账这两个操作必须作为一个完整的事务，要么都成功，要么都失败，InnoDB 能够保证这种数据的完整性。
- 采用行级锁：大大提高了并发访问量。比如在一个电商系统中，多个用户同时购买不同商品（涉及不同行数据的操作），InnoDB 可以允许这些操作同时进行，而不会相互阻塞。
- 支持外键约束：能保证数据的完整性和正确性。如在一个订单管理系统中，订单表和商品表、用户表之间可能存在外键关系，InnoDB 可以确保这些关系的一致性
- 文件：每张InnoDB引擎存储的表都会生成对应的xxx.idb文件，其中xxx是指表名，这个文件存储了这个表的表结构、数据和索引
-
MyISAM
- MySQL早起的存储引擎
- 特点
- 不支持事务和外键约束：这使得它在处理简单的数据存储和查询场景时较为轻便，但不适用于对数据一致性要求高的复杂业务场景。
- 采用表级锁：直接锁住整个表，不支持行级锁。这意味着当一个用户对表进行写操作时，其他用户的读写操作都需要等待。不过在以读操作为主、写操作很少的应用中，这种锁机制对性能的影响可能较小。例如，在一个新闻资讯网站中，文章内容表主要是被用户查询阅读，偶尔有管理员更新文章，这种情况下 MyISAM 的表级锁对整体性能影响不大。而且它的访问速度快，适用于对查询性能要求较高的场景。
- 文件：采用MyISAM存储的表，会生成三个对应的文件，xxx.MYD，xxx.MYI，xxx.sdi这三种，分别表示存储表的数据、存储表的索引和存储表的结构信息
-
Memory
- 存放的数据存储在内存中，这导致受到硬件问题或者断电问题的时候会出现数据丢失，只能将这些表作为临时表或者缓存使用
- 特点
- 内存存放：数据存储在内存中，使得访问速度极快。例如，在一个缓存用户登录信息的系统中，当用户登录时，可以快速从内存中获取用户信息，提高用户体验。
- 支持 hash 索引：这进一步提高了数据查询的速度。
- 文件：只有一种 xxx.sdi 文件用于存储表结构。不过，由于数据存储在内存中，受到硬件问题（如内存故障）或者断电问题时会出现数据丢失情况，所以只能将这些表作为临时表或者缓存使用，并且对表的大小有限制，太大的表无法完全缓存在内存中，也无法保障数据的安全性
存储引擎的选择
- InnoDB
- 作为 MySQL 的默认存储引擎，InnoDB 在很多场景中表现出色。当应用对事务的完整性有较高要求时，InnoDB 是首选。例如，在金融交易系统、企业资源规划（ERP）系统等复杂业务应用中，数据的准确性和一致性至关重要。而且在并发条件下，如果需要保证数据的一致性，特别是数据操作除了插入和查询之外，还包含大量的更新、删除操作，InnoDB 存储引擎是非常合适的选择。它通过支持事务、行级锁和外键约束等特性，能够有效地处理这些复杂的业务场景，避免数据冲突和不一致问题。
- MyISAM
- 如果应用是以读操作和插入操作为主，更新和删除操作很少，并且对事务的完整性、并发性要求不是很高，那么 MyISAM 是一个不错的选择。比如一些内容管理系统（CMS），主要功能是展示文章、图片等内容（读操作），管理员偶尔添加新内容（插入操作），这种场景下 MyISAM 的快速访问速度优势能够得到充分发挥，同时由于其简单的锁机制，在这种低并发写操作的环境中也不会产生明显的性能问题。
- Memory
- MEMORY 存储引擎适用于对访问速度要求极高的临时数据存储场景。由于所有数据保存在内存中，它的访问速度比其他存储引擎快很多。通常用于临时表及缓存，比如在数据库查询过程中的临时结果集存储，或者缓存一些经常访问但数据量不大的数据。然而，MEMORY 也有明显的缺陷，它对表的大小有限制，太大的表无法完全缓存在内存中，而且由于数据存储在易失性的内存中，一旦出现硬件故障或断电，数据就会丢失，无法保障数据的安全性。因此，在使用 MEMORY 存储引擎时，需要充分考虑数据的重要性和持久性要求，以及硬件环境的稳定性。同时，需要设计合适的数据备份和恢复策略，以应对可能出现的数据丢失情况。