高性能MySql学习笔记第一章

1.1 MySql逻辑架构

MySQL主要可以分为Server层和存储引擎层两部分。

MySQL服务器逻辑架构图

• Server
  大多数MySQL的核心服务功能都能在这一层，包括查询解析、分析、优化、缓存以及所有的内置函数（例如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层中实现：存储过程、触发器、试图等。
• 存储层
  存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、 MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎。
  服务器通过API与存储引起进行通信。这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层的查询过程透明，存储引擎API包含几十个底层函数，用于执行如“开始以恶搞事物”或者“根据主键提取一行记录”等操作。但存储引擎不会去解析SQL（InnoDB是一个例外，他会解析外健定义，因为MySQL服务器本身没有实现该功能），不同的存储引擎之间也不会相互通信，而只是简单的响应上层服务器的请求。

1.1.1 连接管理与安全性

每一个客户端连接都会在服务器进程中拥有一个线程（MySQL 5.5或者更高的版本中提供了一个API，支持线程池（Thread-Pooling）插件，可以使用池中少量的线程来服务大量的连接），这个连接的查询只会在这个单独的线程中执行，该线程只能轮流在某个CPU核心或者CPU中运行。服务器会负责连接的创建或者销毁线程。

客户端连接到MySQL服务器时，服务器会进行认证，一旦连接成功之后，服务器会继续验证该客户是否具有执行某个特定查询的权限（例如：是否允许客户端对某个数据库的某个表的某个会某些语句的权限）。

1.1.2 优化与执行

MySQl会解析查询，并且创建内部的数据结构（解析树），然后对其惊喜各种优化，包括重写查询、决定表的读取顺序，以及选择合适的索引等，用户通过特殊的关键字提示（hint）优化器，影响它的决策过程。也可以请求优化器解释（explain）优化过程的各个因素，使用户可以知道服务器时如何进行优化决策的。

优化器并不关心表使用的是什么存储引擎，但存储引擎对于优化查询是有影响的。优化器会请求存储引擎提供容量或某个操作的开销信息，以及表数据的统计信息等。例如，某些存储引擎的某种索引，可能对一些特定的查询有优化。

对于 SELECT语句，在解析查询之前，服务器会先检查查询缓存（ Query Cache），如果能在其中找到对应的查询，服务器就不必在查询解析、优化和执行的整个过程，而是直接返回查询缓存中的结构集。

1.2 并发控制

无论何时只要有多个查询需要在同一时刻修改数据，都会产生并发控制的问题。并发控制可以在MySQL的服务层和存储引擎层来实现。

1.2.1 读写锁

在处理并发读或者并发写时，可以通过实现一个由两种类型的锁组成的锁来解决该问题，这两种类型的锁通常称为共享锁（shared lock）和排他锁（exclusive lock），也叫读锁（read lock）和写锁（write lock）。读锁是共享的，就是一个事物在对数据加锁读取的时候其他的事物也可以读取该数据但是其他的事物不能使用写锁，通俗的说就是多个客户端在同一时间读取同一个资源，互不干扰。写锁是排他的，也就是一个写锁会阻塞其他的写锁和读锁。

1.2.2 锁粒度

表锁

表锁是MySQL中最基本的锁策略，并且是开销最小的策略。表锁会锁定整张表，一个用户对该表的写操作前，需要先获取写锁，这样会阻塞其他用户对该表的读写操作，只有没有写锁的时候，其他读取的用户才能获得读锁，读锁止键是不相互阻塞的

行级锁

行级锁可以最大程度地支持并发处理（同时也带来的最大的锁开销）。行级锁只在存储引擎层实现，而MySQL的服务层没有实现

1.3 事物

事务就是一组原子性的SQL查询，或者说是一个独立的工作单元。如果数据库引擎能够成功的对数据应用该组查询的全部语句，那么就执行该组查询。如果其中有任何一条语句因为崩溃或其他原因无法执行，那么所有的语句就都不会执行。也就是说事务内的语句，要么全部执行，要么全部都不执行

事务特性：事务具有四种特性分别为，原子性（atomicity）、一致性（consistency）、隔离性（isolation）、持久性（durability），简称ACID。一个良好的事务必须具备这些标准的特征。

原子性（atomicity）一个事物必须被视为不可分割的最小单元，整个事物中的所有操作要么全部执行，要么全部都不执行，不可能只执行其中的一部分。

一致性（consistency）数据库总是从一个一致性状态到另一个一致性状态，不存在中间状态。

隔离性（isolation）一个事务所做的修改在最终提交之前，对其他事务是不可见的。

持久性（durability）一旦事务提交，则其所做的修改就会永久的保存到数据库中，此时即使系统崩溃，修改的数据也不会丢失。（实际上持久性分为很多不同的级别，有些持久性策略能够提供非常强的安全保障，而有些则未必，而且不可能有能做到100%的持久性保证的策略）

1.3.1 隔离级别

**READ UNCOMMITED（读未提交）**读未提交级别，事务中的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也称为脏读（Dirty Read）

**READ COMMITED（读已提交）**大多数数据库的默认隔离级别都是读已提交（但MySQL不是）。读已提交只能看见已经提交的事务所做的修改，换句话说，一个事务从开始直到提交之前，所做的任何修改对其他的事务都是不可见的，这个级别有时候也叫做不可重复读，因为两次执行同样的查询，可能会得到不一样的结果

**REPEATABLE READ（可重复读）**可重复读解决了脏读的问题，该级别保证了在同一个事务中多次读取同样记录的结果是一致的，但是可重复读隔离级别还无法解决幻读的问题。所谓幻读指的的当某个事务在读取某个范围内的记录时，另一个事务又在该范围内插入了新的记录，当前的事务再次读取该范围的记录时，会和之前的读取的条数不一样，这就是幻读，InnoDB和XtraDB存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）解决了幻读的问题。可重复读是MySQL的默认隔离级别。

**SERIALIZABLE（可串行化）**串行化是最高的隔离级别，他通过强制事务串行执行，避免前面说的幻读的问题，简单的说，串行化会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁竞争的问题，在实际中很少使用这个隔离级别

隔离级别	脏读可能性	不可重复读可能性	幻读可能性	加锁读
读未提交	Yes	Yes	Yes	No
读已提交	No	Yes	Yes	No
可重复读	No	No	Yes	No
可串行化	No	No	No	Yes

1.3.2 死锁

死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。当多个事务试图以不通的顺序锁定资源时，就可能产生死锁。多个事务同时锁定同一个资源时，也会产生死锁。例如，设想下面两个事务同时处理StockPrice表：

事务1

start transaction;
update StockPrice set close = 45.50 where stock_id = 4 and date = '2020-12-21';
update StockPrice set close = 20.00 where stock_id = 3 and date = '2020-12-18';
commit;

事务2

start transaction;
update StockPrice set high = 21.13 where stock_id = 3 and date = '2020-12-18';
update StockPrice set high = 45.00 where stock_id = 4 and date = '2020-12-21';
commit;

如果凑巧两个事务欧都执行了第一条update语句，更新了第一行数据，同时也就锁定了该行数据，接着每个事务都尝试去执行第二条update语句，却发现该行已经被对方锁定，然后后面的两个事务都等待对方释放锁，同时又持有对方需要的锁，则陷入死循环，除非有外部因素介入才可能解除死锁。

为了解决这种问题，数据系统实现了各种死锁检测和死锁超时机制。越复杂的系统，比如InnoDB存储引擎，越能检测到死锁的循环依赖，并立即返回一个错误，这种解决方法很有效，否则死锁会导致出现非常慢的查询。还有一种解决方式，就是当查询的时间达到等待超时的设定后放弃锁的请求，这种方式通常来说不太好。InnoDB目前处理死锁的方法是，将持有最少行级排他锁的事务进行回滚（这是相对比较简单的死锁回滚算法）。

锁的行为和顺序是和存储引擎相关的，以同样的顺序执行语句，有些存储引擎会产生死锁，有些则不会产生。死锁的产生一偶双重的原因：有些是因为真正的数据冲突，这种情况通常很难避免，但有些则完全是存储引擎的实现方式导致的。

死锁发生时，只有部分或者完全回滚其中的一个事务，才能打破死锁。对于事务型的系统，这是无法避免的，所以应用程序在设计时必须考虑如何处理死锁。大多数情况下只需要重新执行因为死锁回滚的事务即可。

1.3.3 事务日志

事务日志可以帮助提高事务的效率。使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把该修改行为记录到持久在硬盘上的事务日志中，而不用毎次都将修改的数据本身持久到磁盘。事务日志采用的是追加的方式，因此写日志的操作是磁盘上ー小块区域内的顺序IO，而不像随机IO需要在磁盘的多个地方移动磁头，所以采用事务日志的方式相对来说要快得多。事务日志持久以后，内存中被修改的数据在后台可以慢慢地刷回到磁盘。目前大多数存储引繁都是这样实现的，我们通常称之为预写式日志( Write- Ahead Logging)，修改数据需要写两次磁盘。

如果数据的修改已经记录到事务日志并持久化，但数据本身还没有写回磁盘，此时系统崩溃，存储引擎在重启时能够自动恢复这部分修改的数据。具体的恢复方式则视存储引擎而定。

1.3.4 MySQL中的事务

MySQL提供了两种事务型的存储引擎：InnoDB和NDB Cluster。还又一些第三方的存储引擎也支持事务，比较知名的如：XtraDB和PBXT

自动提交（AUTOCOMMIT）

MySQL默认采用自动提交（AUTOCOMMIT）模式。就是说如果不显示的开始一个事务，则每一个查询都被当做一个事务执行提交操作。在当前连接中可以通过设置AUTOCOMMIT变量来启用或者禁用自动提交。

show variables like 'autocommit'; -- 查看自动提交是否启用
set autocommit=1;				  -- 设置启用或者禁用自动提交

1或者ON表示启用，0或者OFF表示禁用。当AUTOCOMMIT=0时，所欲的查询都是在一个事务中，直到显式地执行COMMIT提交或者ROLLBACK回滚，该事务结束，同时又开始了另一个新的事务。修改 AUTOCOMMIT对非事务型的表，比如 MyISAM或者内存表不会有任何影响。对这类表来说，没有 COMMIT或者 ROLLBACK的概念，也可以说是相当于一直处于AUTOCOMMIT启用的模式。

另外还有一些命令,在执行之前会强制执行 COMMIT提交当前的活动事务。典型的例子在数据定义语言(DDL)中,如果是会导致大量数据改变的操作,比如 ALTER TABLE就是如此。另外还有 LOCK TABLES等其他语句也会导致同样的结果。如果有需要,请检査对应版本的官方文档来确认所有可能导致自动提交的语句列表。

MySQL可以通过执行SET TRANSACTION ISOLATION LEVEL '隔离级别'命令来设置隔离级别。新的隔离级别会在下一个事务开始的时候生效。可以在配置文件中设置整个数据库的隔离级别，也可以只改变当前会话的隔离级别：

set session transaction isolation level read committed;	-- 设置当前会话隔离级别为读已提交
set global transaction isolation level repeatable read;	-- 设置系统当前隔离级别为可重复读

select @@tx_isolation;			-- 查看当前会话的隔离级别
select @@global.tx_isolation;	-- 查看系统当前隔离级别

MySQL能够识别所有的4个ANSI隔离级别，InnoDB引擎也支持所有的隔离级别。

在事务中混合使用存储引擎

MySQL服务器层不管理事务，事务是由下层的存储引擎实现的。所以在同一个事务中，使用多种存储引擎是不可靠的。

如果在事务中混合使用了事务型和非事务型的表(例如 InnoDB和 MyISAM表)，在正常提交的情况下不会有什么问题。
但如果该事务需要回滚，非事务型的表上的变更就无法撤销，这会导致数据库处于不致的状态，这种情况很难修复，事务的最终结果将无法确定。所以，为每张表选择合适的存储引擎非常重要。

在非事务型的表上执行事务相关操作的时候，MySQL通常不会发出提醒，也不会报错。有时候只有回滚的时候才会发出一个警告：“某些非事务型的表上的变更不能被回滚”。但大多数情况下，对非事务型表的操作都不会有提示。

隐式和显式锁定

InnoDB采用的是两阶段锁定协议(two- phase locking protocol)。在事务执行过程中，随时都可以执行锁定，锁只有在执行 COMMIT或者 ROLLBACK的时候才会释放，并且所有的锁是在同一时刻被释放。前面描述的锁定都是隐式锁定，InnoDB会根据隔离级别在需要的时侯自动加锁。

另外，InnoDB也支持通过特定的语句进行显式锁定，这些语句不属于SQL规范，如下：

select ... lock in share mode;	-- 读锁/共享锁
select ... for update;			-- 悲观锁

MySQL也支持LOCK TABLES和UNLOCK TABLES语句，这是在服务器层实现的，和存储引擎无关。它们有自己的用途，但并不能代替事务处理。如果应用需要用到事务，还是应该选择事务型存储引擎。

经常可以发现，应用已经将表从MyISAM转换到 InnoDB，但还是显式地使用LOCK TABLES语句。这不但没有必要，还会严重影响性能，实际上 InnoDB的行级锁工作得更好。而且InnoDB是自动加锁的。

L0CK TABLES和事务之间相互影响的话，情况会变得非常复杂，在某些 MySQL版本中甚至会产生无法预料的结果。因此建议，除了事务中禁用了AUTOCOMMIT可以使用 LOCK TABLES之外，其他任何时候都不要显式地执行L0CK TABLES，不管使用的是什么存储引擎。

1.4 多版本并发控制与MVCC-很重要

MySQL的大多数事务型存储引擎实现的都不是简单的行级锁。基于提升并发性能的考虑，它们一般都同时实现了多版本并发控制(MVCC)。不仅是 MYSQL，包括 Oracle、PostgreSQL等其他数据库系统也都实现了MVCC，但各自的实现机制不尽相同，因MVCC没有一个统一的实现标准。

可以认为MVCC是行级锁的一个变种，但是它在很多情况下避免了加锁的操作，因此开销更低。虽然实现机制有所不同，但大都实现了非阻塞的读操作，写操作也只锁定必要的行。

MVCC的实现，是通过保存数据在某个时间点的快照来实现的。也就是说，不管事务需要执行多长时间，每个事务看到的数据都是一致的。根据事务开始的时间不同，每个事务对同一张表时刻看到的数据可能是不一样的。如果之前没有这方面的概念，这句话听起来就有点迷惑。熟悉了以后会发现,这句话其实还是很容易理解的。

