MySQL数据库存储引擎简介

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS MySQL,高可用系列 2核4GB
简介: MySQL数据库存储引擎简介

<!--
title: MySQL数据库存储引擎简介
date: 2018-10-06 11:44:13
categories:

  • data
  • DB
  • MySQL

tags: [data,database,数据库,DB,MySQL]
-->

MySQL 提供了多个存储引擎——包括处理事务安全表的引擎和处理非事务安全表的引擎,在 MySQL 中,不需要在整个服务器中使用同一种存储引擎,针对具体的要求,可以对每一个表使用不同的存储引擎。

存储引擎简介

MySQL中的数据用各种不同的技术存储在文件(或者内存)中。

这些技术中的每一种技术都使用不同的存储机制、索引技巧、锁定水平并且最终提供广泛的不同的功能和能力。

通过选择不同的技术,你能够获得额外的速度或者功能,从而改善你的应用的整体功能。

而存储引擎说白了就是
  • 如何存储数据
  • 如何为存储的数据建立索引
  • 如何更新、查询数据

等技术的实现方法。

例如,如果你在研究大量的临时数据,你也许需要使用内存存储引擎,因为内存存储引擎能够在内存中存储所有的表格数据。又或者,你也许需要一个支持事务处理的数据库,以确保事务处理不成功时数据的回退能力,你就要选择支持事务的存储引擎。

存储引擎分类介绍

下面就简单介绍一下MySQL的存储引擎。

InnoDB

InnoDB是一个健壮的事务型存储引擎,这种存储引擎已经被很多互联网公司使用,为用户操作非常大的数据存储提供了一个强大的解决方案。

InnoDB还引入了行级锁定和外键约束,在以下场合下,使用InnoDB是最理想的选择:

  • 更新密集的表。
    InnoDB存储引擎特别适合处理多重并发的更新请求。
  • 事务。
    InnoDB存储引擎是支持事务的标准MySQL存储引擎。
  • 自动灾难恢复。
    与其它存储引擎不同,InnoDB表能够自动从灾难中恢复。
  • 外键约束。
    MySQL支持外键的存储引擎只有InnoDB。
  • 支持自动增加列AUTO_INCREMENT属性。
  • 从5.7开始innodb存储引擎成为默认的存储引擎。

一般来说,如果需要事务支持,并且有较高的并发读取频率,InnoDB是不错的选择。

MyISAM

MyISAM表是独立于操作系统的,这说明可以轻松地将其从Windows服务器移植到Linux服务器。

每当我们建立一个MyISAM引擎的表时,就会在本地磁盘上建立三个文件,文件名就是表名。

例如,我建立了一个MyISAM引擎的tb_Demo表,那么就会生成以下三个文件:

  • tb_demo.frm,存储表定义。
  • tb_demo.MYD,存储数据。
  • tb_demo.MYI,存储索引。

MyISAM表无法处理事务,这就意味着有事务处理需求的表,不能使用MyISAM存储引擎。MyISAM存储引擎特别适合在以下几种情况下使用:

  1. 选择密集型的表。
    MyISAM存储引擎在筛选大量数据时非常迅速,这是它最突出的优点。
  2. 插入密集型的表。
    MyISAM的并发插入特性允许同时选择和插入数据。

由此看来,MyISAM存储引擎很适合管理服务器日志数据。

MRG_MYISAM

MRG_MyISAM存储引擎是一组MyISAM表的组合,老版本叫 MERGE 其实是一回事儿。

这些MyISAM表结构必须完全相同,尽管其使用不如其它引擎突出,但是在某些情况下非常有用。

说白了,Merge表就是几个相同MyISAM表的聚合器;Merge表中并没有数据,对Merge类型的表可以进行查询、更新、删除操作,这些操作实际上是对内部的MyISAM表进行操作。

Merge存储引擎的使用场景

对于服务器日志这种信息,一般常用的存储策略是将数据分成很多表,每个名称与特定的时间段相关。

例如,可以用12个相同的表来存储服务器日志数据,每个表用对应各个月份的名字来命名。当有必要基于所有12个日志表的数据来生成报表,这意味着需要编写并更新多表查询,以反映这些表中的信息。与其编写这些可能出现错误的查询,不如将这些表合并起来使用一条查询,之后再删除Merge表,而不影响原来的数据,删除Merge表只是删除Merge表的定义,对内部的表没有任何影响。

Merge存储引擎的使用方法

  • ENGINE=MERGE,

