共计 5017 个字符，预计需要花费 13 分钟才能阅读完成。
MySQL 的存储引擎是 MySQL 体系架构中的重要组成部分，也是 MySQL 体系结构的核心，插件式的存储引擎更是它区别于其它数据库的重要特征。它处于 MySQL 体系架构中 Server 端底层，是底层物理结构的实现，用于将数据以各种不同的技术方式存储到文件或者内存中，不同的存储引擎具备不同的存储机制、索引技巧和锁定水平。常见的 MySQL 存储引擎有 InnoDB、MyISAM、Memory、Archive 等等，它们具备各自的特征，我们可以根据不同的具体应用来建立对应的存储引擎表。
在谈不同的存储引擎之前，我们需要先理解几个基本概念：
（1）事务
事务是一组原子性的 SQL 语句或者说是一个独立的工作单元，如果数据库引擎能够成功对数据库应用这组 SQL 语句，那么就执行，如果其中有任何一条语句因为崩溃或其它原因无法执行，那么所有的语句都不会执行。也就是说，事务内的语句，要么全部执行成功，要么全部执行失败。
举个银行应用的典型例子：
假设银行的数据库有两张表：支票表和储蓄表，现在某个客户 A 要从其支票账户转移 2000 元到其储蓄账户，那么至少需求三个步骤：
a. 检查 A 的支票账户余额高于 2000 元；
b. 从 A 的支票账户余额中减去 2000 元；
c. 在 A 的储蓄账户余额中增加 2000 元。
这三个步骤必须要打包在一个事务中，任何一个步骤失败，则必须要回滚所有的步骤，否则 A 作为银行的客户就可能要莫名损失 2000 元，就出问题了。这就是一个典型的事务，这个事务是不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚，不可能只执行其中一部分，这也是事务的原子性特征。
（2）读锁和写锁
无论何时，只要有多个 SQL 需要同一时刻修改数据，都会产生并发控制的问题。
假设一个公共邮箱，用户 A 正在读取邮箱，同时，用户 B 正在删除邮箱中的某个邮件，会产生什么结果呢？客户 A 可能读取时会报错退出，也可能会读取到不一致的邮箱数据。如果把邮箱当作数据库中的一张表，可见其存在同样的问题。
解决这类经典问题的方法就是并发控制，即在处理并发读或者写时，可以通过实现一个由两种类型的锁组成的锁系统来解决问题。这两种锁就是共享锁和排他锁，也叫读锁和写锁。
读锁是共享的，即相互不阻塞的，多个客户在同一时刻可以读取同一资源，互不干扰。写锁是排他的，即一个写锁会阻塞其它的写锁和读锁，只有这样，才能确保给定时间内，只有一个用户能执行写入，防止其它用户读取正在写入的同一资源。写锁优先级高于读锁。
（3）行锁和表锁
实际数据库系统中每时每刻都在发生锁定，锁也是有粒度的，提高共享资源并发行的方式就是让锁更有选择性，尽量只锁定需要修改的部分数据，而不是所有的资源，因此要进行精确的锁定。但是由于加锁也需要消耗资源，包括获得锁、检查锁是否解除、释放锁等，都会增加系统的开销。所谓的锁策略就是要在锁的开销和数据的安全性之间寻求平衡，这种平衡也会影响性能。
每种 MySQL 存储引擎都有自己的锁策略和锁粒度，最常用的两种重要的锁策略分别是表锁和行锁。
表锁是开销最小的策略，会锁定整张表，用户对表做写操作时，要先获得写锁，这会阻塞其它用户对该表的所有读写操作。没有写锁时，其它读取的用户才能获得读锁，读锁之间是不相互阻塞的。行锁可以最大成都支持并发处理，但也带来了最大的锁开销，它只对指定的记录加锁，其它进程还是可以对同一表中的其它记录进行操作。表级锁速度快，但冲突多，行级锁冲突少，但速度慢。
理解了上面几个概念，我们就可以很好地分辨不同存储引擎之间的区别了。
1.
InnoDB 存储引擎
MySQL 存储引擎可以分为官方存储引擎和第三方存储引擎，InnoDB 就是强大的第三方存储引擎，具备较好的性能和自动崩溃恢复特性，目前应用极为广泛，是当前 MySQL 存储引擎中的主流，它在事务型存储和非事务型存储中都很流行。
InnoDB 存储引擎支持事务、支持行锁、支持非锁定读、支持外键。
如非特别原因，应用建表时都可以首选考虑使用 InnoDB。InnoDB 也是一个非常好的值得花时间去深入学习的存储引擎，后续计划专题研究这个存储引擎，这里就暂不赘述其详细内容了。
2. MyISAM 存储引擎
MyISAM 存储引擎是 MySQL 官方提供的存储引擎，它在 InnoDB 出现并完善之前是 MySQL 存储引擎的主流，但目前逐渐被淘汰主要因为其不支持事务，这或许源于 MySQL 的开发者认为不是所有的应用都需要事务，所以便存在了这种不支持事务的存储引擎。
MyISAM 不支持事务，不支持行级锁，支持表锁，支持全文索引，最大的缺陷是崩溃后无法安全恢复。
MyISAM 因设计简单，数据以紧密格式存储，所以某些场景下性能很好，但是它的表锁又带来了性能问题，如果你发现所有的查询都长期处于“Locked”状态，表锁就是罪魁祸首了。
因此，对于只读数据，或者表比较小，可以忍受修复操作的可以依然使
用 MyISAM，对于不需要事务的应用，选择 MyISAM 存储引擎，或许可以获得更高的性能，MySQL 自带的默认的 information_schema 库中就存在使用 MyISAM 存储引擎的表。
| TRIGGERS | CREATETEMPORARY TABLE `TRIGGERS` (
`TRIGGER_CATALOG` varchar(512) NOT NULLDEFAULT ”,
`TRIGGER_SCHEMA` varchar(64) NOT NULL DEFAULT”,
`TRIGGER_NAME` varchar(64) NOT NULL DEFAULT”,
`EVENT_MANIPULATION` varchar(6) NOT NULLDEFAULT ”,
`EVENT_OBJECT_CATALOG` varchar(512) NOT NULLDEFAULT ”,
`EVENT_OBJECT_SCHEMA` varchar(64) NOT NULLDEFAULT ”,
`EVENT_OBJECT_TABLE` varchar(64) NOT NULLDEFAULT ”,
`ACTION_ORDER` bigint(4) NOT NULL DEFAULT’0′,
`ACTION_CONDITION` longtext,
`ACTION_STATEMENT` longtext NOT NULL,
`ACTION_ORIENTATION` varchar(9) NOT NULLDEFAULT ”,
`ACTION_TIMING` varchar(6) NOT NULL DEFAULT”,
`ACTION_REFERENCE_OLD_TABLE` varchar(64)DEFAULT NULL,
`ACTION_REFERENCE_NEW_TABLE` varchar(64)DEFAULT NULL,
`ACTION_REFERENCE_OLD_ROW` varchar(3) NOTNULL DEFAULT ”,
`ACTION_REFERENCE_NEW_ROW` varchar(3) NOTNULL DEFAULT ”,
`CREATED` datetime DEFAULT NULL,
`SQL_MODE` varchar(8192) NOT NULL DEFAULT ”,
`DEFINER` varchar(77) NOT NULL DEFAULT ”,
`CHARACTER_SET_CLIENT` varchar(32) NOT NULLDEFAULT ”,
`COLLATION_CONNECTION` varchar(32) NOT NULLDEFAULT ”,
`DATABASE_COLLATION` varchar(32) NOT NULLDEFAULT ”
)ENGINE=MyISAM DEFAULT CHARSET=utf8 |
3. Memory 存储引擎
Memory 存储引擎将表中数据放在内存中，因此速度非常快，但因其支持表锁，所以并发性能较差，最糟糕的是这个存储引擎在数据库重启或崩溃之后表中的数据将全部丢失，它只适用于存储临时数据的临时表，MySQL 中一般使用这个存储引擎来存放查询的中间结果集，如 MySQL 自带的默认的 information_schema 库中就存在较多使用 Memory 存储引擎的表。
|TABLES | CREATE TEMPORARY TABLE `TABLES` (
`TABLE_CATALOG` varchar(512) NOT NULL DEFAULT”,
`TABLE_SCHEMA` varchar(64) NOT NULL DEFAULT”,
`TABLE_NAME` varchar(64) NOT NULL DEFAULT ”,
`TABLE_TYPE` varchar(64) NOT NULL DEFAULT ”,
`ENGINE` varchar(64) DEFAULT NULL,
`VERSION` bigint(21) unsigned DEFAULT NULL,
`ROW_FORMAT` varchar(10) DEFAULT NULL,
`TABLE_ROWS` bigint(21) unsigned DEFAULTNULL,
`AVG_ROW_LENGTH` bigint(21) unsigned DEFAULTNULL,
`DATA_LENGTH` bigint(21) unsigned DEFAULTNULL,
`MAX_DATA_LENGTH` bigint(21) unsigned DEFAULTNULL,
`INDEX_LENGTH` bigint(21) unsigned DEFAULTNULL,
`DATA_FREE` bigint(21) unsigned DEFAULT NULL,
`AUTO_INCREMENT` bigint(21) unsigned DEFAULTNULL,
`CREATE_TIME` datetime DEFAULT NULL,
`UPDATE_TIME` datetime DEFAULT NULL,
`CHECK_TIME` datetime DEFAULT NULL,
`TABLE_COLLATION` varchar(32) DEFAULT NULL,
`CHECKSUM` bigint(21) unsigned DEFAULT NULL,
`CREATE_OPTIONS` varchar(255) DEFAULT NULL,
`TABLE_COMMENT` varchar(2048) NOT NULLDEFAULT ”
)
ENGINE=MEMORY DEFAULT CHARSET=utf8|
4. Archive 存储引擎
Archive 存储引擎置只支持 INSERT 和 SELECT 操作，支持行锁，但本身并不是事务安全的存储引擎，其最大的优点是其具有较好的压缩比，压缩比一般可达到 1:10，可以将同样的数据以更小的磁盘空间占用来存储。
Archive 存储引擎非常适合存储归档数据，如历史数据、日志信息数据等等，这类数据往往数据量非常大，并且基本只有 INSERT 和 SELECT 操作，使用这个存储引擎可以非常节约磁盘空间。
以某个库里的有 2.5 亿条记录的历史表为例：
mysql> select TABLE_ROWSfrom TABLES where TABLE_NAME=’history’;
+————+
| TABLE_ROWS |
+————+
| 251755162 |
+————+
1 row in set (0.01 sec)
原先其默认为 InnoDB 存储引擎时，该表大小为 12G。
mysql> select concat(round(sum(DATA_LENGTH/1024/1024), 2),’MB’)as
data from TABLES where TABLE_NAME=’history’;
+————+
| data |
+————+
| 12918.88MB |
+————+
1 row in set (0.00 sec)
当使用 Archive 存储引擎重建上述表，并且重新插入同样的数据后，该表的大小变为少于 2G，可见该存储引起具有很好的压缩比。
其它存储引擎使用较少，这里就不谈了。
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-02/141111.htm