前面说到了不同的存储引擎的MVCC实现是不同的，典型的有乐观（optimistic）并发控制和悲观（pessimistic）并发控制。下面我们通过InnoDB的简化版行为来说明MVCC事是如何工作的。

InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存行的过期时间(或删除时间)。当然存储的并不是实际的时间值，而是系统版本号( system version number)。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较。下面看一下在 REPEATABLE READ隔离级别下，MVCC具体
是如何操。

select

​ InnoDB会根据以下两个条件检查每行的记录：

1. InnoDB只查找版本早与当前事务版本的数据行（也就是，行的系统版本号小于或等于事务的系统版本号），这样可以确 保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。

2. 行的删除版本号要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除。

​ 只有符合上述两个条件的记录，才能返回作为查询结果。

inset

​ InnoDB为新插入的每一行保存当前系统版本号作为行版本号。

delete

​ InnoDB为删除的每一行保存当前系统版本号作为行删除标识。

update

​ InnoDB为插入一行新纪录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。

保存这两个额外系统版本号，使大多数读操作都可以不用加锁。这样设计使得读数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行。不足之处是每行记录都需要额外的存储空间，需要做更多的行检査工作，以及一些额外的维护工作。

MVCC只在REPEABLE READ（可重复读）和READ COMMITED（读已提交）两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容，因为READ UNCOMMITED（读未提交）总是读取最新的数据行，而不是符合当前事务版本的数据行。而SERIALIZABLE则会对所有读取的行都加锁。

1.5 MySQL的存储引擎

在文件系统中，MySQL将每一个数据库（也称为schema）保存为数据目录下的一个子目录。创建表时，MySQL会在数据库子目录下创建一个和表同名的*.frm文件保存表的定义。例如创建一个名为MyTable的表，MySQL会在MyTable.frm*文件中保存该表的定义。

因为MySQL使用文件系统的目录和文件来保存数据库和表的定义，大小写敏感性和具体的平台密切相关。在Windows中，大小写是不敏感的；而在类Unix中则是敏感的。不同的存储引擎保存数据和索引的方式是不同的，但表的定义则是在MySQL服务增统一处理的。

可以使用 show table status 命令（在MySQL 5.0以后的版本中，也可以查询 information_schema中对应的表）显示表的相关信息。例如，test 数据库中的 user表

show databases;						-- 查看当前的所有的数据库
use "数据库名字";					 -- 选择数据库 如 use test; 选中test数据库
select database();					-- 查看当前选中的数据库
show tables;						-- 显示当前数据库里的所有表
show table status like 'user' \G;	-- 显示表的相关信息， \G 表示竖着显示

简单介绍一下每一行的含义：

Name：表名

Engine：表的存储引擎类型。在旧版本中，该列的名字叫Type，而不是Engine。

Row_format：行的格式。

• 对于MyISAM存储引擎，可选的值为Dynamic、Fixed或者Compressed。Dynamic的行长度是可变的，一般包含可变长度的字段，如VARCHAR或BLOB。Fixed的行长度则视固定的，只包含固定长度的列，如CHAR和INTEGER。Compressed的行则只在压缩表中存在，请参考“高性能mysql第三版第19页MyISAM压缩表一节”。
• 对于InnoDB存储引擎，常见的行格式类型有Compact、Redundant、Dynamic和Compressed

RowsRows：表中的行数。对于MyISAM和其他一些存储引擎，该值是精确的，但对于InnoDB，该值是估计值。

Avg_row_length：平均每行包含的字节数。

Data_length：表数据的大小（以字节为单位）。

Max_data_length：表数据的最大容量，该值和存储引擎有关。

Index_length：索引的大小（以字节为单位）。

Data_free：对于MyISAM表，表示一节分配但是目前没有使用的空间。这部分空间包括了之前删除的行，以及后续可以被INSET利用到空间。

Auto_increment：下一个AUTO_INCREMENT的值。（自增主键，id的值）

Create_time：表的创建时间。

Update_Time：表数据的最后修改时间。

Check_Time：使用CHECK TABLE命令或者myisamchk工具最后一次检查表的时间。

Collation：表的默认字符集和字符列排列规则。

Checksum：如果启用，保存的是整个表的实时效验和。

Create_options：创建时指定的其他选项。

Commet：该列包含了一些其他的额外信息。对于 MyISAM表，保存的是表在创建时带的注释。对于 InnoDB表，则保存的是 InnoDB表空间的剩余空间信息。如果是一个视图，则该列包含“VIEW”的文本字样。

1.5.1 InnoDB存储引擎

InnoDB是MySQL的默认事务型引擎，也是最重要、使用最广泛的存储引擎。除非有非常特别的原因需要使用其他的存储引擎，否则应该优先考虑InnoDB引擎。

InnoDB概览

InnoDB的数据存储在表空间（tablespace）中，表空间是由InnoDB管理的一个黑盒子，有一系列的数据文件组成。