指明使用MERGE引擎,其实是跟MRG_MyISAM一回事儿,也是对的,在MySQL 5.7已经看不到MERGE了。

  • UNION=(t1, t2),

指明了MERGE表中挂接了些哪表,可以通过alter table的方式修改UNION的值,以实现增删MERGE表子表的功能。比如:

alter table tb_merge engine=merge union(tb_log1) insert_method=last;
  • INSERT_METHOD=LAST,

INSERT_METHOD指明插入方式,取值可以是:
0 不允许插入;
FIRST 插入到UNION中的第一个表;
LAST 插入到UNION中的最后一个表。

  • MERGE表及构成MERGE数据表结构的各成员数据表必须具有完全一样的结构。

每一个成员数据表的数据列必须按照同样的顺序定义同样的名字和类型,索引也必须按照同样的顺序和同样的方式定义。

MEMORY

使用MySQL Memory存储引擎的出发点是速度,为得到最快的响应时间,采用的逻辑存储介质是系统内存。

虽然在内存中存储表数据确实会提供很高的性能,但当mysqld守护进程崩溃时,所有的Memory数据都会丢失。

获得速度的同时也带来了一些缺陷。

它要求存储在Memory数据表里的数据使用的是长度不变的格式,这意味着不能使用BLOB和TEXT这样的长度可变的数据类型。VARCHAR是一种长度可变的类型,但因为它在MySQL内部当做长度固定不变的CHAR类型,所以可以使用。

一般在以下几种情况下使用Memory存储引擎:

  • 目标数据较小,而且被非常频繁地访问。

在内存中存放数据,所以会造成内存的使用,可以通过参数max_heap_table_size控制Memory表的大小,设置此参数,就可以限制Memory表的最大大小。

  • 如果数据是临时的,而且要求必须立即可用,那么就可以存放在内存表中。
  • 存储在Memory表中的数据如果突然丢失,不会对应用服务产生实质的负面影响。
  • Memory同时支持散列索引和B树索引。

B树索引优于散列索引的是,可以使用部分查询和通配查询,也可以使用<、>和>=等操作符方便数据挖掘。

散列索引进行“相等比较”非常快,但是对“范围比较”的速度就慢多了,因此散列索引值适合使用在=和<>的操作符中,不适合在<或>操作符中,也同样不适合用在order by子句中。

CSV

CSV 存储引擎是基于 CSV 格式文件存储数据。

  • CSV 存储引擎因为自身文件格式的原因,所有列必须强制指定 NOT NULL 。
  • CSV 引擎也不支持索引,不支持分区。
  • CSV 存储引擎也会包含一个存储表结构的 .frm 文件,还会创建一个 .csv 存储数据的文件,还会创建一个同名的元信息文件,该文件的扩展名为 .CSM ,用来保存表的状态及表中保存的数据量。
  • 每个数据行占用一个文本行。

因为 csv 文件本身就可以被Office等软件直接编辑,保不齐就有不按规则出牌的情况,如果出现csv 文件中的内容损坏了的情况,也可以使用 CHECK TABLE 或者 REPAIR TABLE 命令检查和修复。

ARCHIVE

Archive是归档的意思,在归档之后很多的高级功能就不再支持了,仅仅支持最基本的插入和查询两种功能。

在MySQL 5.5版以前,Archive是不支持索引,但是在MySQL 5.5以后的版本中就开始支持索引了。

Archive拥有很好的压缩机制,它使用zlib压缩库,在记录被请求时会实时压缩,所以它经常被用来当做仓库使用。

BLACKHOLE

MySQL在5.x系列提供了Blackhole引擎–“黑洞”,其作用正如其名字一样:任何写入到此引擎的数据均会被丢弃掉, 不做实际存储;Select语句的内容永远是空。

这和Linux中的 /dev/null 文件完成的作用完全一致。

那么, 一个不能存储数据的引擎有什么用呢?

Blackhole虽然不存储数据,但是MySQL还是会正常的记录下Binlog,而且这些Binlog还会被正常的同步到Slave上,可以在Slave上对数据进行后续的处理。

这样对于在Master上只需要Binlog而不需要数据的场合下,balckhole就有用了。

BlackHole 还可以用在以下场景

  • 验证语法
    验证dump file语法的正确性
  • 检测负载
    以使用blackhole引擎来检测binlog功能所需要的额外负载
  • 检测性能

由于blackhole性能损耗极小,可以用来检测除了存储引擎这个功能点之外的其他MySQL功能点的性能。

