MySQL存储结构

MySQL体系结构:

1.网络接入层
提供了应用程序接入MySQL服务的接口。客户端与服务端建立连接,客户端发送SQL到服务端。
2.服务层
管理工具和服务
系统管理和控制工具,例如备份恢复、Mysql复制、集群等
连接池
主要负责连接管理、授权认证、安全等等。每个客户端连接都对应着服务器上的一个线程。
SQL接口
接受用户的SQL命令,并且返回用户操作的结果。
查询解析器
SQL命令传递到解析器的时候会被解析器验证和解析。
查询优化器
SQL语句在查询之前会使用查询优化器对查询进行优化。
缓存
查询缓存,如果查询缓存有命中的查询结果,查询语句就可以直接去查询缓存中取数据。
3.存储引擎层
负责数据的存储和读取,与数据库文件打交道。 服务器中的查询执行引擎通过API与存储引擎进行通信,通过接口屏蔽了不同存储引擎之间的差异。
存储引擎是基于表的。
4.文件系统层
该层主要是将数据库的数据存储在文件系统之上,并完成与存储引擎的交互。

Sql执行过程:
MySQL存储结构_第1张图片

存储引擎:

MySQL区别于其他数据库的最重要的一个特点就是插件式的表存储引擎,也就是说存储引擎是基于表的。
存储引擎的概念是MySQL里面才有的。
– 查看MySQL版本
select version();

– 查看版本支持的存储引擎
show engines;

官网5.7版本支持的10种存储引擎:

MyISAM: 拥有较高的插入,查询速度,但不支持事务
InnoDB :5.5.8版本后Mysql的默认数据库引擎,支持ACID事务,支持行级锁定
BDB: 源自Berkeley DB,事务型数据库的另一种选择,支持COMMIT和ROLLBACK等其他事务特性
Memory :所有数据置于内存的存储引擎,拥有极高的插入,更新和查询效率。但是会占用和数据量成正比的内存空间。并且其内容会在Mysql重新启动时丢失
Merge :将一定数量的MyISAM表联合而成一个整体,在超大规模数据存储时很有用
Archive :非常适合存储大量的独立的,作为历史记录的数据。因为它们不经常被读取。Archive拥有高效的插入速度,但其对查询的支持相对较差
Federated: 将不同的Mysql服务器联合起来,逻辑上组成一个完整的数据库。非常适合分布式应用
Cluster/NDB :高冗余的存储引擎,用多台数据机器联合提供服务以提高整体性能和安全性。适合数据量大,安全和性能要求高的应用
CSV: 逻辑上由逗号分割数据的存储引擎。它会在数据库子目录里为每个数据表创建一个.CSV文件。这是一种普通文本文件,每个数据行占用一个文本行。CSV存储引擎不支持索引。
BlackHole :黑洞引擎,写入的任何数据都会消失,一般用于记录binlog做复制的中继

存储引擎为MyISAM:

*.frm:与表相关的元数据信息都存放在frm文件,包括表结构的定义信息等
*.MYD:MyISAM DATA,用于存储MyISAM表的数据
*.MYI:MyISAM INDEX,用于存储MyISAM表的索引相关信息

MyISAM既不支持事务、也不支持外键、其优势是访问速度快,但是表级别的锁定限制了它在读写负载方面的性能,因此它经常应用于只读或者以读为主的数据场景。默认使用B+TREE数据结构存储索引。

特点:
不支持事务
表级锁定(更新时锁定整个表)
读写互相阻塞(写入时阻塞读入、读时阻塞写入;但是读不会互相阻塞)
只会缓存索引(通过key_buffer_size缓存索引,但是不会缓存数据)
不支持外键
读取速度快
业务场景:
不需要支持事务的场景(像银行转账之类的不可行)
一般读数据的较多的业务
数据修改相对较少的业务
数据一致性要求不是很高的业务
MyISAM引擎调优:
设置合适索引
启用延迟写入,尽量一次大批量写入,而非频繁写入
尽量顺序insert数据,让数据写入到尾部,减少阻塞
降低并发数,高并发使用排队机制
MyISAM的count只有全表扫描比较高效,带有其它条件都需要进行实际数据访问

存储引擎为InnoDB:

InnoDB主要包括了内存池、后台线程以及存储文件。INNODB的三大特性:插入缓存,两次写,自适应hash。
*.frm:与表相关的元数据信息都存放在frm文件,包括表结构的定义信息等
*.ibd:InnoDB DATA,表数据和索引的文件。该表的索引(B+树)的每个非叶子节点存储索引,叶子节点存储索引和索引对应的数据。

InnoDB 是一个事务安全的存储引擎,它具备提交、回滚以及崩溃恢复的功能以保护用户数据。InnoDB 的行级别锁定保证数据一致性提升了它的多用户并发数以及性能。InnoDB 将用户数据存储在聚集索引中以减少基于主键的普通查询所带来的 I/O 开销。为了保证数据的完整性,InnoDB 还支持外键约束。默认使用B+TREE数据结构存储索引。

特点:
支持事务,支持4个事务隔离(ACID)级别
行级锁定(更新时锁定当前行)
读写阻塞与事务隔离级别相关
既能缓存索引又能缓存数据
支持外键
InnoDB更消耗资源,读取速度没有MyISAM快
在InnoDB中存在着缓冲管理,通过缓冲池,将索引和数据全部缓存起来,加快查询的速度;
对于InnoDB类型的表,其数据的物理组织形式是聚簇表。所有的数据按照主键来组织。数据和索引放在一块,都位于B+数的叶子节点上;

业务场景:
需要支持事务的场景(银行转账之类)
适合高并发,行级锁定对高并发有很好的适应能力,但需要确保查询是通过索引完成的
数据修改较频繁的业务
InnoDB引擎调优:
主键尽可能小,否则会给Secondary index带来负担
避免全表扫描,这会造成锁表
尽可能缓存所有的索引和数据,减少IO操作
避免主键更新,这会造成大量的数据移动

Memory引擎:

在内存中创建表。每个MEMORY表只实际对应一个磁盘文件(frm 表结构文件)。MEMORY类型的表访问非常得快,因为它的数据是放在内存中的,并且默认使用HASH索引。要记住,在用完表格之后就删除表格,不然一直占据内存空间。

特点:
支持的数据类型有限制,比如:不支持TEXT和BLOB类型(长度不固定),对于字符串类型的数据,只支持固定长度的行,VARCHAR会被自动存储为CHAR类型;
支持的锁粒度为表级锁。所以,在访问量比较大时,表级锁会成为MEMORY存储引擎的瓶颈;
由于数据是存放在内存中,一旦服务器出现故障,数据都会丢失;
查询的时候,如果有用到临时表,而且临时表中有BLOB,TEXT类型的字段,那么这个临时表就会转化为MyISAM类型的表,性能会急剧降低;
默认使用hash索引。
如果一个内部表很大,会转化为磁盘表。
业务场景:
那些内容变化不频繁的代码表,或者作为统计操作的中间结果表,便于高效地堆中间结果进行分析并得到最终的统计结果。
目标数据比较小,而且非常频繁的进行访问,在内存中存放数据,如果太大的数据会造成内存溢出。可以通过参数max_heap_table_size控制Memory表的大小,限制Memory表的最大的大小。
数据是临时的,而且必须立即可用得到,那么就可以放在内存中。
存储在Memory表中的数据如果突然间丢失的话也没有太大的关系。

参考
https://blog.csdn.net/wangfeijiu/article/details/112454405

你可能感兴趣的:(MySQL,mysql,数据库)