共计 4630 个字符，预计需要花费 12 分钟才能阅读完成。
这篇文章给大家分享的是有关 MySql 优化之体系结构及存储引擎的示例分析的内容。丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，一起跟随丸趣 TV 小编过来看看吧。
一、MySQL 结构体系
总体上，我们可以把 MySQL 分成三层，分层再详细一点的话可以将存储引擎层再分为引擎层和存储层：
连接层
最上层是一些客户端和链接服务，包含本地 sock 通信和大多数基于客户端 / 服务端工具实现的类似于 TCP/IP 的通信。主要完成一些类似于连接处理、授权认证、及相关的安全方案。在该层上引入了线程池的概念，为通过认证安全接入的客户端提供线程。同样在该层上可以实现基于 SSL 的安全链接。服务器也会为安全接入的每个客户端验证它所具有的操作权限。
服务层
第二层架构主要完成大多数的核心服务功能，如 SQL 接口，并完成缓存的查询，SQL 的分析和优化，部分内置函数的执行。所有跨存储引擎的功能也在这一层实现，如 过程、函数等。在该层，服务器会解析查询并创建相应的内部解析树，并对其完成相应的优化如确定表的查询的顺序，是否利用索引等，最后生成相应的执行操作。如果是 select 语句，服务器还会查询内部的缓存，如果缓存空间足够大，这样在解决大量读操作的环境中能够很好的提升系统的性能。
引擎层
存储引擎层，存储引擎真正的负责了 MySQL 中数据的存储和提取，服务器通过 API 和存储引擎进行通信。不同的存储引擎具有不同的功能，这样我们可以根据自己的需要，来选取合适的存储引擎。
存储层
数据存储层，主要是将数据存储在文件系统之上，并完成与存储引擎的交互。和其他数据库相比，MySQL 有点与众不同，它的架构可以在多种不同场景中应用并发挥良好作用。主要体现在存储引擎上，插件式的存储引擎架构，将查询处理和其他的系统任务以及数据的存储提取分离。这种架构可以根据业务的需求和实际需要选择合适的存储引擎。
二、MySQL Server 组成部分
MySQL 结构各层又由一个或数个部分构成：
连接层组成部分
Connectors：交互接口
MySQL 向外提供的交互组件，如 java,.net,php 等语言可以通过该组件来操作 SQL 语句，实现与 SQL 的交互
服务层组成部分
Connection Pool : 连接池组件
用于管理、缓冲用户的连接，线程处理等需要缓存的需求
Management Services Utilities : 管理服务和工具组件
用于系统管理和控制工具，例如备份恢复、Mysql 复制、集群、安全管理等
SQL Interface : SQL 接口组件
用于接受用户的 SQL 命令，如 DML,DDL 和存储过程等，并将最终结果返回给用户
Parser : 查询分析器组件
SQL 命令传递到解析器的时候会被解析器验证和解析，首先分析 SQL 命令语法的合法性，并尝试将 SQL 命令分解成数据结构，若分解失败，则提示 SQL 语句不合理
Optimizer : 优化器组件
SQL 语句在查询之前会使用查询优化器对查询进行优化。
如：select id,name from user where age = 20;
这个 select 查询先根据 where 语句进行选取，而不是先将表全部查询出来以后再进行 age 过滤
这个 select 查询先根据 id 和 name 进行属性投影，而不是将属性全部取出以后再进行过滤
将这两个查询条件联接起来生成最终查询结果
Caches Buffers : 缓冲池组件
如果查询缓存有命中的查询结果，查询语句就可以直接去查询缓存中取数据。这个缓存机制是由一系列小缓存组成的。比如表缓存，记录缓存，key 缓存，权限缓存等
引擎层组成部分
Pluggable Storage Engines : 存储引擎
存储引擎就是存储数据，建立索引，更新查询数据等等技术的实现方式。存储引擎是基于表的，而不是基于库的。所以存储引擎也可被称为表类型。对于表的创建，数据的存储，检索，更新等都是由 MySQL 存储引擎完成的，这也是 MySQL 存储引擎在 MySQL 中扮演的重要角色。
MYSQL 提供了插件式的存储引擎架构，所以用户可以根据不同的需求为数据表选择不同的存储引擎，用户也可以根据自己的需要编写自己的存储引擎，或者编写存储引擎。甚至一个库中不同的表使用不同的存储引擎，这些都是允许的。
存储层组成部分
File System : 文件系统
用于实际存储 MySQL 数据库文件和一些日志文件等的系统。常见的如 Linux、Windows 等。
三、存储引擎
常用的存储引擎区别
在 MySQL 5.5 版本之前，默认的存储引擎是 MyISAM，它是 MySQL 自带的。5.5 版本之后默认的存储引擎改成了 InnoDB，它是第三方公司为 MySQL 开发的。为什么要改呢？
最主要的原因还是 InnoDB 支持事务，支持行级别的锁，对于业务一致性要求高的场景来说更适合。
不同存储引擎建表语句：
CREATE TABLE `user_innodb` ( `id` int(11) PRIMARY KEY AUTO_INCREMENT,
`name` varchar(255) DEFAULT NULL,
`gender` tinyint(1) DEFAULT NULL,
`phone` varchar(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE `user_myisam` ( `id` int(11) PRIMARY KEY AUTO_INCREMENT,
`name` varchar(255) DEFAULT NULL,
`gender` tinyint(1) DEFAULT NULL,
`phone` varchar(11) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4;
CREATE TABLE `user_memory` ( `id` int(11) PRIMARY KEY AUTO_INCREMENT,
`name` varchar(255) DEFAULT NULL,
`gender` tinyint(1) DEFAULT NULL,
`phone` varchar(11) DEFAULT NULL
) ENGINE=MEMORY DEFAULT CHARSET=utf8mb4;
CREATE TABLE `user_archive` ( `id` int(11) PRIMARY KEY AUTO_INCREMENT,
`name` varchar(255) DEFAULT NULL,
`gender` tinyint(1) DEFAULT NULL,
`phone` varchar(11) DEFAULT NULL
) ENGINE=Archive DEFAULT CHARSET=utf8mb4;
CREATE TABLE `user_csv` ( `id` int(11) NOT NULL,
`name` varchar(255) NOT NULL,
`gender` tinyint(1) NOT NULL,
`phone` varchar(11) NOT NULL
) ENGINE=CSV DEFAULT CHARSET=utf8mb4;InnoDB
InnoDB 存储引擎是如今 MySQL 的默认存储引擎。InnoDB 存储引擎提供了具有提交、回滚、崩溃恢复能力的事务安全。但是对比 MyISAM 的存储引擎，InnoDB 写的处理效率差一些，并且会占用更多的磁盘空间以保留数据和索引。
InnoDB 存储引擎不同于其他存储引擎的特点：
事务控制
外键约束
InnoDB 存储表和索引有以下两种方式：
使用共享表空间存储，这种方式创建的表的表结构保存在.frm 文件中，数据和索引保存在 innodb_data_home_dir 和 innodb_data_file_path 定义的表空间中，可以是多个文件。
使用多表空间存储，这种方式创建的表的表结构仍然存在 .frm 文件中，但是每个表的数据和索引单独保存在 .ibd 中。
InnoDB 适合的使用环境：
InnoDB 是 MySQL 的默认存储引擎，用于事务处理应用程序，支持外键。如果应用对事务的完整性有比较高的要求，在并发条件下要求数据的一致性，数据操作除了插入和查询意外，还包含很多的更新、删除操作，那么 InnoDB 存储引擎是比较合适的选择。
InnoDB 存储引擎除了有效的降低由于删除和更新导致的锁定，还可以确保事务的完整提交和回滚，对于类似于计费系统或者财务系统等对数据准确性要求比较高的系统，InnoDB 是最合适的选择。
MyISAM
MyISAM 不支持事务、也不支持外键，其优势是访问的速度快，对事务的完整性没有要求或者以 SELECT、INSERT 为主的应用基本上都可以使用这个引擎来创建表。
有以下两个比较重要的特点：
不支持事务
文件存储方式
每个 MyISAM 在磁盘上存储成 3 个文件，其文件名都和表名相同，但拓展名分别是：
.frm (存储表定义)；
.MYD(MYData , 存储数据)；
.MYI(MYIndex , 存储索引)；
MyISAM 适合的使用环境：
如果应用是以读操作和插入操作为主，只有很少的更新和删除操作，并且对事务的完整性、并发性要求不是很高，那么选择这个存储引擎是非常合适的。
MEMORY
Memory 存储引擎将表的数据存放在内存中。每个 MEMORY 表实际对应一个磁盘文件，格式是.frm，该文件中只存储表的结构，而其数据文件，都是存储在内存中，这样有利于数据的快速处理，提高整个表的效率。
MEMORY 类型的表访问非常地快，因为他的数据是存放在内存中的，并且默认使用 HASH 索引，但是服务一旦关闭，表中的数据就会丢失。
MEMORY 适合的使用环境：
将所有数据保存在 RAM 中，在需要快速定位记录和其他类似数据环境下，可以提供几块的访问。
MEMORY 的缺陷就是对表的大小有限制，太大的表无法缓存在内存中，其次是要确保表的数据可以恢复，数据库异常终止后表中的数据是可以恢复的。MEMORY 表通常用于更新不太频繁的小表，用以快速得到访问结果。
MERGE
MERGE 存储引擎是一组 MyISAM 表的组合，这些 MyISAM 表必须结构完全相同，MERGE 表本身并没有存储数据，对 MERGE 类型的表可以进行查询、更新、删除操作，这些操作实际上是对内部的 MyISAM 表进行的。
对于 MERGE 类型表的插入操作，是通过 INSERT_METHOD 子句定义插入的表，可以有 3 个不同的值，使用 FIRST 或 LAST 值使得插入操作被相应地作用在第一或者最后一个表上，不定义这个子句或者定义为 NO，表示不能对这个 MERGE 表执行插入操作。
可以对 MERGE 表进行 DROP 操作，但是这个操作只是删除 MERGE 表的定义，对内部的表是没有任何影响的。
MERGE 适合的使用环境：
用于将一系列等同的 MyISAM 表以逻辑方式组合在一起，并作为一个对象引用他们。
MERGE 表的优点在于可以突破对单个 MyISAM 表的大小限制，并且通过将不同的表分布在多个磁盘上，可以有效的改善 MERGE 表的访问效率。这对于存储诸如数据仓储等 VLDB 环境十分合适。
感谢各位的阅读！关于“MySql 优化之体系结构及存储引擎的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！