PERFORMANCE_SCHEMA

主要用于收集数据库服务器性能参数。

MySQL用户是不能创建存储引擎为PERFORMANCE_SCHEMA的表,一般用于记录binlog做复制的中继。

在这里有官方的一些介绍: MySQL Performance Schema

FEDERATED

主要用于访问其它远程MySQL服务器一个代理,它通过创建一个到远程MySQL服务器的客户端连接,并将查询传输到远程服务器执行,而后完成数据存取;在MariaDB上的实现是FederatedX。

其他

这里列举一些其它数据库提供的存储引擎,OQGraph、SphinxSE、TokuDB、Cassandra、CONNECT、SQUENCE。

提供的名字仅供参考,想了解细节的小伙伴可以自行查阅资料。

常用引擎对比

不同存储引起都有各自的特点,为适应不同的需求,需要选择不同的存储引擎,所以首先考虑这些存储引擎各自的功能和兼容。 | 特性 | InnoDB | MyISAM | MEMORY | ARCHIVE | | ---- | ----- | ------- | ------ | ------- | | 存储限制(Storage limits) | 64TB | No | YES | No | | 支持事物(Transactions) | Yes | No | No | No | | 锁机制(Locking granularity) | 行锁 | 表锁 | 表锁 | 行锁 | | B树索引(B-tree indexes) | Yes | Yes | Yes | No | | T树索引(T-tree indexes) | No | No | No | No | | 哈希索引(Hash indexes) | Yes | No | Yes | No | | 全文索引(Full-text indexes) | Yes | Yes | No | No | | 集群索引(Clustered indexes) | Yes | No | No | No | | 数据缓存(Data caches) | Yes | No | N/A | No | | 索引缓存(Index caches) | Yes | Yes | N/A | No | | 数据可压缩(Compressed data) | Yes | Yes | No | Yes | | 加密传输(Encrypted data [1]) | Yes | Yes | Yes | Yes | | 集群数据库支持(Cluster databases support) | No | No | No | No | | 复制支持(Replication support [2]) | Yes | No | No | Yes | | 外键支持(Foreign key support) | Yes | No | No | No | | 存储空间消耗(Storage Cost) | 高 | 低 | N/A | 非常低 | | 内存消耗(Memory Cost) | 高 | 低 | N/A | 低 | | 数据字典更新(Update statistics for data dictionary) | Yes | Yes | Yes | Yes | | 备份/时间点恢复(backup/point-in-time recovery [3]) | Yes | Yes | Yes | Yes | | 多版本并发控制(Multi-Version Concurrency Control/MVCC) | Yes | No | No | No | | 批量数据写入效率(Bulk insert speed) | 慢 | 快 | 快 | 非常快 | | 地理信息数据类型(Geospatial datatype support) | Yes | Yes | No | Yes | | 地理信息索引(Geospatial indexing support [4]) | Yes | Yes | No | Yes | ## 存储引擎相关操作命令 ### 查看存储引擎 使用“SHOW VARIABLES LIKE '%storage_engine%';” 命令在mysql系统变量搜索默认设置的存储引擎,输入语句如下: ```sql mysql> SHOW VARIABLES LIKE '%storage_engine%'; +----------------------------------+---------+ | Variable_name | Value | |----------------------------------+---------| | default_storage_engine | InnoDB | | default_tmp_storage_engine | InnoDB | | disabled_storage_engines | | | internal_tmp_disk_storage_engine | InnoDB | +----------------------------------+---------+ 4 rows in set Time: 0.005s ``` 使用`SHOW ENGINES;`命令显示安装以后可用的所有的支持的存储引擎和默认引擎,后面带上 `\G` 可以列表输出结果,你可以尝试一下`SHOW ENGINES\G;`。 ```sql mysql> SHOW ENGINES; +--------------------+---------+--------------------------------------+-------------+--------+-----------+ | Engine | Support | Comment | Transactions| XA | Savepoints| |--------------------+---------+--------------------------------------+-------------+--------+-----------| | InnoDB | DEFAULT | Supports transactions, | YES | YES | YES | | | | row-level locking, and foreign keys | | | | | MRG_MYISAM | YES | Collection of identical MyISAM tables| NO | NO | NO | | MEMORY | YES | Hash based, stored in memory, useful | NO | NO | NO | | | | for temporary tables | | | | | BLACKHOLE | YES | /dev/null storage engine (anything | NO | NO | NO | | | | you write to it disappears) | | | | | MyISAM | YES | MyISAM storage engine | NO | NO | NO | | CSV | YES | CSV storage engine | NO | NO | NO | | ARCHIVE | YES | Archive storage engine | NO | NO | NO | | PERFORMANCE_SCHEMA | YES | Performance Schema | NO | NO | NO | | FEDERATED | NO | Federated MySQL storage engine | | | | +--------------------+---------+--------------------------------------+-------------+--------+-----------+ ``` 由上面命令输出,可见当前系统的默认数据表类型是InnoDB。当然,我们可以通过修改数据库配置文件中的选项,设定默认表类型。 ### 设置存储引擎 对上面数据库存储引擎有所了解之后,你可以在`my.cnf` 配置文件中设置你需要的存储引擎,这个参数放在 [mysqld] 这个字段下面的 default_storage_engine 参数值,例如下面配置的片段 ```bash [mysqld] default_storage_engine=CSV ``` ### 在创建表的时候,对表设置存储引擎 例如: ```sql CREATE TABLE `user` ( `id` int(100) unsigned NOT NULL AUTO_INCREMENT, `name` varchar(32) NOT NULL DEFAULT '' COMMENT '姓名', `mobile` varchar(20) NOT NULL DEFAULT '' COMMENT '手机', PRIMARY KEY (`id`) )ENGINE=InnoDB; ``` 在创建用户表 user 的时候,SQL语句最后 ENGINE=InnoDB 就是设置这张表存储引擎为 InnoDB。 ## 如何选择合适的存储引擎 可以根据上文中的 常用引擎对比来选择你使用的存储引擎。 使用哪种引擎需要根据需求灵活选择,一个数据库中多个表可以使用不同的引擎以满足各种性能和实际需求。 使用合适的存储引擎,将会提高整个数据库的性能。 下面提供几个选择标准,然后按照标准,根据实际情况,选择对应的存储引擎即可: 1. 是否需要支持事务; 2. 是否需要使用热备; 3. 崩溃恢复,能否接受崩溃; 4. 是否需要外键支持; 5. 存储的限制; 6. 对索引和缓存的支持。
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
9天前
|
关系型数据库 MySQL Linux
MySQL原理简介—6.简单的生产优化案例
本文介绍了数据库和存储系统的几个主题: 1. **MySQL日志的顺序写和数据文件的随机读指标**:解释了磁盘随机读和顺序写的原理及对数据库性能的影响。 2. **Linux存储系统软件层原理及IO调度优化原理**:解析了Linux存储系统的分层架构,包括VFS、Page Cache、IO调度等,并推荐使用deadline算法优化IO调度。 3. **数据库服务器使用的RAID存储架构**:介绍了RAID技术的基本概念及其如何通过多磁盘阵列提高存储容量和数据冗余性。 4. **数据库Too many connections故障定位**:分析了MySQL连接数限制问题的原因及解决方法。
|
10天前
|
SQL Java 关系型数据库
MySQL原理简介—3.生产环境的部署压测
本文介绍了Java系统和数据库在高并发场景下的压测要点: 1. 普通系统在4核8G机器上每秒能处理几百个请求 2. 高并发下数据库建议使用8核16G或更高配置的机器 3. 数据库部署后需进行基准压测,以评估其最大承载能力 4. QPS和TPS的区别及重要性 5. 压测时需关注IOPS、吞吐量、延迟 6. 除了QPS和TPS,还需监控CPU、内存、磁盘IO、网络带宽 7. 影响每秒可处理并发请求数的因素包括线程数、CPU、内存、磁盘IO和网络带宽 8. Sysbench是数据库压测工具,可构造测试数据并模拟高并发场景 9. 在增加线程数量的同时,必须观察机器的性能,确保各硬件负载在合理范围
113 72
|
7天前
|
SQL 存储 关系型数据库
MySQL原理简介—9.MySQL索引原理
本文详细介绍了MySQL索引的设计与使用原则,涵盖磁盘数据页的存储结构、页分裂机制、主键索引设计及查询过程、聚簇索引和二级索引的原理、B+树索引的维护、联合索引的使用规则、SQL排序和分组时如何利用索引、回表查询对性能的影响以及索引覆盖的概念。此外还讨论了索引设计的案例,包括如何处理where筛选和order by排序之间的冲突、低基数字段的处理方式、范围查询字段的位置安排,以及通过辅助索引来优化特定查询场景。总结了设计索引的原则,如尽量包含where、order by、group by中的字段,选择离散度高的字段作为索引,限制索引数量,并针对频繁查询的低基数字段进行特殊处理等。
MySQL原理简介—9.MySQL索引原理
|
7天前
|
SQL 监控 关系型数据库
MySQL原理简介—12.MySQL主从同步
本文介绍了四种为MySQL搭建主从复制架构的方法:异步复制、半同步复制、GTID复制和并行复制。异步复制通过配置主库和从库实现简单的主从架构,但存在数据丢失风险;半同步复制确保日志复制到从库后再提交事务,提高了数据安全性;GTID复制简化了配置过程,增强了复制的可靠性和管理性;并行复制通过多线程技术降低主从同步延迟,保证数据一致性。此外,还讨论了如何使用工具监控主从延迟及应对策略,如强制读主库以确保即时读取最新数据。
MySQL原理简介—12.MySQL主从同步
|
9天前
|
SQL 缓存 关系型数据库
MySQL原理简介—7.redo日志的底层原理
本文介绍了MySQL中redo日志和undo日志的主要内容: 1. redo日志的意义:确保事务提交后数据不丢失,通过记录修改操作并在系统宕机后重做日志恢复数据。 2. redo日志文件构成:记录表空间号、数据页号、偏移量及修改内容。 3. redo日志写入机制:redo日志先写入Redo Log Buffer,再批量刷入磁盘文件,减少随机写以提高性能。 4. Redo Log Buffer解析:描述Redo Log Buffer的内存结构及刷盘时机,如事务提交、Buffer过半或后台线程定时刷新。 5. undo日志原理:用于事务回滚,记录插入、删除和更新前的数据状态,确保事务可完整回滚。
|
8天前
|
SQL 缓存 关系型数据库
MySQL原理简介—8.MySQL并发事务处理
这段内容深入探讨了SQL语句执行原理、事务并发问题、MySQL事务隔离级别及其实现机制、锁机制以及数据库性能优化等多个方面。
|
7天前
|
SQL 关系型数据库 MySQL
MySQL原理简介—11.优化案例介绍
本文介绍了四个SQL性能优化案例,涵盖不同场景下的问题分析与解决方案: 1. 禁止或改写SQL避免自动半连接优化。 2. 指定索引避免按聚簇索引全表扫描大表。 3. 按聚簇索引扫描小表减少回表次数。 4. 避免产生长事务长时间执行。
|
7天前
|
SQL 存储 关系型数据库
MySQL原理简介—10.SQL语句和执行计划
本文介绍了MySQL执行计划的相关概念及其优化方法。首先解释了什么是执行计划,它是SQL语句在查询时如何检索、筛选和排序数据的过程。接着详细描述了执行计划中常见的访问类型,如const、ref、range、index和all等,并分析了它们的性能特点。文中还探讨了多表关联查询的原理及优化策略,包括驱动表和被驱动表的选择。此外,文章讨论了全表扫描和索引的成本计算方法,以及MySQL如何通过成本估算选择最优执行计划。最后,介绍了explain命令的各个参数含义,帮助理解查询优化器的工作机制。通过这些内容,读者可以更好地理解和优化SQL查询性能。
|
9天前
|
存储 缓存 关系型数据库
MySQL原理简介—5.存储模型和数据读写机制
本文介绍了MySQL中InnoDB存储引擎的物理存储结构和读写机制。主要内容包括: 1. 为什么不能直接更新磁盘上的数据 2. 数据页的概念 3. 一行数据的存储 4. 数据头的内容 5. 行溢出和溢出页 6. 数据页的物理结构 7. 表空间的物理结构 8. InnoDB存储模型及读写机制总结 这些机制共同确保了InnoDB在高并发场景下的高效运行和数据一致性。
|
9天前
|
缓存 NoSQL 关系型数据库
MySQL原理简介—4.深入分析Buffer Pool
本文介绍了MySQL的Buffer Pool机制,包括其作用、配置方法及内部结构。Buffer Pool是MySQL用于缓存磁盘数据页的关键组件,能显著提升数据库读写性能。默认大小为128MB,可根据服务器配置调整(如32GB内存可设为2GB)。它通过free链表管理空闲缓存页,flush链表记录脏页,并用LRU链表区分冷热数据以优化淘汰策略。此外,还探讨了多Buffer Pool实例、chunk动态调整等优化并发性能的方法,以及如何通过`show engine innodb status`查看Buffer Pool状态。关键词:MySQL内存数据更新机制。

热门文章

最新文章