mysql中表使用了不同的存储引擎也就决定了我们底层文件系统中文件的相关物理结构。
为了管理方便,人们把连接管理、语法解析、查询优化这些并不涉及真实数据存储的功能划分为 Mysql Server的功能,把真实存取数据的功能划分为存储引擎的功能,所以在Mysql server完成了查询优化后,只需按照生成的执行计划调用底层存储引擎提供的api,获取到数据后返回给客户端就好了。
Mysql中提到了存储引擎的概念,简而言之,存储引擎就是指表的类型,其实存储引擎以前叫作表处理器,后来改名为存储引擎,它的功能就是接受上层传下来的指令,然后对表中的数据进行提取或写入操作。
一、查看存储引擎
查看mysql提供什么存储引擎:
show engines;
查询结果显示,Mysql 8 支持9种存储引擎,分别为MEMORY、MRG_MYISAM、CSV、FEDERATED、PERFORMANCE_SCHEMA、MyISAM、InnoDB、BLACKHOLE 和 ARCHIVE
Engine:表示存储引擎名称
Support:表示Mysql数据库管理系统是否支持该存储引擎:YES表示支持,NO不支持
DEFAULT:表示系统默认支持的存储引擎
Comment:表示对存储引擎的评论
Transactions:表示存储引擎是否支持事务:YES支持,NO不支持
XA:表示存储引擎所支持的分布式是否符合XA规范:YES表示支持,NO表示不支持,代表着该存储引擎时否支持分布式事务。
Savepoints:表示存储引擎是否支持事务处理的保存点,YES表示支持,NO表示不支持,也就是说,该存储引擎是否支持部分事务回滚。
show engines \G;
显式如下:
*************************** 1. row ***************************Engine : InnoDBSupport: DEFAULTComment : Supports transactions, row - level locking, and foreign keysTransactions: YESXA : YESSavepoints: YES*************************** 2. row ***************************Engine : MRG_MYISAMSupport: YESComment : Collection of identical MyISAM tablesTransactions: NOXA : NOSavepoints: NO*************************** 3. row ***************************Engine : MEMORYSupport: YESComment : Hash based, stored in memory, useful for temporary tablesTransactions: NOXA : NOSavepoints: NO*************************** 4. row ***************************Engine : BLACKHOLESupport: YESComment : /dev/null storage engine (anything you write to it disappears)Transactions: NOXA : NOSavepoints: NO*************************** 5. row ***************************Engine : MyISAMSupport: YESComment : MyISAM storage engineTransactions: NOXA : NOSavepoints: NO*************************** 6. row ***************************Engine : CSVSupport: YESComment : CSV storage engineTransactions: NOXA : NOSavepoints: NO*************************** 7. row ***************************Engine : ARCHIVESupport: YESComment : Archive storage engineTransactions: NOXA : NOSavepoints: NO*************************** 8. row ***************************Engine : PERFORMANCE_SCHEMASupport: YESComment : Performance SchemaTransactions: NOXA : NOSavepoints: NO*************************** 9. row ***************************Engine : FEDERATEDSupport: NOComment : Federated MySQL storage engineTransactions: NULLXA : NULLSavepoints: NULL
二、设置系统默认的存储引擎
查看默认的存储引擎:
show variables like '%storage_engine%';
#或SELECT @@default_storage_engine ;
修改默认的存储引擎
如果在创建表的语句中没有显式指定表的存储引擎的话,那就会默认使用 InnoDB 作为表的存储引擎。 如果我们想改变表的默认存储引擎的话,可以这样写启动服务器的命令行:
SET DEFAULT_STORAGE_ENGINE=MyISAM;
或者修改 my.cnf 文件:
default-storage-engine = MyISAM# 重启服务systemctl restart mysqld.service
三. 设置表的存储引擎
存储引擎是负责对表中的数据进行提取和写入工作的,我们可以为 不同的表设置不同的存储引擎 ,也就是 说不同的表可以有不同的物理存储结构,不同的提取和写入方式。
CREATE TABLE 表名 (建表语句;) ENGINE = 存储引擎名称 ;
ALTER TABLE 表名 ENGINE = 存储引擎名称 ;
比如我们修改一下 engine_demo_table 表的存储引擎:
mysql> ALTER TABLE engine_demo_table ENGINE = InnoDB ;Query OK, 0 rows affected ( 0.05 sec)Records: 0 Duplicates: 0 Warnings : 0
这时我们再查看一下 engine_demo_table 的表结构:
mysql> SHOW CREATE TABLE engine_demo_table \G*************************** 1. row ***************************Table : engine_demo_tableCreate Table : CREATE TABLE `engine_demo_table` (`i` int ( 11 ) DEFAULT NULL) ENGINE = InnoDB DEFAULT CHARSET =utf81 row in set ( 0.01 sec)
四、引擎介绍
4.1 InnoDB 引擎:具备外键支持功能的事务存储引擎
- MySQL从3.23.34a开始就包含InnoDB存储引擎。 大于等于5.5之后,默认采用InnoDB引擎 。
- InnoDB是MySQL的 默认事务型引擎 ,它被设计用来处理大量的短期(short-lived)事务。可以确保事务的完整提交(Commit)和回滚(Rollback)。事务是最重要的区别
- 除了增加和查询外,还需要更新、删除操作,那么,应优先选择InnoDB存储引擎。
- 除非有非常特别的原因需要使用其他的存储引擎,否则应该优先考虑InnoDB引擎。
- 数据文件结构:
- 表名.frm 存储表结构(MySQL8.0时,合并在表名.ibd中)
- 表名.ibd 存储数据和索引
- InnoDB是 为处理巨大数据量的最大性能设计 。
- 在以前的版本中,字典数据以元数据文件、非事务表等来存储。现在这些元数据文件被删除了。比如: .frm , .par , .trn , .isl , .db.opt 等都在MySQL8.0中不存在了。
- 对比MyISAM的存储引擎, InnoDB写的处理效率差一些 ,并且会占用更多的磁盘空间以保存数据和索引。
- MyISAM只缓存索引,不缓存真实数据;InnoDB不仅缓存索引还要缓存真实数据, 对内存要求较高 ,而且内存大小对性能有决定性的影响。
- MyISAM提供了大量的特性,包括全文索引、压缩、空间函数(GIS)等,但MyISAM 不支持事务、行级锁、外键 ,有一个毫无疑问的缺陷就是 崩溃后无法安全恢复 。
- 5.5之前默认的存储引擎
- 优势是访问的 速度快 ,对事务完整性没有要求或者以SELECT、INSERT为主的应用
- 针对数据统计有额外的常数存储。故而 count(*) 的查询效率很高
- 数据文件结构:
- 表名.frm 存储表结构
- 表名.MYD 存储数据 (MYData)
- 表名.MYI 存储索引 (MYIndex)
- 应用场景:只读应用或者以读为主的业务
4.3 Archive 引擎:用于数据存档
- archive 是 归档的意思,仅仅支持 插入 和 查询 两种功能(行被插入后不能再修改)。
- 在Mysql5.5以后支持索引功能。
- 拥有较好的压缩机制,使用zlib压缩库,在记录请求的时候实时的进行压缩,经常被用来作为仓库的使用。
- 创建ARCHIVE表时,存储引擎会创建名称以表名开头的文件,数据文件的扩展名为 .ARZ。
- 根据英文的测试结论来看,同样的数据量下,ARCHIVE表 比 MyISAM表要小大约75%,比支持事务处理的InnOB表小大约83%。
- ARCHIVE存储引擎采用了行级锁,该ARCHIVE引擎支持 AUTO_INCREMENT 列属性。AUTO_INCREMENT列可以具有唯一索引或非唯一索引。禅师在任何其他列上创建索引会导致错误。
- Achive表适合日志和数据采集(档案)类应用;适合存储大量的独立的作为历史记录的数据,拥有很高的插入速度,但是对查询的支持比较差。
下表展示了ARCHIVE 存储引擎功能:
特征
|
支持
|
B
树索引
|
不支持
|
备份
/
时间点恢复
(在服务器中实现,而不是在存储引擎中)
|
支持
|
集群数据库支持
|
不支持
|
聚集索引
|
不支持
|
压缩数据
|
支持
|
数据缓存
|
不支持
|
加密数据(加密功能在服务器中实现)
|
支持
|
外键支持
|
不支持
|
全文检索索引
|
不支持
|
地理空间数据类型支持
|
支持
|
地理空间索引支持
|
不支持
|
哈希索引
|
不支持
|
索引缓存
|
不支持
|
锁粒度
| 行锁 |
MVCC
|
不支持
|
存储限制
| 没有任何限制 |
交易
|
不支持
|
更新数据字典的统计信息
|
不支持
|
4.4 Blackhole 引擎:丢弃写操作,读操作会返回空内容
- Blackhole引擎没有实现任何存储机制,它会丢弃所有插入的数据,不做任何保存。
- 但服务器会记录Blackhole表的日志,所以可以用于赋值数据到备库,或者简单的记录到日志。但这种应用方式会碰到很多问题,因此并不推荐
4.5 CSV 引擎:存储数据时,以逗号分隔各个数据项
- csv引擎可以将 普通的csv文件作为Mysql的表来处理,但不支持索引。
- csv引擎可以作为一种 数据交换的机制,非常有用。
- csv存储的数据直接可以在操作系统里,用文本编辑器,或者excel读取。
- 对于数据的快速导入、导出是有明显优势的。
创建csv表时,服务器会创建一个纯文本数据文件,其名称以表名开头并带有.csv扩展名,当你将数据存储到表中时,存储引擎将其以逗号分隔值格式保存到数据文件中。
使用案例如下:
mysql> CREATE TABLE test (i INT NOT NULL, c CHAR(10) NOT NULL) ENGINE = CSV;
Query OK, 0 rows affected (0.06 sec)
mysql> INSERT INTO test VALUES(1,'record one'),(2,'record two');
Query OK, 2 rows affected (0.05 sec)
Records: 2 Duplicates: 0 Warnings: 0
mysql> SELECT * FROM test;
+---+------------+
| i | c |
+---+------------+
| 1 | record one |
| 2 | record two |
+---+------------+
2 rows in set (0.00 sec)
创建CSV表还会创建相应的 元文件 ,用于 存储表的状态 和 表中存在的行数 。此文件的名称与表的名称相同,后缀为 CSM 。如图所示:
"1","record one""2","record two"
这种格式可以被 Microsoft Excel 等电子表格应用程序读取,甚至写入。使用Microsoft Excel打开如图所示
概述:
Memory采用的逻辑介质是 内存 , 响应速度很快 ,但是当 mysqld 守护进程崩溃的时候 数据会丢失 。另外,要求存储的数据是数据长度不变的格式,比如,Blob 和 Text 类型的数据不可用 (长度不固定的)。
- Memory同时 支持哈希(HASH)索引 和 B+树索引 。
- 哈希索引相等的比较快,但是对于范围的i叫慢很多
- 默认使用哈希索引,其速度要比使用B型树索引快。
- 如果希望使用B树索引,可以在创建索引时选择使用。
- Memory表至少比MyISAM表要 快一个数量级 。
- MEMORY 表的大小是受到限制 的。表的大小主要取决于两个参数,分别是 max_rows 和 max_heap_table_size 。其中,max_rows可以在创建表时指定;max_heap_table_size的大小默认为16MB,可以按需要进行扩大。
- 数据文件与索引文件分开存储。
- 每个基于MEMORY存储引擎的表实际对应一个磁盘文件,该文件的文件名与表名相同,类型为 frm类型,该文件只存储表的结构,而其数据文件都是存储在内存中的。
- 这样有利于数据的快速处理提供整个表的处理效率。
- 缺点:其数据易丢失,生命周期短。基于这个缺陷,选择MEMORY存储引擎时需要特别小心。
也就是表结构在硬盘中存储,表数据在内存中存储。
3. 存储在Memory表中的数据如果突然间 丢失的话也没有太大的关系 。
特
点
|
MyISAM
|
InnoDB
|
MEMORY
|
MERGE
|
NDB
|
存储限制
|
有
|
64TB
|
有
|
没有
|
有
|
事务安全
|
支持
| ||||
锁机制
|
表锁,即使操作一条记录也会锁住整个表,不适合高并发的操作
|
行锁,操作时只锁某一行,不对其它行有影响,适合高并发的操作
|
表锁
|
表锁
|
行锁
|
B
树索引
|
支持
|
支持
| 支持 | 支持 | 支持 |
哈希索引
|
支持
|
支持
| |||
全文索引
| 支持 | ||||
集群索引
| 支持 | ||||
数据缓存
| 支持 | 支持 | 支持 | ||
索引缓存
|
只缓存索引,不缓存真实数据
|
不仅缓存索引还要缓存真实数据,对内存要求较高,而且内存大小对性能有决定性的影响
|
支持
|
支持
|
支持
|
数据可压缩
|
支持
| ||||
空间使用
| 低 | 高 | N/A | 低 | 低 |
内存使用
| 低 | 低 | 高 | 高 | 高 |
批量插入的速度
| 高 | 低 | 高 | 高 | 高 |
支持外键
| 支持 |
五、MyISAM和InnoDB
对比
项
|
MyISAM
|
InnoDB
|
外键
|
不支持
|
支持
|
事务
|
不支持
|
支持
|
行表锁
|
表锁,即使操作一条记录也会锁住整个表,不适合高并发的操作
|
行锁,操作时只锁某一行,不对其它行有影响,适合高并发的操作
|
缓存
|
只缓存索引,不缓存真实数据
|
不仅缓存索引还要缓存真实数据,对内存要求较 高,而且内存大小对性能有决定性的影响
|
自带系 统表使用
| Y | N |
关注点
|
性能:节省资源、消耗少、简单业务
|
事务:并发写、事务、更大资源
|
默认安装
| Y | Y |
默认使用
| N | Y |
InnoDB表的优势:
InnoDB存储引擎在实际应用中拥有诸多优势,比如操作便利、提高了数据库的性能、维护成本低等。如果由于硬件或软件的原因导致服务器崩溃,那么在重启服务器之后不需要进行额外的操作。InnoDB崩溃恢复功能自动将之前提交的内容定型,然后撤销没有提交的进程,重启之后继续从崩溃点开始执行。
InnoDB存储引擎在主内存中维护缓冲池,高频率使用的数据将在内存中直接被处理。这种缓存方式应用于多种信息,加速了处理进程。
在专用服务器上,物理内存中高达80%的部分被应用于缓冲池。如果需要将数据插入不同的表中,可以设置外键加强数据的完整性。更新或者删除数据,关联数据将会被自动更新或删除。如果试图将数据插入从表,但在主表中没有对应的数据,插入的数据将被自动移除。如果磁盘或内存中的数据出现崩溃,在使用脏数据之前,校验和机制会发出警告。当每个表的主键都设置合理时,与这些列有关的操作会被自动优化。插入、更新和删除操作通过做改变缓冲自动机制进行优化。 InnoDB不仅支持当前读写,也会缓冲改变的数据到数据流磁盘 。
1. 原子方面 ACID 的原子方面主要涉及 InnoDB 事务,与 MySQL相关的特性主要包括
- 自动提交设置。
- COMMIT语句。
- ROLLBACK语句。
- 操作INFORMATION_SCHEMA库中的表数据。
- InnoDB双写缓存。
- InnoDB崩溃恢复。
- 自动提交设置。
- SET ISOLATION LEVEL语句。
- InnoDB锁的低级别信息。
- InnoDB双写缓存,通过innodb_doublewrite配置项配置。
- 配置项innodb_flush_log_at_trx_commit。
- 配置项sync_binlog。
- 配置项innodb_file_per_table。
- 存储设备的写入缓存。
- 存储设备的备用电池缓存。
- 运行MySQL的操作系统。
- 持续的电力供应。
- 备份策略。
- 对分布式或托管的应用,最主要的在于硬件设备的地点以及网络情况。
2. 更改缓存 更改缓存是一个特殊的数据结构,当受影响的索引页不在缓存中时,更改缓存会缓存辅助索引页的更改。索引页被其他读取操作时会加载到缓存池,缓存的更改内容就会被合并。不同于集群索 引,辅助索引并非独一无二的。当系统大部分闲置时,清除操作会定期运行,将更新的索引页刷入磁盘。更新缓存合并期间,可能会大大降低查询的性能。在内存中,更新缓存占用一部分InnoDB 缓冲池。在磁盘中,更新缓存是系统表空间的一部分。更新缓存的数据类型由innodb_change_buffering 配置项管理。