InnoDB采用MVCC来支持高并发，并且实现了四个标准的隔离级别。其默认级别是REPEATABLE READ（可重复读），并且通过 间隙锁（next-key locking） 策略防止幻读的出现。间隙锁使得InnoDB不仅仅锁定查询涉及的行，还会对索引中的间隙进行锁定，防止幻影行的插入。

InnoDB表是基于聚簇索引建立的，InnoDB的索引结构和MySQL的其他存储引擎有很大的不同，聚簇索引对主键查询有很高的性能。不过它的二级索引（secondary index，非主键索引）中必须包含主键列，所以如果主键列很大的话，其他的所有索引都会很大。因此，若表上的索引比较多的话，主键应当尽可能的小。InnoDB的存储格式是平台独立的，也就是可以将数据和索引文件从Intel平台复制到PowerPC或者Sun SPARC平台。

InnoDB内部做了很多的优化，包括从磁盘读取数据时采用的可预测性预读，能够自动在内存中创建hash索引以加速读操作的自适应哈希索引（adaptive hash index），以及能够加速插入缓存区（insert buffer）等。

1.5.2 MyISAM存储引擎

在MySQL 5.1 及之前的版本中，MyISAM是默认的存储引擎。MyISAM提供了大量的特性，包括全文索引、压缩、空间函数（GIS）等，但是MyISAM不支持事务和行级锁，而且有一个毫无疑问的缺点就是崩溃之后无法安全恢复。正是由于MyISAM引擎的缘故，即使MySQL支持事务已经很长时间了，在很多人的概念中MySQL还是非事务型的数据库。尽管MyISAM引擎不支持事务、不支持崩溃后的安全恢复，但是它绝不是一无是处的。对于只读的数据，或者表比较小、可以容忍修复（repair）操作，则一眼可以继续使用MyISAM（但请不要默认使用MyISAM，应该默认使用InnoDB）。

show engines;	-- 查看数据库所支持的存储引擎和默认的存储引擎
show variables like 'default_storage_engine%';	-- 查看数据库默认的存储引擎
set default_storage_engine=MyISAM;	-- 修改默认存储引擎为 MyISAM 但是当再次重启客户端时，默认存储引擎仍然是 InnoDB。

存储

MyISAM会将表存储在两个文件中；数据文件和索引文件，分别以*.MYD和.MYI*为扩展名。MyISAM表可以包含动态或者静态（长度固定）行。MySQL会根据表的定义来决定采用何种行格式。MyISAM表可以存储的行记录数，一般受限于可用的磁盘空间，或者操作系统中单个文件的最大尺寸。

在 MySQL 5.0 中，MyISAM表如果是变长行，则默认配置只能处理256TB的数据，因为指向数据记录的指针长度是6个字节。而在更早的版本中，指针长度默认是4字节，所以只能处理4GB的数据。而所有的 MySQL 版本都支持8字节的指针。要改变MyISAM表指针的长度(调高或者调低)，可以通过修改表的 MAX_ROWS 和AVG_ROW_LENGTH 选项的值来实现，两者相乘就是表可能达到的最大大小。修改这两个参数会导致重建整个表和表的所有索引，这可能需要很长的时间才能完成。

MyISAM特性

作为MySQL最早的存储引擎之一，MyISAM有一些已经开放出来很多年的特性。

加锁于并发

• MyISAM对整张表加锁，而不是针对行。读取时会对需要读到的所有表加共享锁，写人时则对表加排他锁。但是在表有读取査询的同时，也可以往表中插入新的记录(这被称为并发插入，CONCURRENT INSERT)。

修复

• 对于 MyISAM表，MySQL可以手工或者自动执行检査和修复操作，但这里说的修复和事务恢复以及崩溃恢复是 不同的概念。执行表的修复可能导致一些数据丢失而且修复操作是非常慢的。可以通过 CHECK TABLE mytable 检查表的错误，如果有错误可以通过执行 REPAIR TABLE mytable 进行修复。另外，如果 MySQL服务器已经关闭，也可以通过 myisamchk命令行工具进行检查和修复操作。

索引特性

• 对于MyISAM表，即使是BLOB和TEXT等长字段，也可以基于及其前500个字符创建索引。MyISAM也支持全文索引，这是一种基于分词创建的索引，可以支持复杂的查询。

延迟更新索引键（Delayed Key Write）

• 创建 MyISAM表的时候，如果指定了DELAY_KEY WRITE选项，在每次修改执行完成时，不会立刻将修改的索引数据写入磁盘，而是会写到内存中的键缓冲区(in- memor key buffer)，只有在清理键缓冲区或者关闭表的时候才会将对应的索引块写入到磁盘。这种方式可以极大地提升写入性能，但是在数据库或者主机崩溃时会造成索引损坏，需要执行修复操作。延迟更新索引键的特性，可以在全局设置，也可以为单个表设置。

MyISAM压缩表

如果表在创建并导入数据以后，不会再进行修改操作，那么这样的表或许适合采用MyISAM压缩表。

可以使用 nyisampack对 MYISAM表进行压缩(也叫打包pack)。压缩表是不能进行修改的(除非先将表解除压缩，修改数据，然后再次压缩)。压缩表可以极大地减少磁盘。空间占用，因此也可以减少磁盘I/O，从而提升査询性能。压缩表也支持索引，但索引也是只读的。
以现在的硬件能力，对大多数应用场景,读取压缩表数据时的解压带来的开销影响并不大，而减少I/O带来的好处则要大得多。压缩时表中的记录是独立压缩的，所以读取单行的时候不需要去解压整个表(甚至也不解压行所在的整个页面)。

MyISAM性能

MyISAM引擎设计简单，数据以紧密格式存储，所以在某些场景下的性能很好。MyISAM有一些服务器级别的性能扩展限制，比如对素引键缓冲区( key cache)的Mutex锁，MariaDB基于段(segment)的素引键缓冲区机制来避免该问题。但 MyISAM最典型的性能问题还是表锁的问题，如果你发现所有的査询都长期处于“Locked”状态，那么毫无疑问表锁就是罪魁祸首。

1.5.3 MySQL内建的其他存储引擎

MySQL还有一些特殊用途的存储引擎。但是需要明确地启用后才能使用。

Archive引擎

Archive存储引擎只支持INSERT和 SELECT操作，在 MYSQL5.1之前也不支持索引。Archive引擎会缓存所有的写并利用zlib对插入的行进行压缩，所以比 MyISAM表的磁盘I/O更少。但是每次 SELECT査询都需要执行全表扫描。所以 Archive表适合日志和数据采集类应用，这类应用做数据分析时往往需要全表扫描。或者在一些需要更快速的INSERT操作的场合下也可以使用。

Archive引擎支持行级锁和专用的缓冲区，所以可以实现高并发的插入。在一个査询开始直到返回表中存在的所有行数之前，Archive引擎会阻止其他的 SELECT执行，以实现一致性读。另外，也实现了批量插入在完成之前对读操作是不可见的。这种机制模仿了事务和MVCC的一些特性，但Archive引擎不是一个事务型的引擎，而是一个针对高速插入和压缩做了优化的简单引擎。

Blackhole引擎

Blackhole引擎没有实现任何的存储机制，它会丢弃所有插入的数据，不做任何保存。但是服务器会记录Blackhole表的日志，所以可以用于复制数据到备库，或者只是简单地记录到日志。这种特殊的存储引擎可以在一些特殊的复制架构和日志审核时发挥作用，但这种应用方式我们碰到过很多问题，因此并不推荐。

CSV引擎

CSV引擎可以将普通的文件(逗号分割值的文件)作为 MYSQL的表来处理，但这种表不支持素引。CSV引擎可以在数据库运行时拷入或者拷出文件。可以将Excel等电子表格软件中的数据存储为CSV文件，然后复制到 MYSQL数据目录下，就能在MYSQL中打开使用。同样，如果将数据写入到一个CSV引擎表，其他的外部程序也能立即从表的数据文件中读取CSV格式的数据。因此CSV引可以作为一种数据交换的机制，非常有用。

Federated引擎

Federated引擎是访问其他MySQL服务器的一个代理，它会创建一个到远程MySQL服务器的客户端连接，并将査询传输到远程服务器执行，然后提取或者发送需要的数据。最初设计该存储引擎是为了和企业级数据库如Microsoft SQL Server和 Oracle I的类似特性竟争的，可以说更多的是一种市场行为。尽管该引擎看起来提供了一种很好的跨服务器的灵活性，但也经常带来问题，因此默认是禁用的。MariaDB使用了它的一个后续改进版本，叫做 Federatedx。

Memory引擎（跟Redis有一拼）

如果需要快速地访问数据，并且这些数据不会被修改，重启以后丢失也没有关系，那么使用Memory表(以前也叫做HEAP表)是非常有用的。Memory表至少比MyISAM表要快一个数量级，因为所有的数据都保存在内存中，不需要进行磁盘I/O。Memory表的结构在重启以后还会保留，但数据会丢失。其实基于hash的，所以和Redis是有一拼的。
Memory表在很多场景可以发挥好的作用：

• 用于查找（lookup）或者映射（mapping）表，例如将邮編和州名映射的表。
• 用于缓存周期性聚合数据（periodically aggregated data）的结果。
• 用于保存数据分析中产生的中间数据。

Memory表支持Hash索引，因此査找操作非常快。虽然Memory表的速度非常快，但还是无法取代传统的基于磁盘的表。Memroy表是表级锁，因此并发写入的性能较低。它不支持BLOB或TET类型的列，并且每行的长度是固定的，所以即使指定了VARCHAR列实际存储时也会转换成CHAR，这可能导致部分内存的浪费（其中一些限制在Percona版本已经解决）。

如果MySQL在执行査询的过程中需要使用临时表来保存中间结果，内部使用的临时表就是Memory表。如果中间结果太大超出了Memory表的限制，或者含有BL0B或TEXT字段，则临时表会转换成MyISAM表。

人们经常混淆Memory表和临时表。临时表是指使用 CREATE TEMPORARY TABLE语句创建的表，它可以使用任何存储引繁，因此和Memory表不是一回事。临时表只在单个连接中可见，当连接断开时，临时表也将不复存在。

Merge引擎

Merge引擎是MyISAM引擎的一个变种。Merge表是由多个MyISAM表合并而来的虚拟表。如果将MySQL用于日志或者数据仓库类应用，该引擎可以发挥作用。但是引人分区功能后，该引擎已经被放弃

NDB集群引擎

2003年，当时的 MYSQL AB公司从素尼爱立信公司收购了NDB数据库,然后开发NDB集群存储引擎，作为SQL和NDB原生协议之间的接口。 MYSQL服务器、NDB集群存储引擎,以及分布式的、share- nothing的、容灾的、高可用的NDB数据库的组合被称为MYSQL集群( MYSQL Cluster)。本书后续会有章节专门来讨论 MYSQL集群

1.5.4 第三方存储引擎

MySQL从2007年开始提供了插件式的存储引擎API，从此涌出了一系列为不同目的而设计的存储引擎。其中有一些已经合并到 MySQL服务器，但大多数还是第三方产品或者开源项目。

1.5.5 选择合适的引擎

当不知道该怎么选择时，选InnoDB这个默认的存储引擎是安全的，尤其是搞不清具体需要什么的时候。

这么多存储引擎，我们怎么选择？大部分情况下，InnoDB都是正确的选择，所以Oracle在 MySQL 5.5 版本时终于将 InnoDB 作为默认的存储引擎了。对于如何选择存储引擎可以简单地归纳为一句话：“除非需要用到某些 InnoDB 不具备的特性，并且没有其他办法可以替代，否则都应该优先选择 InnoDB 引擎”。例如，如果要用到全文索引，建议优先考虑 InnoDB 加上Sphinx的组合，而不是使用支持全文索引的 MyISAM。当然，如果不需要用到 InnoDB 的特性，同时其他引擎的特性能够更好地满足需求，也可以考虑下其他存储引擎。举个例子，如果不在乎可扩展能力和并发能力，也不在乎崩溃后的数据丢失问题，却对 InnoDB 的空间占用过多比较敏感，这种场合下选择MyISAM就比较合适。

除非万不得已，否则建议不要混合使用多种存储引擎，否则可能带来一系列复杂的问题
以及一些潜在的bug和边界问题。存储引擎层和服务器层的交互已经比較复杂，更不用
说混合多个存储引擎了。至少，混合存储对一致性备份和服务器参数配置都带来了一些
困难。

如果应用需要不同的存储引擎，请先考虑以下几个因素。

事务
如果应用需要事务支持，那么InnoDB(或者 Xtradb)是目前最稳定并且经过验证的选择。如果不需要事务，并且主要是 SELECT 和 INSERT操作，那么 MYISAM 是不错的选择。一般日志型的应用比较符合这一特性。

备份

备份的需求也会影响存储引擎的选择。如果可以定期地关闭服务器来执行备份，那么备份的因素可以忽略。反之，如果需要在线热备份，那么选择InnoDB就是基本的要求。

崩溃恢复

数据量比较大的时候系统崩溃后如何快速的恢复是一个需要考虑的问题。相对而言，MyISAM崩溃后发生损坏的概率比InnoDB要很多，而且恢复速度也要慢。因此，即使不需要事务支持，很多人也选择InnoDB引擎，这是一个非常重要的因素。

特有的特性

最后，有些应用可能依赖一些存储引擎所独有的特性或者优化，比如很多应用依赖聚簇索引的优化。另外MySQL中也只有 MyISAM 支持地理空间搜索。如果一个存储引擎拥有一些关键的特性，同时却又缺乏一些必要的特性，那么有时候不得不做折中的考虑，或者在架构设计上做一些取舍。某些存储引擎无法直接支持的特性，有时候通过变通也可以满足需求。

上面提到的这些概念比较抽象。所以接下来具体讨论一些常见的场景。

日志型应用（插入比较多的应用）

假设你需要实时地记录一台中心电话交换机的每一通电话的日志到mysql中，或者通过 Apache 的 mod_log_sql 模块将网站的所有访问信息直接记录到表中。这类应用的插入速度有很高的要求，数据库不应该成为瓶颈。MyISAM 或者 Archive 存储引擎对这类应用比较合适，因为他们开销低，而且插入速度非常快。

如果需要对记录的日志做分析报表，则事情就会变得有趣了。生成报表的SQL很有可能会导致插人效率明显降低，该怎么办？

这种解决方法，是利用 MYSQL内置的复制方案将数据复制一份到备库，然后在备库上执行比较消耗时间和CPU的査询。这样主库只用于高效的插入工作，而备库上执行的査询也无须担心影响到日志的插入性能。当然也可以在系统负载较低的时候执行报表查询操作，但应用在不断变化，如果依赖这个策略可能以后会导致问题。

另外一种方法，在日志记录表的名字中包含年和月的信息，比如web_Logs201201或者web Logs 2012这样可以在已经没有插人操作的历史表上做频繁的査询操作，而不会干扰到最新的当前表上的插入操作。

只读或者大部分情况下只读的表

有些表的数据用于编制类目或者分列清单（如工作岗位、竟拍、不动产等），这种应用场景是典型的读多写少的业务。如果不介意 MyISAM 的崩溃恢复问题，选用 MyISAM 引擎是合适的。不过不要低估崩溃恢复问题的重要性，有些存储引擎不会保证将数据安全地写入到磁盘中，而许多用户实际上并不清楚这样有多大的风险（MyISAM 只将数据写到内存中，然后等待操作系统定期将数据刷出到磁盘上）

一个值得推荐的方式，是在性能测试环境模拟真实的环境，运行应用,然后拔下电源模拟崩溃测试。对崩溃恢复的第一手测试经验是无价之宝，可以避免真的碰到崩溃时手足无措。

当设计上述类型的应用时，建议采用 INNODB。 MYISAM引擎在一开始可能没有任何问题，但随着应用压力的上升，则可能迅速恶化。各种锁争用、崩溃后的数据丢失等问题都会随之而来。

订单处理

如果涉及订单处理，那么支持事务就是必要选项。半完成的订单是无法用来吸引用户的。另外一个重要的考虑点是存储引檠对外键的支持情况。InnoDB 是订单处理类应佳选择。

大数据量

什么样的数据量算大？我们创建或者管理的很多 InnoDB 数据库的数据量在3~5TB之或者更大，这是单台机器上的量，不是一个分片( shard)的量。这些系统运行得还不错，要做到这一点需要合理地选择硬件，做好物理设计，并为服务器的1/O瓶颈做好规划。在这样的数据量下，如果采用 MyISAM，崩溃后的恢复就是一个盟梦。如果数据量继续增长到10TB以上的级别，可能就需要建立数据仓库。Infobright是MySQL数据仓库最成功的解决方案。

1.5.6 转换表的引擎

有很多种方法可以将表的存储引擎转换成另外一种引檠。毎种方法都有其优点和缺点在接下来的章节中，我们将讲述其中的三种方法。

ALTER TABLE

将表从一个引擎修改为另一个引擎最简单的办法是使用 ALTER TABLE语句。下面的语句将 mytable 的引擎修改为 InnoDB：

alter table mytable engine=InnoDB;

上述语法可以适用任何存储引擎。但有一个问题：需要执行很长时间。MySQL会按行将数据从原表复制到一张新的表中，在复制期间可能会消耗系统所有的I/0能力，同时原表上会加上读锁。所以，在繁忙的表上执行此操作要特别小心。一个替代方案是采用接下来将讨论的导出与导入的方法，手工进行表的复制。
如果转换表的存储引擎，将会失去和原引擎相关的所有特性。例如，如果将一张 InnoDB 表转换为 MyISAM，然后再转换回 InnoDB，原 InnoDB 表上所有的外键将丢失。

导出与导入

为了更好地控制转换的过程,可以使用 mysqldump 工具将数据导出到文件，然后修改文件中 CREATE TABLE 语句的存储引擎选项，注意同时修改表名，因为同一个数据库中不能存在相同的表名，即使它们使用的是不同的存储引擎。同时要注意 mysqldump 默认会自动在 CREATE TABLE 语句前加上 DROP TABLE 语句，不注意这一点可能会导致数据丢失。在重新导入数据之前，一定要先修改新表的名字否则后果自负

-- 在mysql命令行里执行
select * from mytable into outfile '/tmp/mytable.txt';-- 把表里的数据导出到txt文件，不包含表结构

-- 在终端里执行，test为数据库的名称 mytable为表名
mysqldump -uroot -p123456 test mytable > 'C:/Users/miaoweiwei/Desktop/dump.txt';

创建与查询（推荐的方法）

第三种转换的技术综合了第一种方法的高效和第二种方法的安全。不需要导出整个表的数据先创建一个新的存储引擎的表，然后利用 INSERT-… SELECT语法来导数据:

-- 先创建一个先的表
create table innodb_table like myisam_table; 
-- 把这个表的存储引擎修改成 InnoDB 
alter table innodb_table engine=InnoDB;
-- 在把旧表的数据插入到先的表中
insert into innodb_table select * from myisam_table;

这样操作完成以后，新表是原表的一个全量复制，原表还在,如果需要可以删除原表。如果有必要，可以在执行的过程中对原表加锁，以确保新表和原表的数据一致。