查看存储引擎和修改默认的存储引擎
-
查看 mysql 提供的所有存储引擎。
sqlshow engines;# \G是一种命令行选项,用于以垂直方式显示查询结果。show engines \G; -
查看默认的存储引擎。
sqlshow variables like '%storage_engine%';# 或者使用如下命令也行。SELECT @@default_storage_engine; -
修改默认的存储引擎
如果在创建表的语句中没有显式指定表的存储引擎的话,那就会默认使用 InnoDB 作为表的存储引擎。如果我们想改变表的默认存储引擎的话,命令如下:
sqlSET DEFAULT_STORAGE_ENGINE=MyISAM;或者修改 my.cnf 文件,然后重启 MySQL 服务器。
sql[mysqld]default-storage-engine=MyISAM
设置表的存储引擎
存储引擎是负责对表中的数据进行提取和写入工作的,我们可以给不同的表设置不同的存储引擎,也就是说不同的表可以有不同的物理存储结构,不同的提取和写入方式。
1. 创建表时指定存储引擎
我们之前创建表的语句都没有指定表的存储引擎,那就会使用默认的存储引擎 InnoDB 。如果我们想显式的指定一下表的存储引擎,那可以这么写:
CREATE TABLE 表名(建表语句;) ENGINE = 存储引擎名称;2. 修改表的存储引擎
如果表已经建好了,我们也可以使用下边这个语句来修改表的存储引擎:
ALTER TABLE 表名 ENGINE = 存储引擎名称;3. 查看表的结构以及存储引擎
SHOW CREATE TABLE 表名 \G;引擎介绍
1. InnoDB 引擎
-
MySQL 从 3.23.34a 开始就包含 InnoDB 存储引擎。大于等于 5.5 之后,默认采用 InnoDB 引擎。
-
InnoDB 是 MySQL 的 默认事务型引擎 ,它被设计用来处理大量的短期(short-lived)事务。可以确保事务的完整提交(Commit)和回滚(Rollback)。
-
除非有非常特别的原因需要使用其他的存储引擎,否则应该优先考虑InnoDB引擎。 -
数据的文件结构:
表名.frm:存储表结构(在 MySQL8.0 中,合并到表名.ibd中)表名.ibd:存储数据和索引(在 MySQL8.0 中,还会存储表结构)
-
InnoDB 是 为处理巨大数据量的最大性能设计 。
在以前的版本中,字典数据以元数据文件、非事务表等来存储。现在这些元数据文件被删除了。比如: .frm , .par , .trn , .isl , .db.opt 等都在 MySQL8.0 中不存在了。
-
对比 MyISAM 的存储引擎,
InnoDB写的处理效率差一些,并且会占用更多的磁盘空间以保存数据和索引。 -
MyISAM 只缓存索引,不缓存真实数据;InnoDB 不仅缓存索引还要缓存真实数据, 对内存要求较高 ,而且内存大小对性能有决定性的影响。
2. MyISAM 引擎
-
MyISAM 提供了大量的特性,包括全文索引、压缩、空间函数(GIS)等,但
MyISAM 不支持事务、行级锁、外键,还有一个毫无疑问的缺陷就是崩溃后无法安全恢复。 -
5.5 之前默认的存储引擎。
-
优势是访问的
速度快,对事务完整性没有要求或者以 SELECT、INSERT 为主的应用。 -
针对数据统计有额外的常数存储。故而 count(*) 的查询效率很高
-
数据文件结构:
-
表名.frm:存储表结构 -
表名.MYD:存储数据 (MYData) -
表名.MYI:存储索引 (MYIndex)
-
-
应用场景:只读应用或者以读为主的业务。
MyISAM 和 InnoDB
很多人对InnoDB和MyISAM的取舍存在疑问,到底选择哪个比较好呢?
-
首先对于 InnoDB 存储引擎,提供了良好的事务管理、崩溃修复能力和并发控制。因为 InnoDB 存储引擎
支持事务,所以对于要求事务完整性的场合需要选择 InnoDB,比如数据操作除了插入和查询以外还包含有很多更新、删除操作,像财务系统等对数据准确性要求较高的系统。缺点是其读写效率稍差,占用的数据空间相对比较大。 -
其次,对于 MyISAM 存储引擎,如果是小型应用,系统以读操作和插入操作为主,只有很少的更新、删除操作,并且对事务的要求没有那么高,则可以选择这个存储引擎。MyISAM 存储引擎的优势在于
占用空间小,处理速度快;缺点是不支持事务的完整性和并发性。 -
这两种引擎各有特点,当然你也可以在 MySQL 中,针对不同的数据表,可以选择不同的存储引擎。
一些补充
1. InnoDB 表的优势
-
InnoDB 存储引擎在实际应用中拥有诸多优势,比如操作便利、提高了数据库的性能、维护成本低等。如果由于硬件或软件的原因导致服务器崩溃,那么在重启服务器之后不需要进行额外的操作。InnoDB 崩溃恢复功能自动将之前提交的内容定型,然后撤销没有提交的进程,重启之后继续从崩溃点开始执行。
-
InnoDB 存储引擎在主内存中维护缓冲池,高频率使用的数据将在内存中直接被处理。这种缓存方式应用于多种信息,加速了处理进程。在专用服务器上,物理内存中高达 80%的部分被应用于缓冲池。如果需要将数据插入不同的表中,可以设置外键加强数据的完整性。更新或者删除数据,关联数据将会被自动更新或删除。如果试图将数据插入从表,但在主表中没有对应的数据,插入的数据将被自动移除。如果磁盘或内存中的数据出现崩溃,在使用脏数据之前,校验和机制会发出警告。当每个表的主键都设置合理时,与这些列有关的操作会被自动优化。插入、更新和删除操作通过做改变缓冲自动机制进行优化。 InnoDB 不仅支持当前读写,也会缓冲改变的数据到数据流磁盘 。
-
InnoDB 的性能优势不只存在于长时间运行查询的大型表。在同一列多次被查询时,自适应哈希索引会提高查询的速度。使用 InnoDB 可以压缩表和相关的索引,可以在不影响性能和可用性的情况下创建或删除索引。对于大型文本和 BLOB 数据,使用动态行形式,这种存储布局更高效。通过查询 INFORMATION_SCHEMA 库中的表可以监控存储引擎的内部工作。在同一个语句中,InnoDB 表可以与其他存储引擎表混用。即使有些操作系统限制文件大小为 2GB,InnoDB 仍然可以处理。 当处理大数据量时,InnoDB 兼顾 CPU,以达到最大性能 。
2. InnoDB 和 ACID 模型
ACID 模型是一系列数据库设计规则,这些规则着重强调可靠性,而可靠性对于商业数据和任务关键型应用非常重要。MySQL 包含类似 InnoDB 存储引擎的组件,与 ACID 模型紧密相连,这样出现意外时,数据不会崩溃,结果不会失真。如果依赖 ACID 模型,可以不使用一致性检查和崩溃恢复机制。如果拥有额外的软件保护,极可靠的硬件或者应用可以容忍一小部分的数据丢失和不一致,可以将 MySQL 设置调整为只依赖部分 ACID 特性,以达到更高的性能。下面讲解 InnoDB 存储引擎与 ACID 模型相同作用的四个方面。
-
原子性方面:ACID 的原子方面主要涉及 InnoDB 事务,与 MySQL 相关的特性主要包括:- 自动提交设置。
- COMMIT 语句。
- ROLLBACK 语句。
- 操作 INFORMATION_SCHEMA 库中的表数据。
-
一致性方面:ACID 模型的一致性主要涉及保护数据不崩溃的内部 InnoDB 处理过程,与 MySQL 相关的特性主要包括:- InnoDB 双写缓存。
- InnoDB 崩溃恢复。
-
隔离性方面:隔离是应用于事务的级别,与 MySQL 相关的特性主要包括:- 自动提交设置。
- SET ISOLATION LEVEL 语句。
- InnoDB 锁的低级别信息。
-
持久性方面:ACID 模型的持久性主要涉及与硬件配置相互影响的 MySQL 软件特性。由于硬件复杂多样化,持久性方面没有具体的规则可循。与 MySQL 相关的特性有:- InnoDB 双写缓存,通过 innodb_doublewrite 配置项配置。
- 配置项 innodb_flush_log_at_trx_commit。
- 配置项 sync_binlog。配置项 innodb_file_per_table。
- 存储设备的写入缓存。存储设备的备用电池缓存。
- 运行 MySQL 的操作系统。
- 持续的电力供应。
- 备份策略。
- 对分布式或托管的应用,最主要的在于硬件设备的地点以及网络情况。
3. InnoDB 架构
-
缓冲池:缓冲池是主内存中的一部分空间,用来缓存已使用的表和索引数据。缓冲池使得经常被使用的数据能够直接在内存中获得,从而提高速度。 -
更改缓存:更改缓存是一个特殊的数据结构,当受影响的索引页不在缓存中时,更改缓存会缓存辅助索引页的更改。索引页被其他读取操作时会加载到缓存池,缓存的更改内容就会被合并。不同于集群索引,辅助索引并非独一无二的。当系统大部分闲置时,清除操作会定期运行,将更新的索引页刷入磁盘。更新缓存合并期间,可能会大大降低查询的性能。在内存中,更新缓存占用一部分 InnoDB 缓冲池。在磁盘中,更新缓存是系统表空间的一部分。更新缓存的数据类型由 innodb_change_buffering 配置项管理。 -
自适应哈希索引:自适应哈希索引将负载和足够的内存结合起来,使得 InnoDB 像内存数据库一样运行,不需要降低事务上的性能或可靠性。这个特性通过 innodb_adaptive_hash_index 选项配置,或者通过–skip-innodb_adaptive_hash_index 命令行在服务启动时关闭。 -
重做日志缓存:重做日志缓存存放要放入重做日志的数据。重做日志缓存大小通过 innodb_log_buffer_size 配置项配置。重做日志缓存会定期地将日志文件刷入磁盘。大型的重做日志缓存使得大型事务能够正常运行而不需要写入磁盘。 -
系统表空间:系统表空间包括 InnoDB 数据字典、双写缓存、更新缓存和撤销日志,同时也包括表和索引数据。多表共享,系统表空间被视为共享表空间。 -
双写缓存:双写缓存位于系统表空间中,用于写入从缓存池刷新的数据页。只有在刷新并写入双写缓存后,InnoDB 才会将数据页写入合适的位置。 -
撤销日志:撤销日志是一系列与事务相关的撤销记录的集合,包含如何撤销事务最近的更改。如果其他事务要查询原始数据,可以从撤销日志记录中追溯未更改的数据。撤销日志存在于撤销日志片段中,这些片段包含于回滚片段中。 -
每个表一个文件的表空间:每个表一个文件的表空间是指每个单独的表空间创建在自身的数据文件中,而不是系统表空间中。这个功能通过 innodb_file_per_table 配置项开启。每个表空间由一个单独的.ibd 数据文件代表,该文件默认被创建在数据库目录中。 -
通用表空间:使用 CREATE TABLESPACE 语法创建共享的 InnoDB 表空间。通用表空间可以创建在 MySQL 数据目录之外能够管理多个表并支持所有行格式的表。 -
撤销表空间:撤销表空间由一个或多个包含撤销日志的文件组成。撤销表空间的数量由 innodb_undo_tablespaces 配置项配置。 -
临时表空间:用户创建的临时表空间和基于磁盘的内部临时表都创建于临时表空间。innodb_temp_data_file_path 配置项定义了相关的路径、名称、大小和属性。如果该值为空,默认会在 innodb_data_home_dir 变量指定的目录下创建一个自动扩展的数据文件。 -
重做日志:重做日志是基于磁盘的数据结构,在崩溃恢复期间使用,用来纠正数据。正常操作期间,重做日志会将请求数据进行编码,这些请求会改变 InnoDB 表数据。遇到意外崩溃后,未完成的更改会自动在初始化期间重新进行。