mysql批量造数据_再谈MySQL存储引擎，不止innodb

本文的快速概述

我一直都见过这个存储引擎，但好像没有研究和了解其他存储引擎，不知道它有什么特点。 本文将带你从以下四点一一打败它：

1️⃣ MySQL数据库服务器架构

在下面的MySQL数据库服务器架构图中，最顶层是我经常用作后端开发的客户端连接器JDBC。 当然，除了Java之外，PHP、Ruby也可以作为客户端连接器，而我们主要关注的是客户端连接器下面的MySQL服务器的架构，即MySQL

首先，第一层：连接层。它的功能是：接收客户端连接，完成连接处理，认证授权，安全解决方案，检查是否超过最大连接数……认证授权就是我们登录时的过程输入用户名和密码，并赋予用户相应的权限

然后是第二层：服务层。核心功能基本都在这一层完成：SQL接口、解析器、查询优化器、缓存，比如创建存储过程、视图、触发器等都是在服务层完成

第三层：引擎层。上图中的紫色圆柱体是不同类型的存储引擎。 第一个是我们常用的。 上图是MySQL提供给我们的存储引擎，我们也可以自己扩展存储引擎。 它的名字叫它是：可插拔存储引擎，类似于一个接口。 我们需要时插入，不需要时拔掉。 存储引擎控制我们存储和检索数据的方式。

这里还需要注意的是，索引是在存储引擎级别确定的。

最后一层：存储层。引擎层只决定我们如何访问数据，数据实际上是存储在磁盘上的。 同时，数据库日志也会存储在磁盘上。

2️⃣ MySQL数据库中的存储引擎

虽然前面介绍了这么多，但是什么是存储引擎呢？ 我们操作数据库时如何指定存储引擎也是一个问题。

存储引擎

存储引擎是存储数据、创建索引、更新/查询数据等技术的实现。 存储引擎是基于表的，也就是说一张表使用一个存储引擎。 数据库中不同表的存储引擎不一定相同。 因此，存储引擎可以称为表类型。

在前面的MySQL基础知识中，我们并没有指定存储引擎，但是当我们导出下面的建表的SQL语句时，我们会发现它的存储引擎是

这是因为.5之后，数据库表的默认存储引擎是

指定存储引擎

其实有了上面导出的建表的SQL语句，我们就不难找到指定存储引擎的方法了，那就是：

create table `table_name`(
	`字段1` 字段1类型 [COMMENT 备注],
	...,
	`字段n` 字段n类型 [COMMENT 备注]
) ENGINE=引擎类型 [COMMENT 备注]
复制代码

但是我们如何知道当前数据库版本支持哪些存储引擎呢？ 这需要执行SHOW

从这个表我们可以得到的信息：

3️⃣各存储引擎的特点及差异

这里主要介绍一下所使用的三种主要存储引擎。

⚙

其特点可以通过数据库查询三点来概括：

另外，我们来说一下存储数据的文件

说了这么多ibd文件，我们不妨找到ibd文件的位置。 我们可以在Data中找到对应的ibd文件：

该文件是二进制编码的，我们无法直接打开它。 我们可以通过命令从ibd文件中提取sdi表结构数据。

最后简单介绍一下逻辑存储结构：

其实就是一种层层包含关系：表空间包含多个段，一个段包含多个区域。 一个区域的固定大小是1M，最多可以包含64个页面，因为一页的固定大小是16K，而一页可以包含多列。 一列是我们数据库中的一条数据。 当然，除了记录数据之外，还有事务id和指针。

这只是一个简单的介绍，后面在SQL优化的时候会详细讲解。

⚔

它是MySQL早期的默认存储引擎。 我们可以将其特点与当前默认的存储引擎进行比较：

涉及到三种类型的存储文件：MYD、MYI、SDI。

最大的特点是它的表数据存储在内存中，因此很容易受到宕机、断电等影响，导致数据丢失。 因此，存储引擎一般用于临时表和缓存。 其特点与前两者类似。 存储引擎类型不同，不做比较：

至于存储它的文件类型，只有一种sdi，因为数据存储在内存中而不是磁盘中，所以不需要更多的文件类型来存储数据，只有一种sdi文件需要记录表结构。

总结

特征

存储限制

64TB

有

有

交易安全

支持

锁定机构

行锁

表锁

表锁

B+树索引

支持

支持

支持

哈希索引

支持

全文索引

支持（5.6以后）

支持

空间使用

高的

低的

不适用

内存使用情况

高的

低的

中等的

批量插入速度

低的

高的

高的

支持外键

支持

4️⃣存储引擎选择

其实学习到现在不难发现，各种存储引擎之间并不存在所谓的高低之分。 没有说哪个是最好的。 只能说应该根据应用系统的特点来选择合适的存储引擎。 您不一定会选择所有这些。 对于复杂的应用，对于应用系统，我们可以选择多种存储引擎的组合来达到最佳的效果。

：如果对事务的完整性要求比较高，要求并发条件下的数据一致性，那么选择是一个不错的选择：如果数据主要是读和插入，很少有更新和删除，为了事务的完整性，如果并发要求不高，那么这个存储引擎比较适合。 一开始我并没有想到什么不需要完整性的场景，但事实上，电商平台的浏览记录都非常符合这个特性。 大部分都是插入和查询，对事务完整性的要求不高。 其实也就少了一两个而已。 这不是一个大问题：它通常用于临时表和缓存。 它的缺点是由于内存有限，表的大小也受到限制。 同时，也无法保证数据的安全。

: