MySQL

举个例子。上图是本人的MySQL的版本号

系统默认是nulls_equal,也就是所有的null值都是相等的.
```c
SHOW VARIABLES LIKE 'innodb_stats_method';
SELECT VERSION();
```
```c
CREATE TABLE `test_null` (
  `field` varchar(8) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=gbk
```

SELECT COUNT(*) FROM test_null;# 认为每个null都是不同的    4
SELECT COUNT(`field`) FROM test_null; # 认为null是无效的 2
SELECT * FROM test_null WHERE `field` IS NULL;# 认为每个null都是不同的 2

1.为什么MySQL有binlog，还有redo log?
这个是因为MySQL体系结构的原因，MySQL是多存储引擎的，不管使用哪种存储引擎，都会有binlog,而不一定有redolog,简单地说，binlog是MySQL Server层的，redo log是InnoDB层的。
redolog
在MySQL InnoDB中，redo log是用来实现事务的是就行，即当事务在提交时，必须先将该事务的所有操作日志写到磁盘上的redo log file进行持久化，这也就是我们常说的Write Ahead Log策略。有了redo log，在数据库发生宕机时，即时内存中的数据还没来得及持久化到磁盘上，我们也可以通过redo log完成数据的恢复，这样就避免了数据的丢失
binlog
在MySQL中，binlog记录了数据库系统所有的更新操作，主要是用来实现数据恢复和主从复制的。一方面，主从配置的MySQL集群可以利用binlog将主库中的更新操作传递到从库中，依次来实现主从数据的一致性;另一方面，数据库还可以利用binlog来进行数据的恢复

2.事务是如何提交的？事务提交先写binlog还是redo log?如何保证这两部分的日志做到顺序一致性？
MySQL Binary Log在MySQL5.1版本后推出主要用于主备复制的搭建，我们回顾下MySQL在开启/关闭Binary Log功能时是如何工作的。
2.1 MySQL没有开启Binary log的情况下
正式环境一般是开启的。首先看一下什么是CrashSafe?CrashSafe指MySQL服务器宕机重启后，能够保证:
2.1.1 所有已经提交的事务的数据仍然存在
2.1.2 所有没有提交的事务的数据自动回滚
InnoDB通过Redo Log和Undo Log可以保证以上两点。为了保证严格的CrashSafe，必须要在每隔事务提交的时候，将Redo Log写入硬件存储。这样做会牺牲一些性能，但是可靠性最好。为了平衡两者，InnoDB提供了一个innodb_flush_log_at_trx_commit(控制的是Redo Log文件的写入)系统变量，用户可以根据应用的需求自行调整.
innodb_flush_log_at_trx_comit = 0|1|2 (默认是1)
0 - 每N秒将Redo Log Buffer的记录写入Redo Log 文件，并且将文件刷入硬件存储1次，N由innodb_flush_log_at_timeout控制。默认是1s
1 - 每个事务提交时，将记录从Redo Log Buffer写入Redo Log文件，并且将文件刷入硬件存储
2 - 每个事务提交奥时，仅将记录从Redo Log Buffer写入Redo Log文件，也就是写入到操作系统缓存，但不保证它们被同步到磁盘，操作系统可能会定期将缓存中的数据写入磁盘。这种设置在操作系统崩溃时提供了一定程度的持久性保证，但在MySQL数据库崩溃时可能会丢失数据
通过redo日志将所有已经在存储以前引擎内部提交的事务应用redolog恢复，所有已经prepare但是没有commit的transaction将会应用undo log做rollback。然后客户端连接时就能看到已经提交的数据存在数据库内，未提交被回滚的数据需要重新执行。
2.2MySQL开启Binary LOg的情况下？
MySQL引入二阶段提交(two phase commit or 2pc)，MySQL内部会自动将普通事务当作一个XA事务(内部分布式事务)来处理:
(在这里提到的两段式提交是MySQL 5.6以前的实现方式，但是此过程存在严重缺陷:此过程为了保证MySQL Server层binlog的写入顺序和InnoDB层的事务提交顺序是一致的，MySQL数据库内部使用了prepare_commit_mutext这个锁。但是在启用了这个锁之后，并不能并发写入binlog，从而导致group commit失效，这个问题在MySQL 5.6中的Binary Log Group Commit(BLGC)得到解决)
先写binglog还是先写redolog的呢？
针对这个疑问，我们可以做出两个假设.
1.假设一:先写redo log再写binlog
想象以下,如果数据库系统在写完一个事务的redolog时发生crash,而此时这个事务的binlog还没有持久化。在数据库恢复后，主库会根据redolog中区完成此事务的重做，主库中就有这个事务的数据。但是，由于此事务并没有产生binlog，即时主库恢复后，关于此事务的数据修改也不会同步到从库上，这样就产生了主从不一致的错误
2.假设而:先写binlog再写redo log
想象以下，如果数据库系统在写完一个事务的binlog时发生crash,而此时这个事务的redo log还没有持久化，或者说此事务的redolog还没记录完(至少没有记录commitlog)。在数据库恢复后，从库会根据主库中记录的binlog去回放此事务的数据修改。但是，由于此事务并没有产生完整提交的redo log，主库在恢复后会回滚事务，这样也会产生主从不一致的错误。

通过上面的假设和分析，我们可以看出，不管时先写redo log还是先写binlog，都有可能会产生主从不一致的错误，那么MySQL又是怎么做到binlog和redolog的一致性的呢？

在MySQL内部，在事务提交时利用两阶段提交(内部XA的两阶段提交)很好地解决了上面提到的binlog和redo log的一致性:
1.第一阶段:InnoDB Prepare阶段。此时SQL已经成功执行，并生成事务ID(xid)信息及redo和undo的内存日志。此阶段InnoDB会写事务的redo log，但要注意的时，此时redo log只是记录了事务的所有操作日志，并没有记录提交(commit)日志，因此事务此时的状态为Prepare。此阶段对binlog不会有任何操作
2.第二阶段:commit节点，这个阶段又分成两个步骤。第一步写binlog(先调用write()将binlog日志数据写入文件系统缓存，再调用fsync()将binlog文件系统缓存日志数据永久写入磁盘)；第二步完成事务的提交(commit)，此时在redo log中记录此事务的提交日志(增加commit标签)。还要注意的是，在这个过程中是以第二阶段中binlog的写入与否作为事务是否成功提交的标识，第一步写binlog完成，第二步redo log的commit未提交未完成，也算完成。

可以看出，此过程中是先写redolog再写binlog的。但需要注意的是，在第一阶段并没有记录完整的redolog(不包含事务的commit标签)，而是在第二阶段记录完binlog后再写入redolog的commit标签。
当innodb的redolog记录，但是状态为Prepare时，尚未commit时，用户是查询不到该数据的

此时的崩溃恢复过程如下:
1.如果数据库在记录此事务的binlog之前和过程中发生crash那么没有此条redolog记录，并且后续的binlog也不会记录。数据库在恢复后认为此事务并没有成功提交，则会回滚此事务的操作。与此同时，因为在binlog中
也没有此事务的记录，所以从库也不会有此事务的数据修改。
2.如果数据库在记录此事务的binlog之后发生crash,此时redolog新增一条，binlog新增一条，但是redolog的commit标识为false.此时，即使是redo log中还没有记录此事务的commit标签，数据库在恢复后也会认为此事务提交成功.

因为在上述两阶段中，binlog写入成功就认为事务成功提交了,原理如下:
数据库恢复后它会先扫描最后一个redolog文件，并提取其中的事务ID(xid)，InnoDB会将那些状态为Prepare的事务(redo log没有记录commit标签)的xid和binlog中提取的xid做比较，如果在binlog中存在，则重新提交该事务，
否则回滚该事务。这也就是说，binlog中记录的事务，在恢复时都会被认为是已提交事务，会在redolog中重新写入commit标志，并完成此事务的重做(主库中有此事务的数据修改)，在当前机器的innodb实例上补做事务的提交标识。
与此同时，因为在binlog中有了此事务的记录，所有从库也会此事务的数据修改。简单来说，即使redo log中还没有记录此事务的commit标签，只要记录了binlog，系统重启后，就会去扫描binglog，重新不上redolog的commit

知识点总结:
1.自动为每个事务分配一个唯一的ID(XID)。这个ID很重要，是两阶段提交的核心
2.COMMIT会被自动的分成Prepare和Commit两个阶段
3.Binlog会被当作事务协调者(Transaction Coordinator) Binlog Event会被当作协调者日志
     
binlog在2PC中充当了事务的协调者(Transaction Coordinator)由binlog来通知InnoDB引擎来执行prepare，commit或者rollback的步骤。事务提交的整个过程如图所示:
1.engine是存储引擎实例，这里指innodb，第一个箭头处标识准备阶段，第二个箭头表示二次提交阶段
2.server是server层

如上图绿色显示，只要步骤执行到写binlog时，就算作提交了，当然，最后redolog的commit算是锦上添花，即使局部失败，也不影响整体的成功。上面的图片可以看到，事务的提交主要分为两个主要步骤:
1.InnoDB Prepare准备阶段(Storage Engine (InnoDB) Transaction Prepare Phase)
此时SQL已经成功执行，并生成xid信息及redo和undo的内存日志。然后调用prepare方法完成第一阶段，prepare方法实际上什么也没做，将事务状态设为TRX_PREPARED，并将redo log刷磁盘
2.commit提交阶段(Storage Engine(InnoDB) Commit Phase)
记录协调者日志，即binlog。如果事务设计的所有存储引擎的prepare都执行成功，则调用TC_LOG_BINLOG::log_xid方法将SQL语句写到binlog(write()将binnary log内存日志数据写入文件系统才能，fsync()将binnary log文件系统缓存日志数据永久写入磁盘)。此时，事务已经算作要提交了告诉引擎做commit.最后调用引擎的commit完成事务的提交。会清楚undo信息，刷redo日志(写入redo log 的commit标签)，将事务设为TRX_NOT_STARTED状态。
     
PS:记录binlog是在InnoDB引擎Prepare(即Redo Log写入磁盘)之后，这点至关重要。通过上述MySQL内部XA的两阶段提交就可以解决binlog和redolog的一致性问题。数据库在上述任何阶段crash,主从库都不会产生不一致的错误。
简单来说，当系统挂掉，redo log里面可能包含无效数据(待回滚数据)，当系统再恢复后，首先会处理binlog,根据binlog会回滚redolog(处理完后，redolog的数据都是有效数据),最后才会读取redolog恢复bufferpool

连接管理与安全性。
每个客户端连接都会在服务器进程中拥有一个线程，这个连接的查询只会在这个单独的线程中执行，该线程只能轮流在某个CPU核心或者CPU中运行，服务器会负责缓存线程，因此不需要为每一个新键的连接创建或者销毁线程(MySQL5.5版本后提供了一个API，支持线程池(Thread-Pooling)插件，可以使用池中少量的线程来服务大量的连接)。
当客户端(应用)连接到MySQL服务器时，服务器需要对其进行认证。认证基于用户名、原始主机信息和密码。如果使用了安全套接字(SSL)的方式连接，还可以使用X.509证书认证。一旦客户端连接成功，服务器会继续验证该客户端是否具有执行某个特定查询的权限(例如，是否允许客户端对world数据库的Country表执行SELECT语句)

优化与执行。
MySQL会解析查询，并创建内部数据结构(解析树)，然后对其进行各种优化，包括重写查询、决定表的读取顺序，以及选择合适的索引等。用户可以通过特殊的关键字提示(hint)优化器，影响它的决策过程。也可以请求优化器解释(explain)优化过程的各个因素，使用户可以知道服务器是如何进行优化决策的，并提供一个参考基准，便于用户重构查询和schema、修改相关配置，使应用尽可能高效运行。
优化器并不关心表使用的是什么存储引擎，但存储引擎对于优化查询是有影响的。优化器会请求存储引擎提供容量或某个具体操作的开销信息，以及表数据的统计信息等。例如，某些存储引擎的某种索引，可能对一些特定的查询有优化。
对于SELECT语句，在解析查询之前，服务器会先检查查询缓存(Query Cache)，如果能够在其中找到对应的查询，服务器就不必再执行查询解析、优化和执行的整个过程，而是直接返回查询缓存中的结果集

读写锁。
从邮箱中读取数据没有这样的麻烦，即使同一个hi上课多个用户并发读取也不会有什么问题，因为读取不会修改数据，所以不会出错。但如果某个客户正在读取邮箱，同时另外一个用户视图删除编号为25的邮件，会产生什么结果？结论是不确定，读的客户可能会报错退出，也可能读取到不一致的邮箱数据。所以，为安全起见，即使是读取邮箱也需要特别注意。
如果把上述的邮箱当称数据库的一张表，把邮件当成表中的一行记录，就很容易看出，同样的问题依然存在。从很多方面来说，邮箱就是一张简单的数据库表。修改数据库中的记录，和删除或者修改邮箱中的邮件信息，十分类似。
解决这类经典问题的方法就是并发控制，其实非常简单。在处理并发读或者写时，可以通过实现一个由两种类型的锁组成的锁系统来解决问题。这两种类型的锁通常被称为共享锁(shared lock)和排他锁(exclusive lock)，也叫读锁(read lock)和写锁(write lock)，

这里先不讨论锁的具体实现，描述一下锁的概念如下:读锁是共享的，或者说是相互不阻塞的。多个客户端在同一时刻可以同时读取同一个资源，而互不干扰。写锁则是排他的，也就是说一个写锁会阻塞其他的写锁和读锁，这是出于安全策略的考虑，只有这样，才能确保在给定的时间里，只有一个用户能执行写入，并防止其他用户读取正在写入的同一资源。
在实际的数据库系统中，每时每刻都在发生锁定，当某个用户在修改某一部分数据时，MySQL会通过锁定防止其他用户读取同一数据。大多数时候，MySQL锁的内部管理是透明的

锁粒度。
一种提高共享资源并发性的方式就是让锁定对象更有选择性。尽量只锁定需要修改的部分数据，而不是所有的资源。更理想的方式是，只对会修改的数据片进行精确的锁定。任何时候，在给定的资源山，锁定的数据量越少，则系统的并发程度越高，只要相互间不发生冲突即可。
问题是加锁也需要消耗资源，锁的各种操作，包括获得锁、检查锁是否已经解除、释放锁等，都会增加系统的开销。如果系统花费大量的时间来管理锁，而不是存取数据，那么系统的性能可能会因此受到影响。
所谓的锁策略，就是在锁的开销和数据的安全性之间寻求平衡，这种平衡当然也会影响到性能。大多数商业数据库系统没有提供更多的选择，一般是在表上施加行级锁(row-level lock)，并以各种复杂的方式来实现，以便在锁比较多的秦广下尽可能地提供更好的性能。
而MySQL则提供了多种选择。每种MySQL存储引擎都可以实现自己的锁策略和锁粒度。在存储引擎的设计中，锁管理是个非常重要的决定。将锁粒度固定在某个级别，可以为某些特定的应用场景提供更好的性能，但同时却会失去对另外一些应用场景的良好支持。好在MySQL支持多个存储引擎的架构，所以不需要单一的通用解决方案

隔离级别。
隔离性其实比想象的要复杂。在SQL标准中定义了四种隔离几倍，每一种隔离级别都规定了一个事务中所做的修改，哪些在事务内和事务间是可见的，哪些是不可见的。较低级别的隔离通常可以执行更高的并发，系统的开销也更低。
每种存储引擎实现的隔离级别不尽相同。下面简单地介绍一下四种隔离级别。
1.READ UNCOMMITED(未提交读)
在READ UNCOMMITTED级别，事务中地修改，即使没有提交，对其他事务也都是可见地。事务可以读取未提交的数据，这也被称为脏读(Dirty Read).这个级别会导致很多问题，从性能上来说，READ UNCOMMITTED不会比其他的级别好太多，但却缺乏其他级别的很多好处，除非真的非常有必要，在实际应用中一般很少使用
2.READ COMMITTED(提交读)
大多数数据库系统的默认隔离级别都是READ COMMITTED(但MySQL 不是)。READ COMMITTED满足前面提到的隔离性的简单定义:一个事务开始时，只能"看见"已经提交的事务所做的修改。换句话说，一个事务从开始知道提交之前，所做的任何修改对其他事务都是不可见的。这个级别有时候也叫做不可重复读(nonrepeatable read)，因为两次执行同样的查询，可能会得到不一样的结果。
3.REPETABLE READ(可重复读)
REPETABLE READ解决了脏读的问题，该级别保证了同一个事务中多次读取同样的结果是一致的。但是理论上，可重复读隔离级别还是无法解决另一个幻读(Phantom Read)的问题。所谓幻读，指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行(Phantom Row)。InnoDB和XtraDB存储引擎通过多版本并发控制(MVCC，Multiversion Concurrency Control)解决了幻读的问题。可重复读是MySQL的默认事务隔离级别
4.SERIALIZABLE(可串行化)
SERIALIZABLE是最高的隔离几倍。她通过强制事务串行执行，避免了前面说的幻读问题。简单来说，SERIALIZABLE会在读取的每一行数据上都加上所，所以可能导致大量的超时和锁争用的问题。实际应用中也很少用到这个隔离级别，只有在非常需要确保数据的一致性而且可以接受没有并发的情况下，才考虑采用该级别

死锁。
死锁是指两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。当多个事务试图以不同的顺序锁定资源时，就可能会产生死锁。多个事务同时锁定一个资源时，也会产生死锁。例如，设想下面两个事务同时处理StockPrice表:
事务1：
```sql
START TRANSACTION;
UPDATE StockPrice SET close =45.50 WHERE stock_id = 4 and date = '2002-05-01';
UPDATE StockPrice SET close = 19.80 WHERE stock_id = 3 and date = '2002-05-02';
COMMIT; 
```
事务2:
```sql
START TRANSACTION;
UPDATE StockPrice SET high = 20.12 WHERE stock_id = 3 and date = '2002-05-02';
UPDATE StockPrice SET high = 47.20 WHERE stock_id = 4 and date = '2002-05-01';
COMMIT;
```
如果凑巧，两个事务都执行了第一条UPDATE语句，更新了一行数据，同时也锁定了该行数据，接着每个事务都尝试去执行第二条UPDATE语句，却发现该行已经被对方锁定，然后两个事务都等待对方释放锁，同时又持有对方需要的锁，则现如死循环。除非有外部因素介入才可能解除死锁。
为了解决这种问题，数据库系统实现了各种死锁检测和死锁超时机制。越复杂的系统，比如InnoDB存储引擎，越能检测到死锁的循环一来，并立即返回一个错误。这种解决方式很有效，否则死锁会导致出现非常慢的查询。还有一种解决方式，就是当查询的时间达到锁等待超时的设定后放弃锁请求，这种方式通常来说不太好。InnoDB目前处理死锁的方法时，将持有最少行级排他锁的事务进行回滚(这是相对比较简单的死锁回滚算法)。
锁的行为和顺序是和存储引擎相关的。以同样的顺序执行语句，有些存储引擎会产生死锁，有些则不会。死锁的产生有双重原因:有些是因为真正的数据冲突，这种情况通常很难避免，但有些完全是由于存储引擎的实现方式导致的。死锁放生以后，只有部分或者完全回滚其中一个事务，才能打破死锁。对于事务型的系统，这是无法避免的，所以应用程序在设计时必须考虑如何处理死锁。大多数情况下只需要重新执行因死锁回滚的事务即可。

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

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

MySQL中的事务。
MySQL提供了两种事务型的存储引擎:InnoDB和NDB Cluster。另外还有一些第三方存储引擎也支持事务，比较知名的包括XtraDB和PBXT.
1.自动提交(AUTOCOMMIT):
MySQL默认采用自动提交(AUTOCOMMIT)模式。也就是说，如果不是显式地开始一个事务，则每个查询都被当作一个事务执行提交操作。在当前连接中，可以通过设置AUTOCOMMIT变量来启用或者禁用自动提交模式:
```c
mysql > SHOW VARIABLES LIKE 'AUTOCOMMIT';
Variable_name:autocommit
Value: ON
mysql> 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命令来设置隔离级别。新的隔离级别会在下一次事务开始的时候生效。可以在配置文件中设置整个数据库的隔离界别，也可以只改变当前会话的隔离级别:
```sql
mysql>SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
```
MySQL能够识别所有的4个ANSI隔离级别，InnoDB尹千影也支持所有的隔离界别。
2.在事务中混合使用存储引擎:
MySQL服务器层不管理事务，事务是由下层的存储引擎实现的。所以在同一个事务中，使用多种存储引擎是不可靠的。
如果在事务中混合使用了事务型和非事务型的表(例如InnoDB和MyISAM表)，在正常提交的情况下不会有什么问题，但如果该事务需要回滚，非事务型表上的变更就无法撤销，这会导致数据库处于不一致的状态，这种情况很难修复，事务的最终结果将无法确定。所以为每张表选择合适的存储引擎非常重要。
在非事务型的表上执行事务相关操作的时候，MySQL通常不会发出提醒，也不会报错。有时候只有回滚的时候才会发出一个警告:"某些非事务型的表上的变更不能被回滚"。但大多数情况下，对非事务型表的操作都不会有提示。
3.隐式和显式锁定:
InnoDB采用的是两阶段锁定协议(two-phase locking protocol)。在事务执行过程中，随时都可以执行锁定，锁只有执行COMMIT或者ROLLBACK的时候才会释放，并且所有的锁是在同一时刻被释放。前面描述的锁定都是隐式锁定，InnoDB会根据隔离级别在需要的时候自动加锁。另外，InnoDB也支持通过特定的语句进行显式锁定，这些语句不属于SQL规范(这些锁定提示经常被滥用，实际上应当尽量避免使用)
3.1 SELECT ... LOCK IN SHARE MODE
3.2 SELECT ... FOR UPDATE
MySQL也支持LOCK TABLES和UNLOCK TABLES语句，这是在服务器层实现的，和存储引擎无关。它们有自己的用途，但并不能替代事务处理。如果应用需要用到事务，还是应该选择事务型存储引擎。经常可以发现，应用已经将表从MyISAM转换到InnoDB，但还是显式地使用LOCK TABLES语句。这不但没有必要，还会严重影响性能，实际上InnoDB的行级锁工作得更好。
LOCK TABLES和事务之间相互影响得化，情况会变得非常复杂，在某些MySQL版本中甚至会产生无法预料的结果。因此，建议除了事务中禁用AUTOCOMMIT，可以使用LOCK TABLES之外，其他任何时候都不要显式地执行LOCK TABLES，不管使用的是什么存储引擎。

InnoDB三大特性:
1.AHI 自适应哈希
2.双写机制
3.Buffer Pool

字段含义:
Name:表名
Engine:表的存储引擎类型。在旧版本中，该列的名字叫Type，而不是Engine.
Row_format:行的格式。可选的值为Dynamic、Fixed或者Compressed.Dynamic的行长度是可变，一般包含可变长度的字段，如VARCHAR或BLOB.Fixed的行长度则是固定的，只包含固定长度的列，如CHAR和INTERGER.Compressed的行则只在压缩表中存在。
Rows:表中的行数。对于MyISAM和其他一些存储引擎，该值是精确的，但对于InnoDB该值是估计值。
Avg_row_length:平均每行包含的字节数
Data_length:表数据的大小(以字节为单位)
Max_data_length:表数据的最大容量，该值和存储引擎有关
Index_length:索引的大小(以字节为单位)
Data_free:对于MyISAM表，表示已分配但目前没有使用的空间。这部分空间包括了之前删除的行，以及后续可以被INSERT利用到的空间
Auto_increment:下一个AUTO_INCREMENT的值
Create_time:表的创建时间
Update_time:表数据的最后修改时间
Check_time:使用CHECK TABLE命令或者myisamchk工具最后一次检查表的时间
Collation:表的默认字符集和字符列排序规则
Checksum:如果启用，保存的是整个表 的实时校验和
Create_options:创建表时指定的其他选项
Comment:该列包含了一些其他的额外信息。对于MyISAM表，保存的时表在创建时带的注释。对于InnoDB表，则保存的时InnoDB表空间的剩余空间信息。如果是一个视图，则该列包含"VIEW"的文本字样

InnoDB存储引擎.
InnoDB是MySQL的默认事务型引擎，也是最重要、使用最广泛的存储引擎。它被设计用来处理大量的短期(short-lived)事务，短期事务大部分情况是正常提交的，很少会被回滚。InnoDB的性能和自动崩溃回复特性，使得它在非事务型存储的需求中也很流行。除非有特别的原因需要使用其他的存储引擎，否则应该优先考虑InnoDB引擎，如果要学习存储引擎，InnoDB也是一个非常好的值得花最多的时间去深入学习的对象，收益肯定比将时间平均花在每个存储引擎的学习上要高得多。
InnoDB概览:InnoDB的数据存储在表空间(tablespace)中，表空间是InnoDB管理的一个黑盒子，由一系列的数据文件组成。在MySQL4.1以后的版本中，InnoDB可以将每个表的数据和索引存放在单独的文件中。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)等。

InnoDB的行为是非常复杂的，不容易理解，如果使用了InnoDBi年轻，强烈建议阅读官方手册中的"InnoDB事务模型和锁"一节。如果应用程序基于InnoDB构建，则实现了解一下InnoDB的MVCC架构带来的一些微妙和细节之处是非常有必要的。存储引擎要为所有用户甚至包括修改数据的用户维持一致性的视图，是非常复杂的工作。

作为事务型的存储引擎，InnoDB通过一些机制和工具支持真正的热备份，Oracle提供的MySQL Enterprise Backup、Percona提供的开源的XtraBackup都可以做到这一点。MySQL的其他存储引擎不支持热备份，要获取一致性视图需要停止对所有表的写入，而在读写混合场景中，停止写入可能也意味着停止读取

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

MySQL内键的其他存储引擎。
MySQL还有一些有特殊用途的存储引擎。在新版本中，有些可能因为一些原因已经不再支持；另外还有些会继续支持，但是需要明确地启用后才能使用。
1.Archive引擎
Archive存储引擎只支持INSERT和SELECT操作，在MySQL5.1之前也不支持索引。Archive引擎会缓存所有的写并利用zlib对插入的行进行压缩，所以比MySQL表的磁盘I/O更少。但是每次SELECT查询都需要执行全表扫描。所以Archive表适合日志和数据采集类应用，这类应用做数据分析时往往需要全表扫描。或者在一些需要更快速的INSERT操作的场合下也可以使用.
Archive引擎支持行级锁和专用的缓冲区，所以可以实现高并发的插入。在一个查询开始直到返回表中存在的所有行数之前，Archive引擎会阻止其他的SELECT执行，以实现一致性读。另外，也实现了批量插入在完成之后对读操作是不可见的。这种机制模仿了事务和MVCC的一些特性，但Archive引擎不是一个事务型的引擎，而是一个针对告诉插入和压缩做了优化的简单引擎
2.Blackhole引擎。
Blackhole没有实现任何的存储机制,它会丢弃所有插入的数据，不做任何保存。但是服务器会记录Blackhole表的日志，所以可以用于复制数据到悲苦，或者只是简单地记录到日志。这种特殊的存储引擎可以在一些特殊的复制架构和日志审核时发徽作用。但这种应用方式会碰到很多问题，因此并不推荐
3.CSV引擎.
CSV引擎可以将普通的CSV文件(逗号分割值得文件)作为MySQL的表来处理，但这种表不支持索引。CSV引擎可以在数据库运行时拷入或者拷出文件。可以将Excel等电子表格软件中的数据存储为CSV文件，然后复制到MySQL数据目录下，就能在MySQL中打开使用。同样的，如果将数据写入到一个CSV引擎表，其他的外部程序也能立即从表的数据文件中读取CSV格式的数据，因此CSV引擎可以作为一种数据交换的机制，非常有用
4.Federated引擎。
Federated引擎是访问其他MySQL服务器的一个代理，它会创建一个到远程MySQL服务器的客户端连接，并将查询传输到远程服务器执行，然后提取或者发送需要的数据。最初设计该存储引擎是为了和企业级数据库如Microsoft SQL Server和Oracle的类似特性竞争的，可以说更多的是一种市场行为。尽管该引擎看起来提供了一种很好的跨服务器的灵活性，但也经常带来问题，因此默认是禁止的。MariaDB使用了它的一个后续改进版本，叫作FederatedX.
5.Memory引擎。
如果需要快速地访问数据，并且这些数据不会被修改，重启以后丢失也没关系，那么使用Memory表(以前也叫做HEAP表)是非常有用的。Memory表至少比MyISAM表要快一个数量级，因为所有的数据都存在内存中，不需要进行磁盘I/O，Memory表的结构在重启以后还会保留，但数据会丢失
Memory表在很多场景可以发挥好的作用:
5.1 用于查找(lookup)或者映射(mapping)表，例如将邮编和州名映射的表
5.2 用于缓存周期性聚合数据(periodically aggregated data)的结果
5.3 用于保存数据分析中产生的中间数据
Memory表支持Hash索引，因此查询操作非常快。虽然Memory表的速度非常快，但还是无法取代传统的基于磁盘的表。Memory表是表级锁，因此并发写入的性能较低。它不支持BLOCK或TEXT类型的列，并且每行的长度是固定的，所以即使指定了VARCHAR列，实际存储时也会转换成CHAR;这可能导致部分内存的浪费(其中一些限制在Percona版本已经解决)
如果MySQL在执行查询的过程中需要使用临时表来保存中间结果，内部使用的临时表就是Memory表。如果中间结果太大超出了Memory表的限制，或者含有BLOB或TEXT字段，则临时表会转换成MyISAM表。
人们经常混淆Memory表和临时表，临时表是指使用CREATE TEMPORARY TABLE语句创建的表，它可以使用任何存储引擎，因此和Memory 表不是一回事。临时表只在单个连接中可见，当连接断开时，临时表也将不复存在。
6.Merge引擎。
Merge引擎是MyISAM引擎的一个变种。Merge表是由多个MyISAM表合并而来的虚拟表。如果将MySQL用于日志或者数据仓库类应用，该引擎可以发挥作用，但是引入分区功能后，该引擎已经被放弃
7.NDB集群引擎
2003年，当时的MySQL AB公司从索尼爱立信公司收购了NDB数据库，然后开发了NDB集群存储引擎，作为SQL和NDB原生协议之间的解耦。MySQL服务器、NDB集群存储引擎，以及分布式、share-noting的、容灾的、高可用的NDB数据库的组合，被称为MySQL集群(MySQL Cluster)

MySQL查看存储引擎的命令
```sql
mysql> SHOW ENGINES;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
| FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
| Sequence           | YES     | Sequence Storage Engine Helper                                 | NO           | NO   | NO         |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
10 rows in set (0.11 sec)
```

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

选择合适的引擎。
这么多存储引擎，我们怎么选择?大部分情况下，InnoDB都是正确的选择，所以Oracle在MySQL5.5版本时终于将InnoDB作为默认的存储引擎了。对于如何选择存储引擎，可以简单概括为一句话"除非需要用到某些InnoDB不具备的特性，并且没有其他办法可以替代，否则都应该优先选择InnoDB引擎"。例如，如果要用到全文索引，建议优先考虑InnoDB加上Sphinx的组合，而不是使用支持全文索引的MyISAM。当然如果不需要用到InnoDB的特性，同时其他引擎的特性能够更好地满足需求，也可以考虑一下其他存储引擎。举个例子，如果不在乎可扩展能力和并发能力，也不在乎崩溃后的数据丢失问题，却对InnoDB的空间占用过多比较敏感，这种场合下选择MyISAM就比较合适。
除非万不得已，否则建议不要混合使用多种存储引擎，否则可能带来的一系列复杂的问题已经一些潜在的buf和边界问题。存储引擎层和服务器层的交互已经比较复杂，更不用说混合多个存储引擎了。至少，混合存储对一致性备份和服务器参数配置都带来了一些困难。
如果应用需要不同的存储疫情，请先考虑一下几个因素。
1.事务
如果应用需要事务支持，那么InnoDB(或者XtraDB)是目前最稳定并且经过验证的选择。如果不需要事务，并且主要是SELECT和INSERT操作，那么MyISAM是不同的选择。一般日志行的应用比较符合这一特性。
2.备份
备份的需求也会影响存储引擎的选择。如果可以定期地关闭服务器来执行备份，那么备份的因素可以忽略。反之，如果需要在线热备份，那么选择InnoDB就是基本的要求
3.崩溃恢复。
数据量比较大的时候，系统崩溃后如何快速地恢复是一个需要考虑地问题。相对而言，MyISAM崩溃后发生损坏地概率比InnoDB要高很多，而且恢复速度也要慢。因此，即使不需要事务支持，很多人也选择InnoDB引擎，这是一个非常重要的因素。
4.特有的特性.
最后，有些应用可能一来一些存储引擎所独有的特性或者优化，比如很多应用一来聚簇索引的优化。另外，MySQL中也只有MyISAM支持地理空间搜索。如果一个存储引擎拥有一些关键的特性，同时却又缺乏一些必要的特性，那么有时候不得不做折中的考虑，或者在架构设计上做一些取舍。某些存储引擎无法直接支持的特性，有时候通过变通也可以满足需求。
如果不了解具体的应用，上面提到的这些概念都是比较抽象的。所以接下来会讨论一些常见的应用场景，在这些场景中会涉及很多的表，以及这些表如何选用合适的存储引擎。

转换表的引擎。
1.ALTER TABLE
将表从一个引擎修改为另一个引擎最简单的办法是使用ALTER TABLE语句。下面的语句将mytable的引擎修改为InnoDB:
```sql
mysql>ALTER TABLE mytable ENGINE = InnoDB;
```
上述语法可以使用任何存储引擎。但有一个问题:需要执行很长时间。MySQL会按行将数据从原表复制到一张新的表中，在复制期间可能会消耗系统所有的I/O能力，同时原表上回加上读锁。所以，在繁忙的表上执行此操作要特别小心。一个替代方案是采用导入与导出的方法，手工进行表的复制。如果转换表的存储引擎，将会失去和原引擎相关的所有特性。例如，将一张InnoDB表转换为MyISAM,然后再转换回InnoDB，原InnoDB表上所有的外键将丢失。
2.导出与导入
为了更好地控制转换的过程，可以使用mysqldump工具将数据导出到文件，然后修改文件中CREATE TABLE语句的存储引擎选项，注意同时修改表名，因为同一个数据库中不能存在相同的表ing，即使它们使用的是不同的存储引擎。同时要注意mysqldump默认回自动再CREATE TABLE语句前加上DROP TABLE语句，不注意这一点可能回导致数据丢失.
3.创建与查询(CREATE 和SELECT)
第三种转换的技术综合了第一种方法的高效和第二种方法的安全。不需要导出整个表的数据，而是先创建一个新的存储引擎的表，然后利用INSERT...SELECT语法来导数据:
```sql
mysql>START TRANSACTION;
mysql>INSERT INTO innodb_table SELECT * FROM myisam_table WHERE id BETWEEN x AND y;
mysql>COMMIT;
```
这样操作完成以后，新表是原表的一个全量复制，原表还在，如果需要可以删除原表。如果有必要，可以在执行的过程中对原表加锁，以确保新表和原表的数据一致。

理解性能剖析。
MySQL的性能剖析(profile)将最重要的任务展示在前面，但有时候没显式出来的信息也很重要。不幸的是，尽管性能剖析输出了排名、总计和平均值，但还是有很多需要的信息是却是的，如下所示:
1.值得优化的查询(worthwhile query)
性能剖析不会自当给出那些查询值得花时间去优化。这把我们带回到优化的不呢一，如果你读过Cary Millsap的书，对此就会有很多的理解。这里我们要再次强调两点:
第一，一些只占总响应时间比重很小的查询是不值得优化的。根据阿姆达尔定律(Amdahl's Law)，对一个占总响应时间不超过5%的查询进行优化，无论如何努力，收益也不会超过5%.
第二，如果花费了1000美元去优化一个任务，但业务的收入没有任何增加，那么可以说反而导致业务被逆优化了1000美元。如果优化的成本大于收益，就应当停止优化
2.异常情况
某些任务即使没有出现在性能剖析输出的前面也需要优化。比如某些任务执行次数很少，但每次执行都非常慢，严重影响用户体验。因为其执行频率低，所以总的响应时间占比并不突出。
3.未知的未知
一款好的性能剖析工具会显式可能的"丢失的时间"。丢失的时间指的是任务的总时间和实际测量到的时间之间的差。例如，如果处理器的CPU时间是10秒，二剖析到的任务总时间是9.7秒，那么就有300毫秒的丢失时间。这可能是有些任务没有测量到，也可能是由于测量的误差和精度问题的缘故。如果工具发现了这类问题，则要引起重视，因为有可能错过了某些重要的事情。即使性能剖析没有发现丢失时间，也需要注意考虑这类问题存在的可能性，这样才不会错过重要的信息。
4.被掩藏的细节
性能剖析无法显式所有响应时间的分布。只相信平均值是非常危险的，它会隐藏很多信息，而且无法表达全部情况。Peter经常举例说医院所有病人的平均提问没有任何价值。假如在前面的性能剖析的例子中，如果有两次查询的响应时间是1秒，而另外12771次查询的响应时间是几十微妙，结果会怎样？只从平均值里是无法发现两次1秒的查询的。要做出最好的决策，需要为性能剖析里输出的这一样中包含的12773次查询提供更多的信息，尤其是更多响应时间的信息，比如直方图、百分比、标准差、偏差指数。

性能剖析本身会导致服务器变慢吗？
说"是的"，是因为性能剖析确实会导致应用慢一点;说"不是"，是因为性能剖析可以帮助应用运行得更快。
性能剖析和定期检测都会带来额外开销。问题在于这部分得开销有多少，并且由此获得得收益是否能够抵消这些开销。大多数设计和构建过高性能应用程序得人相信，应该尽可能地测量一切可以测量地地方，并且接受这些测量带来的额外开销，这些开销应该被当称应用程序的一部分。Oracle的性能优化大师Tom Kyte曾被问到Oracle中的测量点的开销，他的回答是，测量点至少为性能优化贡献了10%。对此我们深表赞同，而且大多数应用并不需要要每天都运行详细的性能测量，所以实际贡献甚至要超过10%。即使不同这个观点，为应用构建一些可以永久使用的轻量级的性能剖析也是有意义的。如果系统没有每天变化的性能统计，则碰到无法提前预知的性能瓶颈就是一件头痛的事情，发现问题的时候，如果有历史数据，则这些历史数据价值是无限的。而且性能数据还可以帮助规划好硬件采购、资源分配、以及预测周期性的性能尖峰。那么何谓"轻量级"的性能剖析？比如可以为所有的SQL语句计时，加上脚本总时间统计，这样做的代价不高，而且不需要在每次页面查看(page view)时都执行.如果流量趋势比较稳定，随机采样也可以，随机采用可以通过在应用程序中设置实现:
```php
<?php
$profiling_enabled = rand(0,100) >99;
?>
```
这样只有1%的会话会执行性能采样，来帮助定位一些严重的问题。这种策略在生产环境中尤其有用，可以发现一些其他方法无法发现的问题。

剖析服务器负载。
服务器端的剖析很有价值，因为在服务器端可以有效地审计效率低下的查询。定位和优化"坏"查询能够显著地提升应用的性能，也能解决某些特定的难题。还可以降低服务器的整体压力，这样所有的查询都将因为减少了对共享资源的争用而收益("间接的好处")。降低服务器的负载也可以推迟或者避免升级更昂贵硬件的需求，还可以发现和定位糟糕的用户体验，比如某些极端情况.
MySQL的每一个新版本中都增加了更多的可测量点。如果当前的趋势可靠的话，那么在性能方面比较重要的测量需求很快能够在全球范围内得到支持。但如果只是需要剖析并找出代价高的查询，就不需要如此复杂。有一个工具很早之前就能帮到我们了，这就是慢查询日志。

剖析单条查询。
在定位到需要优化的单条查询后，可以针对查询"钻取"更多的信息，确认为什么会花费这么长的时间执行，以及需要如何去优化。不幸的是，MySQL目前大多数的测量点对于剖析查询都没有什么帮助。当然这种状况正在改善，大多数生产环境的服务器还没有使用包含最新剖析特性的版本。所以在实际应用中，除了SHOW STATUS、SHOW PROFILE、检查慢查询日志的条目(这还要求必须是Percona Server,官方MySQL版本的慢查询缺失了很多附加信息)这三种方法外就没有什么更好的办法了。

使用性能剖析。
当获得服务器或者查询的剖析报告后，怎么使用？好的剖析报告能够将潜在的问题显示出来，但最终的解决方案还需要用户来决定(尽管报告可能会给出建议)。优化查询时，用户需要对服务器如何执行查询有较深的了解。剖析报告能够尽可能多地收集需要的信息、给出诊断问题的正确方向，以及为其他诸如EXPLAIN等工具提供基础信息。
尽管一个拥有完美测量信息的剖析报告可以i让事情变得简单，但现有系统通常都没有完美的测量支持。例如，我们虽然推断出是临时表和没有索引的读导致查询的响应事件过长，但却没有明确的证据。因为无法测量所有需要的信息，或者测量的范围不正确，有些问题就很难解决。例如，可能没有集中在需要优化的地方测量，而是测量了服务器层面的活动，或者测量的是查询开始之前的计数器，而不是查询开始后的数据。
也有其他的可能性。设想一下正在分析慢查询日志，发现了一个很简单的查询正常情况下都非常快，却有几次非常不合理地执行了很长事件。手工重新执行一遍，发现也非常快，然后使用EXPLAIN 查询其执行计划，也正确地使用了索引。然后尝试修改WHERE条件中使用不同的值，以排除缓存命中的可能，也没有发现什么问题，这可能是什么原因呢?
如果使用官方版本的MySQL,慢查询日志中没有执行计划或者详细的时间信息，对于偶尔记录到的这几次查询异常慢的问题，很难知道其原因在哪里，因为信息优先，可能是系统中有其他东西消耗了资源，比如正在备份，也可能是某种类型的所或者争用阻塞了查询的进度。

整数类型。
有两种类型的数字:整数(whole number)和实数(real number)。如果存储整数，可以使用这几种整数类型:TINYINT,SMALLINT, MEDIUMINT,INT,BIGINT.分别使用8，16，24，32，64存储空间。它们可以存储的值的范围从-2^(N-1)到2^(N-1)-1,其中N是存储空间的位数。
整数类型有可选的UNSIGNED属性，表示不允许负值，这大致可以使正数的上限提高已被。例如TINYINT UNSIGNED可以存储的范围是0~255,而TINYINY的存储范围是-128~127.
有符号和无符号类型使用相同的存储空间，并具有相同的性能，因此可以根据实际情况选择合适的类型。你的选择决定MySQL是怎么在内存和磁盘中保存数据的，然而，整数计算一半使用64位的BIGINT整数，即使在32位环境也是如此。(一些聚合函数是例外，它们使用DECIMAL或者DOUBLE进行计算)。
MySQL可以为整数类型指定宽度，例如INT(11)，对大多数应用这是没有意义的，他不会限制值得合法范围，只是规定了MySQL的一些交互工具(例如MySQL命令行客户端)用来显示字符的个数。对于存储和计算来说INT(1)和INT(20)是相同的。

实数类型。
实数是带有小数部分的数字。然而，它们不只是为了存储小数部分；也可以使用DECIMAL存储比BIGINT还大的整数。MySQL既支持精确类型，也支持不精确类型。
FLOAT和DOUBLE类型支持使用标准的浮点运算进行近似计算。如果需要直到浮点运算时怎么计算的，则需要研究所使用的平台的浮点数的具体实现。DECIMAL类型用于存储精确的小数。在MySQL 5.0和更高版本，DECIMAL类型支持精确计算。MySQL4.1及更早版本则使用浮点运算来实现DECIMAL的计算，这样做会因为精度损失导致一些奇怪的结果。在这些版本的MySQL中，DECIMAL只是一个"存储类型"。
因为CPU不支持对DECIMAL的直接计算，所以在MySQL5.0以及更高版本中，MySQL服务器自身实现了DECIMAL的高精度计算。相对而言，CPU直接支持原生浮点计算，所以浮点运算明显更快。
浮点和DECIMAL类型都可以指定精度。对DECIMAL列，可以指定小数点前后所允许的最大位数。这会影响列的空间消耗。MySQL5.0和更高版本将数字打包保存到一个二进制字符串中(每4个字节存9个数字)。例如DECIMAL(18,9)小数点两边将个存储9个数字，一共使用9个字节:小数点前的数字用4个字节，小数点后的数字用4个字节，小数点本身占1个字节。
MySQL5.0和更高版本中的DECIMAL类型允许最多65个数字。而早期的MySQL版本中，这个限制时254个数字，并且保存为未压缩的字符串(每个数字一个字节)。然而，这些(早期)版本实际上并不能在计算中使用这么大的数字，因为DECIMAL只是一种存储格式，在计算中DECIMAL会转换为DOUBLE类型。
有多种方法可以指定浮点列所需要的精度，这回使得MySQL悄悄选择不同的数据类型，或者在存储时对值进行取舍。这些精度定义时非标准的，所以建议只指定数据类型，不指定精度。
浮点类型在存储同样范围的值时，通常比DECIMAL使用更少的空间。FLOAT使用4个字节存储。DOUBLE只能用8个字节，相比FLOAT有更高的精度和更大的范围。和整数类型一样，能选择的只是存储类型;MySQL使用DOUBLE作为内部浮点计算的类型。
因为需要额外的空间和计算开销，所以应该尽量只在对小数进行精确计算时才使用DECIMAL——例如存储财务数据。但在数据量比较大的时候，可以高铝使用BIGINT代替DECIMAL,将需要存储的货币单位根据小数的位数乘以相应的倍数即可。假设要存储财务数据精确到万分之一，则可以把所有金额乘以一百万，然后将结果存储在BIGINT里，这样就可以同时避免浮点存储计算不精确和DECIMAL精确计算代价高的问题

字符串类型。
MySQL支持多种字符串类型，每种类型还有很多变种。这些数据类型在4.1和5.0版本发生了很大的变化，使得情况更加复杂。从MySQL4.1开始，每个字符串列可以定义自己的字符集和排序规则，或者说校对规则(collation).这些东西会很大程度上影响性能。
1.VARCHAR和CHAR类型
VARCHAR和CHAR时两种最主要的字符串类型。不幸的时，很静精确地解释这些值是怎么存储在磁盘和内存中地，因为这跟存储引擎地具体实现有关。下面的描述假设使用的存储引擎是InnoDB和/或者MyISAM。
先看看VARCHAR和CHAR值通常在磁盘上怎么存储。请注意，存储引擎存储CHAR或者VARCHAR值得方式在内存中和磁盘上可能不一样，所以MySQL服务器从存储引擎独处得值可能需要转换另一种存储格式。下面是关于两种类型的一些比较

VARCHAR:
VARCHAR类型用于存储可变长字符串，是最常见的字符串数据类型。它比定长类型更节省空间，因为它仅使用必要的空间(例如，越短的字符串使用越少的空间)。有一种情况例外，如果MySQL表使用ROW_FORMAT=FIXED创建的话，每一行都会使用定长存储，这会很浪费空间。
VARCHAR需要使用1或者2个额外字节记录字符串的长度:如果列的最大长度小于或等于255字节。则只使用1个字节表示，否则使用2个字节。假设采用latin1字符集，一个VARCHAR(10)的列需要11个字节的存储空间。VARCHAR(1000)的列则需要1002个字节，因为需要2个字节存储长度信息。
VARCHAR节省了存储空间，所以对性能也有帮助。但是，由于行是变长的，在UPDATE时可能使行变得比原来更长，这就导致需要做额外的工作，如果一个行占用的空间增长，并且在页内没有更多的的空间可以存储，在这种情况下，不同的存储引擎的处理方式是不一样的。例如，MyISAM会将行拆成不同的片段存储，InnoDB则需要分裂页来使行可以放进页内。，其他一些存储引擎也许从不在原数据为止更新数据。
下面这些情况下使用VARCHAR是合适的:字符串列的最大长度比平均长度大很多；列的更新很少，所以碎片不是问题；使用了像UTF-8这样的复杂的字符集，每个字符都使用不同的字节数进行存储。在5.0或者更高版本。MySQL在存储和检索时会保留末尾空格。但在4.1或更老版本，MySQL会剔除末尾空格。
InnoDB则更灵活，它可以把过长的VARCHAR存储为BLOB
CHAR:
CHAR类型是定长的:MySQL总是根据定义的字符串长度分配足够的空间。当存储CHAR值时，MySQL会删除所有的末尾空格(在MySQL4.1和更老版本中VARCHAR也是这样实现的——也就是说这些版本中CHAR和VARCHAR在逻辑上是一样的，区别只是在存储格式上)。CHAR会根据需要采用空格进行填充以方便比较。
CHAR适合存储很短的字符串，或者所有的值都接近同一个长度。例如CHAR非常适合存储密码的MD5值，因为这是一个定长的值。对于经常变更的数据，CHAR也比VARCHAR更好，因为定长的CHAR类型不容易产生碎片。对于非常短的列，CHAR比VARCHAR在存储空间上也更有效率。例如使用CHAR(1)来存储只有Y和N的值，如果采用单字节字符集(记住字符串长度不是字节数，是字符数，多字节字符集会需要更多的空间存储单个字符)只需要一个字节，但是VARCHAR(1)却需要两个字节，因为还有一个记录长度的额外字节。
CHAR类型的这些行为可能有一点难以理解，下面通过一个具体的例子来说明。

BLOB和TEXT类型
BLOB和TEXT都是为存储很大的数据而设计的字符串数据类型，分别采用二进制和字符方式存储。
实际上它们分别属于两组不同的数据类型家族:字符类型是TINYTEXT，SMALLTEXT,TEXT，MEDIUMTEXT，LONGTEXT;对应的二进制类型是TINYBLOB，SMALLBLOB,BLOB,MEDIUMBLOB,LONGBLOB.BLOB是SMALLBLOB的同义词，TEXT是SMALLTEXT的同义词。
与其他类型不同，MySQL把每个BLOB和TEXT值当作一个独立的对象处理。存储引擎在存储时通常会做特殊处理。当BLOB和TEXT值太大时，InnoDB会使用专门的"外部"存储区域来进行存储，此时每个值在行内需要1~4个字节存储一个指针，然后再外部存储区域存储实际的值。
BLOB和TEXT家族之间仅有的不同时BLOB类型存储的是二进制数据，没有排序规则或字符集，而TEXT类型有字符集和排序规则。
MySQL对BLOB和TEXT列进行排序与其他类型是不同的:它只对每个列的最前max_sort_length字节而不是整个字符串做排序。如果只需要排序前面一小部分字符，则可以减小max_sort_length的配置，或者使用ORDER BY  SUBSTRING(column, length).
MySQL不能将BLOB和TEXT列全部长度的字符串进行索引，也不能使用这些索引消除排序

使用枚举类型(ENUM)代替字符串类型
有时候可以使用枚举列代替常用的字符串类型。枚举列可以把一些不重复的字符串存储成一个预定义的集合。MySQL在存储枚举时非常紧凑，会根据列表值得数量压缩到一个或者两个字节中。MySQL会在内部将每个值在列表中得为止保存为整数，并且在表的.frm文件中保存"数字-字符串"映射关系的"查找表"，
例如，
```sql
mysql> CREATE TABLE enum_test(e ENUM('fish', 'apple', 'dog') NOT NULL);
Query OK, 0 rows affected (0.03 sec)
mysql> INSERT INTO enum_test(e) VALUES('fish'), ('dog'),('apple');
Query OK, 3 rows affected (0.02 sec)
Records: 3  Duplicates: 0  Warnings: 0
```
这三行数据实际存储为整数，而不是字符串。可以通过在数字上下问环境检索看到这个双重属性:
```sql
mysql> SELECT e+0 FROM enum_test;
+-----+
| e+0 |
+-----+
|   1 |
|   3 |
|   2 |
+-----+
3 rows in set (0.05 sec)
```
如果使用数字作为ENUM枚举常量，这种双重性很容易导致混乱，例如ENUM('1','2','3').建议尽量避免这么做。另外一个让人吃惊的地方时，枚举字段是按照内部存储的整数而不是定义的字符串进行排序的:
```sql
mysql> SELECT e FROM enum_test ORDER BY e;
+-------+
| e     |
+-------+
| fish  |
| apple |
| dog   |
+-------+
3 rows in set (0.05 sec)
```
一种绕过这种限制的方式是按照需要的顺序来定义枚举列。另外也可以在查询中使用FIELD()函数显式地指定排序顺序，但这会导致MySQL无法利用索引消除排序。
```sql

mysql> SELECT e FROM enum_test ORDER BY FIELD(e, 'apple', 'dog','fish');
+-------+
| e     |
+-------+
| apple |
| dog   |
| fish  |
+-------+
3 rows in set (0.07 sec)
```

日期和时间类型
MySQL可以使用许多类型来保存日期和时间值，例如YEAR和DATE.MySQL能存储的最小时间粒度为秒(MariaDB支持微秒级别的时间类型)。但是MySQL也可以使用微秒级别的粒度进行临时运算，接下来会展示如何绕开这种存储限制。大部分时间类型都没有替代品，因此没有什么事最佳选择的问题。唯一的问题是保存日期和时间的时候需要做什么。MySQL提供两种相似的日期类型:DATETIME和TIMESTAMP。对于很多应用程序，它们都能工作，但是在某些场景，一个比另一个工作得好。
1.DATETIME
这个类型能保存大范围的值，从1001年到9999年，精度为秒。它把日期和时间封装到格式YYYYMMDDHHMMSS的整数中，与时区无关。使用8个字节的存储空间。默认情况下，MySQL以一种可排序的、无歧义的格式显式DATETIME值，例如"2008-01-16 22:37:08"。这是ANSI标准帝国一的日期和时间表示方法。
2.TIMESTAMP
就像它的名字一样，TIMESTAMP类型保存了从1970年1月1日午夜(格林尼治标准时间)以来的秒数，它和UNIX时间戳相同。TIMESTAMP只使用4个字节的存储空间，因此它的范围比DATETIME小得多:只能表示1970年到2038年。MySQL提供了FROM_UNIXTIME()函数把Unix时间戳转换为日期，并提供了UNIX_TIMESTAMP()函数把七日转换为Unix时间戳。MySQL4.1以及更新的版本按照DATETIME的方式格式化TIMESTAMP的值，但是MySQL4.0以及更老的版本不会在各个部分之间显式任何标点符号。这仅仅是显式格式上的区别，TIMESTAMP的存储格式在各个版本都是一样的。
TIMESTAMP显式地值也依赖于时区。MySQL服务器、操作系统，以及客户端连接都有时区设置。因此，存储值为0地TIMESTAMP在美国东部时区显式为"1969-12-31 19:00:00"，与格林尼治时间差5个小时。有必要强调一下这个区别:如果在多个时区存储或访问数据，TIMESTAMP和DATETIME的行为将很不一样。前者提供的值与时区有关系，后者则保留文本表示的日期和时间。
TIMESTAMP也有DATETIME没有的特殊属性。默认情况下，如果插入时没有指定第一个TIMESTAMP的值，MySQL则设置这个列的值为当前时间(TIMESTAMP的行为规则比较复杂，并且在不同的MySQL版本里会变动，所以你应该验证数据库的行为是你需要的。一个好的方式是修改完TIMESTAMP列后用SHOW CREATE TABLE命令检查输出)。在插入一行记录时，MySQL默认也会更新第一个TIMESTAMP列的值(除非在UPDATE语句中明确指定了值)。你可以配置任何TIMESTAMP列插入和更新行为。最后，TIMETSAMP列默认为NOT NULL，这也和其他的数据类型不一样。

除了特殊行为之外，通常也应该尽量使用TIMESTAMP,因为它比DATETIME空间效率更高。有时候人们会将Unix时间戳存储为整数值，但这不会带来任何收益。用整数保存时间戳的格式通常不方便处理，所以不推荐这样做。如果需要存储比秒更小粒度的日期和时间值怎么办呢？MySQL目前没有提供合适的数据类型，但是可以使用自己的存储格式:可以使用BIGINT类型存储微秒级别的时间戳，或者使用DOUBLE存储秒之后的小数部分，这两种方式都可以，或者也可以使用MariaDB替代MySQL

位数据类型
MySQL有少数 集中存储类型使用紧凑的位存储数据。所有这些位类型，不管底层存储格式和处理方式如何，从技术上来说都是字符串类型。
1.BIT
在MySQL5.0之前，BIT是TINYINT的同义词。但是在MySQL5.0以及更新版本，这是一个特性完全不同的数据类型。可以使用BIT列在一列中存储一个或多个true/false值。BIT(1)定义一个包含单个位的字段,BIT(2)存储2个位，依此类推，BIT列的最大长度是64个位。BIT的行为因存储引擎而异。MyISAM会打包存储所有的BIT列，所以17个单独的BIT列只需要17个位存储(假设没有可为NULL的列)，这样MyISAM只适用3个字节就能存储17个BIT列。其他存储引擎例如Memory和InnoDB，为每个BIT列使用一个豿存储的最小整数类型来存放，所以不能节省存储空间。
MySQL把BIT当作字符串类型，而不是数字类型。当检索BIT(1)的值时，结果是一个包含二进制0或1值得字符串，而不是ASCII码的"0"或"1".然而，在数字上下文的场景中检索时，结果将时位字符串转换成的数字。如果需要和另外的值比较结果，一定要记得这一点。例如，如果存储一个值b'00111001'(二进制值等于57)到BIT(8)的列并且检索它，得到的内容是字符码为57的字符串。也就是说得到00111001。但是在数字上下文场景中，得到的是数字57:
```sql
mysql> INSERT INTO bittest VALUES(b'00111001');
Query OK, 1 row affected (0.03 sec)

mysql> SELECT CONCAT(a,' ') AS 'a ', a, a+0 FROM bittest;
+----+----------+-----+
| a  | a        | a+0 |
+----+----------+-----+
| 9  | 00111001 |  57 |
+----+----------+-----+
1 row in set (0.08 sec)

mysql> SELECT VERSION();
+-----------+
| VERSION() |
+-----------+
| 5.7.44    |
+-----------+
1 row in set (0.08 sec)
```
这是相当令人费解的，所以我们认为应当谨慎使用使用BIT类型。对于大部分应用，最好避免使用这种类型。如果想在一个bit的存储空间中个存储一个true/false值，另一个方法是创建一个可以为空的CHAR(0)列。该列可以保存控制(NULL)或者长度为零的字符串(空字符串)
2.SET
如果需要保存很多的true/false值，可以考虑合并这些列到一个SET数据类型，它在MySQL内部是以以一系列打包的位的集合来表示的。这样就有效地利用了存储空间，并且MySQL有像FIND_IN_SET()和FIELD()这样的函数，方便地在查询中使用。它的主要缺点是改变列的定义的代价较高:需要ALTER TABLE,这对达标来说非常昂贵的操作。一半来说，也无法在SET列上通过索引查找。
3.在整数列上进行按位操作
一种替代SET的方式使用一个整数包装一系列的位。例如，可以把8个位包装到一个TINYINT中，并且按位操作来使用。可以在应用中为每个位定义名称常量来简化这个工作。比起SET,这种办法主要的好处在于可以不使用ALTER TABLE改变字段代表的"枚举"值，缺点是查询语句更难写，并且更难理解(当第5个bit位被设置时是什么意思?)一些人非常适应这种方式，也有一些人不适应，所以是否采用这种技术取决于个人的偏好。

选择标识符(identifier)
为表示列(identifier column)选择合适的数据类型非常重要。一般来说更有可能用标识符与其他值进行比较(例如，在关联操作中)，或者通过标识列寻找其他列。标识列也可能在另外的表中作为外键使用，所以为标识列选择数据类型时，应当选择跟关联表中的对应列一样的类型(在相关的表中使用相同的数据类型是个好注意，因为这些列很可能在关联中使用)。
当选择标识列的类型时，不仅仅需要考虑存储类型，还需要考虑MySQL对这种类型怎么执行计算和比较。例如，MySQL在内部使用整数存储ENUM和SET类型，然后在做比较操作时转换为字符串。一旦选定了一种类型，要确保在所有关联表种都是用同样的类型。类型之间需要精确匹配，包括像UNSIGNED这样的属性(如果使用的是InnoDB存储引擎，将不能在数据类型不是完全匹配的情况下创建外键，否则会有保存信息:"ERROR 1005(HY000):Can't create table",这个信息可能让人迷惑不解，这个问题在MySQL邮件组也经常有人抱怨(但奇怪的是，在不同长度的VARCHAR列上创建外键又是可以的))混用不同数据类型可能导致性能问题，即使没有性能影响，在比较操作时隐式类型转换也可能导致很难发现的错误。这种错误可能会很久以后才突然出现，那时候可能都已经忘记是在比较不同的数据类型。
在可以满足值得范围的需求，并且预留未来增长空间的前提下，应该选择最小的数据类型/；例如有一个state_id列存储美国各州的名字(这是关联到另一张存储名字的表的ID)就不需要几千或几百万个值，所以不需要使用INT。TINYINT足够存储，而且比INT少了3个字节。如果用这个值作为其他表的外键，3个字节可能导致很大的性能差异。下面是一些小技巧
1.整数类型
整数通常是标识列最好的选择，因为它们很快并且可以使用AUTO_INCREMENT
2.ENUM和SET类型
对于标识列来说，ENUM和SET类型通常是一个糟糕的选择，尽管对某些只包含固定状态或者类型的静态"定义表"来说可能是没有问题的。ENUM和SET列适合存储固定信息，例如有序的状态、产品类型、人的性别。举个例子，如果使用枚举字段来定义产品类型，也许会设计一张以这个枚举字段为主键的查找表(可以在查找表种增加一些列来保存描述性质的文本，这样就能够生成一个术语表，或者为网站的下拉菜单提供有意义的标签)。这时，使用枚举类型作为标识列是可行的，但是大部分情况下都要避免这么做。
3.字符串类型
如果可能，应该避免使用字符串类型作为标识列，因为它们很消耗空间，并且通过常比数字类型慢。尤其是在MyISAM表里使用字符串作为标识列时要特别小心。MyISAM默认对字符串使用压缩索引，这回导致查询慢得多。最多会有6倍的性能下降。
4.对于完全"随机"的字符串也需要多加注意
例如MD5()、SHA1()或者UUID()产生的字符串。这些函数生成的新值会任意分布在很大的空间内，这会导致INSERT以及一些SELECT语句变得很慢(另一方面，对一些有很多写的特别大的表，这总伪随机值实际上可以帮助消除热点)。
3.1 因为插入值会随机地写到索引的不同为止，所以使得INSERT语句更慢。这会导致页分裂、磁盘随机访问，以及对于聚簇存储引擎产生聚簇索引刷碎片。
3.2 SELECT语句会变得很慢，因为逻辑上相邻的行会分布在磁盘和内存的不同地方
3.3 随机值导致缓存对所有类型的查询语句效果都很差，因为会使得 缓存赖以工作的访问局部性原理失效。如果整个数据集都是一样"热"，那么缓存任何一部分特定数据到内存都没有好处；如果工作集比内存大，缓存将会有很多刷新和不命中
如果存储UUID，则应该移除"-"符号，或者更好的做法是，用UNHEX()函数转换UUID值伪16字节的数字，并且存储在一个BINARY(16)列种。检索时可以通过HEX()函数来格式化十六进制格式。
UUID()生成的值与加密散列函数例如SHA1()生成的值有不同的特征:UUID虽然分布也不均匀，但还是有一定顺序的。尽管如此，但还是不如递增的整数好用

特殊类型数据。
某些类型的数据并不直接与内置类型一致。低于秒级精度的时间戳就是一个例子。另外一个例子是一个IPv4地址。人们经常使用VARCHAR(15)列存储IP地址。然而，它们实际上是32位无符号整数。不是字符串。用小数点将地址分成四段的表示方法只是为了让人们阅读容易。所以应该用无符号整数存储IP地址。MySQL提供INET_ATON()和INET_NTOA()函数在这两种表示方法之间转换

范式的优点和缺点。
当为性能问题而寻求帮助时，经常会被建议对schema进行范式化设计，尤其是写密集的场景。这通常是个好建议。因为下面这些原因，范式化通常能够带来好处:
1.范式化的更新操作通常比反范式化要快
2.当数据较好地范式化时，就只有很少或者没有重复数据，所以只需要修改更少地数据
3.范式化地表通常更小，可以更好地放在内存里，所以执行操作会更快
4.很少有多余地数据意味着检索列表数据时更少需要DISTINCT或者GROUP BY 语句

还是前面地例子:在非范式化的结构种鄙视使用DISTINCT 或者GROUP BY 才能获得一份唯一的部门列表，如果部门(DEPARTMENT)是一张单独的表，则只需要简单的查询这张表就行了.
范式化设计的schema的缺点是通常需要关联，稍微复杂一些的查询语句在符合范式的schema上都可能需要至少一次的关联，也许更多。这不但代价昂贵，也可能使一些索引策略无效。例如，范式化可能将列放在不同的表种，而这些列如果在一个表种本可以属于同一个索引

反范式的优点和缺点。
反范式化的schema因为所有数据都在一张表种，可以很好地避免关联。
如果不需要关联表，则对大部分查询最差地情况——即使表没有使用索引——是全表扫描。当数据比内存大时这可能比关联要快得多，因为这样避免了随机IO.单独得表也能使用更有效得索引策略。假设有一个网站，允许用户发送消息，并且一些用户是付费用户。现在想查看付费用户最近的10条信息。如果是范式化的结构并且索引了发送日期字段published,这个查询也许看起来像这样:
```sql
mysql>SELECT message_text,user_name FROM message INNER JOIN user ON message.user_id =user.id WHERE user.account_type='premiumv' ORDER BY message.publised DESC LIMIT 10;
```
要更有效地执行这个查询，MySQL需要扫描message表的published字段的索引。对于每一行找到的数据，将需要到user表里检查这个用户是不是付费用户。如果只有一小部分用户是付费账户，那么这是效率低下的做法。另一种可能的执行计划是从user表开始，选择所有的付费用户，获得它们所有的信息，并且排序。但这可能更加糟糕。主要问题是关联，使得需要在一个索引中又排序又过滤，如果采用反范式化组织数据，将两张表的字段合并一下，并且增加一个索引(account_type,published)，就可以不通过关联写出这个查询。这将非常高效:
```sql
mysql>SELECT message_text,user_name FROM user_messages WHERE account_type='premium' ORDER BY published DESC LIMIT 10;
```

混用范式化和反范式化。
范式化和反范式化的schema各有优劣，怎么选择最佳的设计？
事实是，完全的范式化和完全的反范式化schema都是实验室里才有的东西:在真实世界中很少会这么极端地使用。在实际应用中经常需要混用，可能使用部分范式化地schema、缓存表以及其他技巧。最常见地反范式化数据地方法是复制或者缓存，在不同地表中存储相同地特定列。在MySQL5.0和更新版本中，可以使用触发器更新缓存值，这使得实现这样地方案变得更简单。
在网站实例中，可以在user表和message表中都存储account_type字段，而不用完全地范式化。这避免了完全反范式化地插入和删除问题，因为即使没有消息地时候也绝不会丢失用户地信息。这样也不会把user_message表搞得太大，有利于高效地获取数据。但是现在更新用户的账户类型的操作代价就高了，因为需要同时更新两张表。至于这会不会是一个问题，需要考虑更新的频率以及更新的时长，并和执行SELECT查询的频率进行比较。
另一个从附表冗余一些数据到子表的理由是排序的需要，例如，在范式化的schema里通过作者的名字对消息排序的代价将会非常高，但是如果在message表中缓存author_name字段并且建好索引，则可以非常高效地完成排序。
缓存衍生值也是有用的。如果需要显示每个用户发了多少消息(像很多论坛做的)，可以没执行一个昂贵的子查询来计算并显示它；也可以在user表中建一个num_messages列，每当用户发新消息时更新这个值。

物化视图。
许多数据库管理系统(例如Oracle或者微软SQL Server)都提供了一个被称作物化视图地功能。物化视图实际上是预先计算并且存储在磁盘上的表，可以通过各种各样的策略刷新和更新。MySQL并不原生支持物化视图。然而Justin Swanhart的开源工具Flexviews，也可以自己实现物化视图。Flexviews比完全自己实现的解决方案更精细，并且提供了很多不错的功能使得可以更简单地创建和维护物化视图。它由下面这些部分组成:
1.变更数据抓取(Change Data Capture, CDC)功能，可以读取服务器的二进制日志，并且解析相关行的变更
2.一系列可以帮助创建和管理视图的定义的存储过程
3.一些可以应用变更到数据库中的物化视图的工具

对比传统的维护汇总表和缓存表的方法，Flexviews通过提取对源表的更改，可以增量地重新计算物化视图地内容。这意味着不需要通过查询原始数据来更新视图。例如，如果创建了一张汇总表用于计算每个分组地行数，此后增加了一行数据到源表中，Flexviews简单地给相应地组的行数加一即可。同样的技术对其他的聚合函数也有效，例如SUM()和AVG().这实际上是有好处的，基于行的二进制日志包含行更新前后的镜像，所以Flexviews不仅仅可以获得每行的新值，还可以需要查找源表就能直到每行数据的旧版本。计算增量数据比源表中读取数据的效率要高得多。
例如写出一个SELECT语句描述想从已经存在的数据库中得到的数据。这可能包含关联和聚合(GROUP BY)。Flexviews中有一个辅助工具可以转换SQL语句到Flexviews的API调用。Flexviews会做完所有的脏活、累活:监控数据库的变更并且转换后用于更新存储物化视图的表。现在应用可以简单地查询物化视图来替代查询需要检索的表。

Flexviews有不错的SQL覆盖范围，包括一些棘手的表达式，你可能没有料到一个工具可以在MySQL服务器之外处理这些工作。这一点对创建基于复杂SQL表达式的视图很有用，可以用基于物化视图的简单、快速的查询替换原来复杂的查询

计数器表。
如果应用在表中保存计数器，则在更新计数器时可能碰到并发问题。计数器表在Web应用中很常见。可以用这种表缓存一个用户的朋友数、文件下载次数等。创建一张独立的表存储计数器通常是个好主意，这样可使计数器表小且快。使用独立的表可以帮助避免查询缓存失效，并且可以使用下面展示的一些高级的技巧。应该让事情变得尽可能简单，假设有一个计数器表，只有一行数据，记录网站的点击次数:
```sql
mysql> CREATE TABLE hit_counter (
    -> cnt int unsigned not null
    -> ) ENGINE=InnoDB;
Query OK, 0 rows affected (0.03 sec)
```
网站的每次点击都会导致对计数器进行更新:
```sql
mysql> UPDATE hit_counter SET cnt = cnt + 1;
Query OK, 1 row affected (0.02 sec)
Rows matched: 1  Changed: 1  Warnings: 0
```
问题在于，对于任何想要更新这一行的事务来说，这条记录上都有一个全局的互斥锁(mutex)。这会使得这些事务只能串行执行。要获得更高的并发更新性能，也可以将计数器保存在多行中，每次随机选择一行进行更新。这样做需要对计数器表进行如下修改:
```sql
mysql> CREATE TABLE hit_counter_new (
    -> slot tinyint unsigned not null primary key,
    -> cnt int unsigned not null
    -> ) ENGINE=InnoDB;
Query OK, 0 rows affected (0.03 sec)
```
然后预先在这张表增加100行数据。现在选择一个随机的槽(slot)进行更新:
```sql
mysql> UPDATE hit_counter_new SET cnt = cnt + 1 WHERE slot = RAND() * 100;
```
要获得统计结果，需要使用下面这样的聚合查询:
```sql
mysql> SELECT SUM(cnt) FROM hit_counter_new;
```
一个常见的需求是每隔一段时间开始一个新的计数器(例如，每天一个)。如果需要这么做，则可以再简单地修改一下表设计:
```sql
mysql> CREATE TABLE daily_hit_counter (
    -> day date not null,
    -> slot tinyint unsigned not null,
    -> cnt int unsigned not null,
    -> primary key(day, slot)
    -> ) ENGINE=InnoDB;
Query OK, 0 rows affected (21.37 sec)
```
在这个场景中，可以不用像前面的例子那样预先生成行，而用ON DUPLICATE KEY UPDATE代替:
```sql
mysql> INSERT INTO daily_hit_counter(day,slot,cnt)
    -> VALUES(CURRENT_DATE, RAND() * 100, 1) ON DUPLICATE KEY UPDATE cnt = cnt +1;
Query OK, 1 row affected (0.02 sec)
```
如果希望减少表的行数，以避免表得太大，可以写一个周期执行的任务，合并所有结果到0号槽，并且删除所有其他的槽:
```sql
mysql> UPDATE daily_hit_counter AS c
    -> INNER JOIN (
    -> SELECT day,SUM(cnt) AS cnt, MIN(slot) AS mslot
    -> FROM daily_hit_counter
    -> GROUP BY day
    -> ) AS x USING(day)
    -> SET c.cnt = IF(c.slot = x.mslot, x.cnt, 0),
    -> c.slot =IF(c.slot = x.mslot, 0, c.slot);
Query OK, 1 row affected (0.06 sec)
mysql> DELETE FROM daily_hit_counter WHERE slot <> 0 AND cnt = 0;
```

更快地读，更慢地写。
为了提升读查询的速度，经常会需要建一些额外索引，增加冗余列，甚至是创建缓存表和汇总表。这些方法会增加写查询的负担，也需要额外的维护任务，但在设计高性能数据库时，这些都是常见的技巧:虽然写操作变得更慢了，但更显著地提高了读操作的性能

然而，写操作变慢并不是读操作变得更快所付出的唯一代价，还可能同时增加了读操作和写操作的开发难度

只修改.frm文件。
从前面的例子中可以看到修改表的.frm文件是很快的，但MySQL有时候会在没有必要的时候也重建.如果愿意冒一些风险，可以让MySQL做一些其他类型的修改而不用重建表。下面这些操作是有可能不需要重建表的:
1.移除(不是增加)一个列的AUTO_INCREMENT属性
2.增加、移除，或更改ENUM和SET常量。如果移除的是已经有行数据用到其值的变量，查询将会返回一个空字符串

基本的技术是为想要的表结构创建一个新的.frm文件，然后用它替换掉已经存在的那张表的.frm文件，像下面这样:
1.创建一张有相同结构的空表，并进行所需要的修改(例如增加ENUM常量)
2.执行FLUSH TABLES WITH READ LOCK.这将会关闭所有正在使用的表，并且进制任何表被打开
3.交换.frm文件
4.执行UNLOCK TABLES来释放第2步的读锁
下面以给sakila.film表的rating列增加一个常量为例来说明。当前列看起来如下
```sql
mysql> SHOW COLUMNS FROM film LIKE 'rating';
+--------+------------------------------------+------+-----+---------+-------+
| Field  | Type                               | Null | Key | Default | Extra |
+--------+------------------------------------+------+-----+---------+-------+
| rating | enum('G','PG','PG-13','R','NC-17') | YES  |     | G       |       |
+--------+------------------------------------+------+-----+---------+-------+
1 row in set (0.07 sec)
```
假设我们需要为那些对电影更加谨慎的父母们增加一个PG-14的电影分级：
```sql
mysql> CREATE TABLE film_new LIKE film;
Query OK, 0 rows affected (0.03 sec)

mysql> ALTER TABLE film_new
    -> MODIFY COLUMN rating ENUM('G','PG','PG-13','R','NC-17','PG-14')
    -> DEFAULT 'G';
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.02 sec)
```
注意，我们是在常量列表的末尾增加一个新的值。如果把新增的值放在中间，例如PG-13之后，则会导致已经存在的数据的含义被改变:已经存在的R值将变成PG-14,而已经存在的NC-17将变成R，等等。
接下来用操作系统的命令交换.frm文件
```bash
/var/lib/mysql/sakila# mv film.frm film_tmp.film
/var/lib/mysql/sakila# mv film_new.frm film.frm
/var/lib/mysql/sakila# mv film_tmp.frm film_new.frm
```
再回到MySQL 命令行，现在可以解锁表并且看到变更后的效果了:
```sql
mysql> UNLOCK TABLES;
Query OK, 0 rows affected (18.96 sec)
mysql> SHOW COLUMNS FROM film LIKE 'rating';
+--------+--------------------------------------------+------+-----+---------+-------+
| Field  | Type                                       | Null | Key | Default | Extra |
+--------+--------------------------------------------+------+-----+---------+-------+
| rating | enum('G','PG','PG-13','R','NC-17','PG-14') | YES  |     | G       |       |
+--------+--------------------------------------------+------+-----+---------+-------+
1 row in set (0.09 sec)
```
最后要做的事删除为完成这个操作而创建的辅助表:
```sql
mysql>DROP TABLE film_new;
```

快速创建MyISAM索引.
为了高效地载入数据到MyISAM表中，有一个常用的技巧是先禁用索引、载入数据，然后重新启用索引:
```sql
mysql>ALTER TABLE test.load_data DISABLE KEYS;
mysql>ALTER TABLE test.load_data ENABLE KEYS;
```
这个技巧能够发挥作用，是因为构建索引的工作被延迟到数据完全载入以后，这个时候已经可以通过排序来构建索引了，这样做会快很多，并且使得索引树的碎片更少、更紧凑。
不幸的是，这个办法对唯一索引无效，因为DISABLE KEYS只对非唯一索引有效。MyISAM会在内存中构造唯一索引，并且为载入的每一行检查唯一性。一旦索引的大小超过了有效内存大小，载入操作就会变得越来越慢。
在现代版本的InnoDB版本中，有一个类似的技巧，这依赖于InnoDB的快速在线索引创建功能。这个技巧是，先删除所有的非唯一索引，然后增加新的列，最后重新创建删除掉的索引。Percona Server可以自动完成这些操作步骤。也可以使用像前面说的ALTER TABLE的骇客方法来加速这个操作，但需要多做一些工作并且承担一定的风险。这对备份中载入数据是很有用的，例如，当已经直到所有的数据都是有效的并且没有必要做唯一性检查就可以这么来操作。
下面是操作步骤:
1.用需要的表结构创建一张表，但是不包括索引。
2.载入数据到表以后构建.MYD文件
3.按照需要的结构创建另外一张空表，这次要包含索引。这回创建需要的.frm和.MYI文件
4.获取读锁并刷新表
5.重命名第二张表的.frm和MYI文件，让MySQL认为是第一张表的文件
6.释放读锁
7.使用REPAIR TABLE来重建表的索引。该操作会通过排序来构建所有索引，包括唯一索引

B-Tree索引
当人们讨论索引的时候，如果没有特别指明类型，那多半说的是B-Tree索引，它使用B-Tree数据结构来存储数据。(实际上很多存储引擎使用的是B+Tree，既每一个叶子节点都包含指向下一个叶子节点的指针，从而方便叶子节点的范围遍历)，大多数MySQL引擎都支持折中索引。Archive引擎是一个例外:5.1之前Archive不支持任何索引，直到5.1才开始支持单个自增列(AUTO_INCREMENT)的索引。使用术语"B-Tree",是因为MySQL在CREATE TABLE和其他语句中也使用该关键字，不过，底层的存储引擎也可能使用不同的存储结构，例如，NDB集群存储引擎内部实际上使用了T-Tree结构存储这种索引，即使其名字是BTREE;InnoDB则使用的是B+Tree;
存储引擎以不同的方式使用B-Tree索引，性能也各有不同，各有优劣。例如,MyISAM使用前缀压缩技术使得索引更小，但InnoDB则按照原数据格式进行存储。再如MyISAM索引通过数据的物理位置引用被索引的行，而InnoDB则根据主键引用被索引的行。
B-Tree通常意味着所有的值都是按顺序存储的，并且每一个叶子页到根的距离相同。如图所示，该图展示了B-Tree索引的抽象表示，大致反映了InnoDB索引是如何工作的。MyISAM使用的结构有所不同，但基本思想是类似的。
B-Tree索引能够加快访问数据的速度，因为存储引擎不再需要进行全表扫描来获取需要的数据，取而代之的是从索引的根节点(未画出)开始进行搜索。根节点的槽中存放了指向子节点的指针，存储引擎根据这些指针向下层查找。通过比较节点页的值和要查找的值可以找到合适的指针进入下层子节点，这些指针实际上定义了子节点页中值得上限和下限。最终存储引擎要么是找到对应的值，要么该记录不存在。
叶子节点比较特别，它们的指针指向的是被索引的数据，而不是其他的节点页(不同引擎的"指针类型不同")。如图所示，该图回直了一个节点和其对应的叶子节点，其实在根节点和叶子节点之间可能有很多层节点页。树的深度和表的大小直接相关。
B-Tree对索引列是顺序组织存储的，所以很适合查找范围数据。例如，在一个基于文本域的索引树上，按字母顺序传递连续的值进行查找是非常合适的，所以像"找出所有以I到K开头的名字"这样的查询效率会非常高.假设有如下数据表:
```sql
mysql> CREATE TABLE Peoople (
    -> last_name varchar(50) not null,
    -> first_name varchar(50) not null,
    -> dob date not null,
    -> gender enum('m','f') not null,
    -> key(last_name, first_name, dob)
    -> );
```
对于表中的每一行数据，索引中包含了last_name、first_name和dob列的值，上图展示了该索引是如何组织数据的存储的。请注意，索引对多个值进行排序的依据是CREATE TBLE语句中定义索引时列的顺序，看一下最后两个条目，两个人的姓和名都一样，则根据它们的出生日期来排列顺序。

哈希索引
哈希索引(hash index)基于哈希表实现，只有精确匹配索引所有的列的查询才有效。对于每一行数据，存储引擎都会对所有的索引列计算一个哈希码(hash code).哈希码是一个较小的值，并且不同键值的行计算出来的哈希码也不一样。哈希索引将所有的哈希码存储在索引中，同时哈希表中保存指向每个数据行的指针。在MySQL中，只有Memory引擎显式支持哈希索引。这也是Memory引擎表的默认索引类型，Memory引擎同时也支持B-Tree索引。值得一提的是，Memory引擎是支持非唯一哈希索引的，这在数据库世界里面是比较与众不同的。如果多个列的哈希值相同，索引会以链表的方式存放多个记录指针到同一个哈希条目中.下面来看一个例子
```sql
mysql> CREATE TABLE testhash(
    -> fname VARCHAR(50) NOT NULL,
    -> lname VARCHAR(50) NOT NULL,
    -> KEY USING HASH(fname)
    -> ) ENGINE=MEMORY;
```
表种包含如下数据:
```sql
mysql> SELECT * FROM testhash;
+-------+-----------+
| fname | lname     |
+-------+-----------+
| Arjen | Lentz     |
| Baron | Schwartz  |
| Peter | Zaitsev   |
| Vadim | Tkachenko |
+-------+-----------+
```
假设索引使用假想的哈希函数f(),它返回下面的值(都是示例数据，非真实数据):
```c
f('Arjen')=2323
f('Baron')=7437
f('Peter')=8784
f('Vadim')=2458
```
则哈希索引的数据结构如下:
```c
槽(Slot)      值(Value)
2323          指向第1行的指针
2458          指向第4行的指针
7437          指向第2行的指针
8784          指向第3行的指针
```
注意每隔槽的编号是顺序的，但是数据行不是。先在来看如下查询
```sql
mysql> SELECT lname FROM testhash WHERE fname ='Peter';
```
MySQL先计算'Peter'的哈希值，并使用该值寻找对应的记录指针。因为f('Peter')=8784,所以MySQL在索引中查找8784，可以找到指向第3行的指针，最后异步是比较第三行的值是否为'Peter',以确保就是要查找的行。因为索引自身只需要存储对应的哈希值，所以索引的结构十分紧凑，这也让哈希索引查找的速度非常快。然而，哈希索引也有它的限制:
1.哈希索引只包含哈希值和行指针，而不存储字段值，所以不能使用索引中的值来避免读取行。不过，访问内存中的行的速度很快，所以大部分情况下这一点对性能的影响并不明显
2.哈希索引数据并不是按照索引值顺序存储的，所以也就无法用于排序
3.哈希索引也不支持部分索引列匹配查找，因为哈希索引始终是使用索引列的全部内容来计算哈希值的。例如，在数据列(A,B)上建立哈希索引，如果查询只有数据列A,则无法使用该索引
4.哈希索引只支持等值比较查询，包括=、IN()、<=>(注意<>和<=>是不同的操作)。也不支持任何范围查询，例如WHERE price >100
5.访问哈希索引的数据非常快，除非有很多哈希冲突(不同的索引列值却有相同的哈希值)。当出现哈希冲突的时候，存储引擎必须遍历链表中所有的行指针，主键进行比较，直到找出所有符合条件的行
6.如果哈希冲突很多的化，一些索引维护操作的代价也会很高。例如，如果在某个选择性很低(哈希冲突很多)的列上建立哈希索引，那么当从表中删除一行时，存储引擎需要遍历对哈希值的链表中的每一行，找到并删除对应行的引用，冲突越多，代价越大。因为这些限制，哈希索引只适用于某些特定的场合。而一旦适合哈希索引，则它带来的的性能提升将非常显著。举个例子，在数据仓库应用中有一种经典的"星型"schema。需要关联很多表，哈希索引就非常适合查找表的需求。除了Memory引擎外，NDB集群引擎也支持唯一哈希索引，且在NDB集群引擎中作用非常特殊。
InnoDB引擎有一个特殊的功能叫作"自适应哈希索引(Adaptive Hash Index)"。当InnoDB注意到某些索引值被使用得非常频繁时，它会在内存中基于B-Tree之上再创建一个哈希索引，这样就让B-Tree索引也具有哈希索引的一些优点，比如快速的哈希查找。这是一个完全自动的、内部的行为，用户无法控制或者配置，不过有必要，完全可以关闭该功能。

空间数据索引(R-Tree)
MyISAM表支持空间索引，可以用作地理数据存储。和B-Tree索引不同，这类索引无须前缀查询。空间索引会从所有维度来索引数据。查询时，可以有效地使用任意维度来组合查询。必须使用MySQL的GIS相关函数如MBRCONTAINS()等来维护数据。MySQL的GIS支持并不完善，所以大部分人都不会使用这个特性。开源关系数据库系统中对GIS的解决方案做得比较好的是PostgreSQL的PostGIS.

全文索引
全文索引是一种特殊类型的索引，它查找的是文本中的关键词，而不是直接比较索引中的值。全文搜索和其他几类索引的匹配方式完全不一样。它有许多需要注意的细节，如停用词、词干和复数、布尔搜索等。全文索引更类似于搜索引擎作得事情，而不是简单的WHERE条件匹配。
在相同的列上同时创建全文索引和基于值得B-Tree索引不会有冲突，全文索引适用于MATCH AGAINST操作，而不是普通得WHERE条件操作

索引是最好的解决方案吗？
索引并不总是最好的工具。总的来说，只有当索引帮助存储引擎快速查找到记录带来的好处大于其带来的额外工作时，索引才是有效地。对于非常小的表，大部分情况下简单的全表扫描更高效。对于中到大型的表，索引就非常有效。但对于大型的表，建立和使用索引的代价将随之增长。这种情况下，则需要一种技术可以直接区分出查询需要的一组数据，而不是一条记录一条记录地匹配。例如可以使用分区技术。如果表的数量特别多，可以建立一个元数据信息表，用来查询需要用到的某些特性。例如执行那些需要聚合多个应用分布在多个表的数据的查询，则需要记录"哪个用户的信息存储在哪个表中"的元数据，这样在查询时就可以直接忽略那些不包含指定用户信息的表。对于大型系统，这是一个常用的技巧，事实上，Infobright就是使用类似的实现。对于TB级别的数据，定位单条记录的意义不大，所以经常会使用块级别元数据技术来替代索引

独立的列
我们通常会看到一些查询不当地使用索引，或者使得MySQL无法使用已有的索引。如果查询中的列不是独立的，则MySQL就不会使用索引。"独立的列"是指索引不能是表达式的一部分，也不能是函数的参数。例如，下面这个查询无法使用actor_id列的索引:
```sql
mysql> SELECT actor_id FROM actor WHERE actor_id + 1 =5;
```
凭肉眼很容易看出WHERE中的表达式其实等价于actor_id=4,但是MySQL无法自动解析这个方程式。这完全是用户行为。我们应该养成简化WHERE条件的习惯，始终将索引列单独放在比较符号的一侧。下面是另一个常见的错误:
```sql
mysql> SELECT .... WHERE TO_DAYS(CURRENT_DATE) - TO_DAYS(date_col) <= 10;
```

前缀索引和索引选择性
有时候需要索引很长的字符列，这会让索引变得大且慢。一个策略是前面提到过的模拟哈希索引。但有时候这样做还不够，还可以做些什么呢？
通常可以索引开始的部分字符，这样可以大大节约索引空间，从而提高索引效率。但这样也会降低索引的选择姓。索引的选择性是指，不重复的所引致(也成为技术，cardinality)和数据表的记录总数(#T)的比值。范围从1/#T到1之间。索引的选择性越高则查询效率越高，因为选择性高的索引可以让MySQL在查找时过滤掉更多的行。唯一索引的选择性是1，这是最好的索引选择性，性能也是最好的。

一般情况下某个列前缀的选择性也是足够高的，足以满足查询性能。对于BLOB、TEXT或者很长的VARCHAR类型的列，必须使用前缀索引，因为MySQL不允许索引这些列的完整长度。诀窍在于要选择足够长的前缀以保证较高的选择性，同时又不能太长(以便节约空间)。前缀应该足够长，以使得前缀索引的选择性接近于索引整个列。换句话说，前缀的"技术"应该接近于完整列的"基数"。为了决定前缀的合适长度，需要找到最常见的值得列表，然后和最常见得前缀列表进行比较。(MySQL Sakila官方链接http://downloads.mysql.com/docs/sakila-db.zip)大家可以下载下来导入进去。这里从表city中生成一个示例表，这样就有足够得数据进行演示：
```sql
use sakila;
CREATE TABLE city_demo(city VARCHAR(50) NOT NULL);

INSERT INTO city_demo(city) SELECT city FROM city;

INSERT INTO city_demo(city) SELECT city FROM city_demo;# 执行五次

UPDATE city_demo SET city = (SELECT city FROM city ORDER BY RAND() LIMIT 1);
```
现在我们有了示例数据集。数据分布当然不是真实得分布；因为我们使用了RAND().所以你的结果会与此不同，但对这个例子说这并不重要。首先，我们找到最常见的城市列表:
```sql
mysql> SELECT COUNT(*) AS cnt,city FROM city_demo GROUP BY city ORDER BY cnt DESC LIMIT 10;
+-----+-------------+
| cnt | city        |
+-----+-------------+
|  64 | London      |
|  50 | Bagé        |
|  49 | Brockton    |
|  48 | Soshanguve  |
|  47 | Bucuresti   |
|  47 | El Alto     |
|  47 | Balašiha    |
|  46 | Osmaniye    |
|  46 | Arecibo     |
|  45 | Santo André |
+-----+-------------+
10 rows in set (0.09 sec)
```
注意到，上面每隔值都出现了45~64次。现在查找结果最频繁出现的城市前缀，先从前3个前缀字母开始:

多列索引
很多人对多列索引的理解都不够。一个常见的错误就是，为每个列创建独立的索引，或者按照错误的顺序创建多列索引。先来看第一个问题，为每个列创建独立的索引，从SHOW CREATE TABLE总很容易看到这种情况:
```sql
CREATE TABLE t (
c1 INT,
c2 INT ,
c3 INT,
KEY(c1),
KEY(c2),
KEY(c3)
);
```
这种索引策略，一般是由于人们听到一些专家诸如"把WHERE条件里面的列都建上索引"这样模糊的建议导致的.实际上这个建议是非常错误的。这样一来最好的情况也只能是一星索引，其性能必去真正最优的索引可能差几个数量级。有时如果无法设计一个三星索引，那么不如忽略掉WHERE子句，集中精力优化索引列的顺序，或者创建一个全覆盖索引。在多个列上建立独立的单列索引大部分情况下并不能提高MySQL的查询性能。MySQL5.0和更新版本引入了一种"索引合并"(index merge)的策略，一定程度上可以使用表上的多个单列索引来定位指定的行。更早版本的MySQL只能使用其中某一个单列索引，然而这种情况没有哪一个独立的单列索引是非常有效的。例如，表fime_actor在字典fim_id和actor_id上各有一个单列索引。但对于下面的这个查询WHERE条件，这两个单列索引都不是好的选择:
```sql
CREATE TABLE t (
c1 INT,
c2 INT ,
c3 INT,
KEY(c1),
KEY(c2),
KEY(c3)
);
```
在老的MySQL版本中，MySQL对这个查询会使用全表扫描。除非改写成如下的两个查询UNION的方式:
```sql
mysql>  SELECT film_id,actor_id FROM film_actor WHERE actor_id = 1
UNION ALL
SELECT film_id,actor_id FROM film_actor WHERE film_id =1 AND actor_id <>1;
```
但在MySQL5.0和更新的版本中，查询能够同时使用这两个单列索引进行扫描，并将结果进行合并。这种算法有三个变种:OR条件的联合(union),AND条件的相交(intersection),组合前两种情况的联合及相交。下面的查询就是使用了两个索引扫描的联合，通过EXPLAIN中的Extra列可以看到这点:
```sql
mysql> EXPLAIN SELECT film_id,actor_id FROM film_actor WHERE actor_id = 1 OR film_id =1\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: film_actor
   partitions: NULL
         type: index_merge
possible_keys: PRIMARY,idx_fk_film_id
          key: PRIMARY,idx_fk_film_id
      key_len: 2,2
          ref: NULL
         rows: 29
     filtered: 100.00
        Extra: Using union(PRIMARY,idx_fk_film_id); Using where
1 row in set, 1 warning (0.00 sec)
```
MySQL会使用这类基数优化复杂查询，所以在某些语句的Extra列中还可以看到嵌套操作。

选择合适的索引列顺序
我们遇到最容易引起困惑的问题就是索引列的顺序。正确的顺序依赖于使用该索引的查询，并且同时需要考虑如何更好地满足排序和分组的需要(以B-Tree索引为例)。在一个多列B-Tree索引中，索引列的顺序意味着索引首先按照最左列进行排序，其次是第二列，等等。所以索引可以按照升序或者降序进行扫描，以满足精确符合列顺序的ORDER BY 、GROUP BY和DISTINCT等子句的查询需求。所以多列索引的列顺序至关重要。在Lahdenmaki和Leach的"三星索引"系统中，列顺序也决定了一个索引是否能够成为一个真正的"三星索引".对于如何选择索引的列顺序有一个经验法则:将选择性最高的列放到索引最前列。这个建议有用吗？在某些场景可能有帮助，但通常不如避免随机IO和排序那么重要，考虑问题需要更全面(场景不同则选择不同，没有一个放之四海而皆准的法则。这里只是说明，这个经验法则可能没有你想象的重要)。当不需要考虑排序和分组时，将选择性最高的列放在前面通常是很好的，这时候索引的作用只是用于优化WHERE条件的查找。在这种情况下，这样设计的索引确实能够最快地过滤出需要的行，对于在WHERE子句中只适用了索引部分前缀列的查询来说选择性也更高。然而，性能不只是依赖于所有索引列的选择性(整体基数)，也和查询条件的具体值有关，也就是和值的分布有关，可能需要根据那些运行频率最高的查询来调整索引列的顺序，让这种情况下索引的选择性最高。以下面的查询为例:
```sql
mysql> SELECT * FROM payment WHERE staff_id = 2 AND customer_id =584;
```
是应该创建一个(staff_id,customer_id)索引还是应该颠倒一下顺序?可以跑一些查询来确定在这个表中值的分布情况，并确定哪个列的选择性更高。先用下面的查询预测一下，看看各个WHERE条件的分支对应的数据基数有多大:
```sql
*************************** 1. row ***************************
      SUM(staff_id=2): 7990
SUM(customer_id =584): 30
```
根据前面的经验法则，应该将索引列customer_id放到前面，因为对应条件值的customer_id数量更小。我们再来看看对于这个customer_id的条件值，对应的staff_id列的选择性如何:
```sql
mysql> SELECT SUM(staff_id=2) FROM payment WHERE customer_id=584\G
*************************** 1. row ***************************
SUM(staff_id=2): 17
```
这样做有一个地方需要注意，查询的结果非常依赖于选定的值。如果按照上述办法优化，可能对其他一些条件值的查询不公平，服务器的整体性能可能变得更糟，或者其他某些查询的运行变得不如预期。如果是诸如pt-query-digest这样的工具的报告中提取"最差"查询，那么再按上述办法选定的索引顺序往往是非常高效的。如果没有类似的具体查询来运行，那么最好还是按照经验法则来做，因为经验法则考虑的是全局基数和选择性，而不是某个具体查询:
```sql
mysql> SELECT COUNT(DISTINCT staff_id)/COUNT(*) AS staff_id_selectivity,
    -> COUNT(DISTINCT customer_id)/COUNT(*) AS customer_id_selectivity,
    -> COUNT(*) FROM payment\G
*************************** 1. row ***************************
   staff_id_selectivity: 0.0001
customer_id_selectivity: 0.0373
               COUNT(*): 16044
```
customer_id的选择性更高，所以答案是将其作为索引列的第一列:
```sql
mysql> ALTER TABLE payment ADD KEY(customer_id,staff_id);
```

聚簇索引
聚簇索引并不是一种单独的索引类型，而是一种数据存储方式。具体的细节依赖于其实现方式但InnoDB得聚簇索引实际上在同一个结构中保存了B-Tree索引和数据行。当表有聚簇索引时，它的数据行实际上存放在索引的叶子页(leaf page)中。术语"聚簇"表示数据行和相邻的键值紧凑地存储在一起。因为无法同时把数据行存放在两个不同的地方，所以一个表只能有一个聚簇索引(不过，覆盖索引可以模拟多个聚簇索引的情况)。因为是存储引擎负责实现索引，因此不是所有的存储引擎都支持聚簇索引。主要关注InnoDB.如图展示了聚簇索引中的记录是如何存放的。注意到，叶子页包含了行的全部数据，但是节点页只包含了索引列。该图中，索引包含的是整数值。
一些数据库服务器允许选择哪个索引作为聚簇索引，但是目前市场上，还没有任何一个MySQL内建的存储引擎支持这一点。InnoDB将通过主键聚集数据，这也就是说上图中的"被索引的列"就是主键列。如果没有定义主键，InnoDB会选择一个唯一的非空索引代替。如果没有这样的索引，InnoDB会隐式定义一个主键来作为聚簇索引，InnoDB只聚集在同一个页面中的记录。包含相邻键值的页面可能会相距甚远。
聚簇索引可能对性能有帮助，但也可能导致严重的性能问题。所以需要仔细地考虑聚簇索引，尤其是将表的存储引擎从InnoDB改成其他引擎的时候(反过来也一样)。聚集的数据有一些重要的优点:
1.可以把相关数据保存在一起。例如实现电子邮箱时，可以根据用户ID来聚集数据，这样只需要从磁盘读取少数的数据也就能获取某个用户的全部邮件。如果没有使用聚簇索引，则每封邮件都可能导致一次磁盘IO
2.数据访问更快。聚簇索引将索引和数据保存在同一个B-Tree中，因此聚簇索引中获取数据通常比在非聚簇索引中查找要快。
3.使用覆盖索引扫描的查询可以直接使用叶节点中的主键值
如果在设计表和查询时能充分利用上面的优点，那就能极大地提升性能。同时，聚簇索引也有一些缺点:
1.聚簇数据最大限度地提高了IO密集型应用的性能，但如果数据全部都存放在内存中，则访问的顺序就没那么重要了，聚簇索引也就没什么优势了
2.插入速度严重依赖于插入顺序。按照主键的顺序插入是加载数据到InnoDB表中速度最快的方式。但如果不是按照主键顺序加载数据，那么在加载完成后最好使用OPTIMIZE TABLE命令重新组织一下表
3.更新聚簇索引列的代价很高，因为会强制InnoDB将每个被更新的行移动到新的位置
4.基于聚簇索引的表在插入新行，或者主键被更新导致需要移动行的时候，可能面临"页分裂(page split)"的问题。当行的主键值要求必须将这一行插入到某个已满的页中时，存储引擎会将该页分裂成两个页面来容纳该行，这就是一次页分裂操作。也分裂会导致表占用更多的磁盘空间
5.聚簇索引可能导致全表扫描变慢，尤其是行比较稀疏，或者由于页分裂导致数据存储不连续的时候
6.二级索引(非聚簇索引)可能比想象的要更大，因为在二级索引的叶子节点包含了引用行的主键列
7.二级索引访问需要两次索引查找，而不是一次

最后一点可能让人有些疑惑，为什么二级索引需要两次索引查找?答案在于二级索引中保存的"行指针"的实质。要记住，二级索引叶子节点保存的不是指向行的物理位置的指针，而是行的主键值。这意味着通过二级索引查找行，存储引擎需要找到二级索引的叶子节点获得对应的主键值，然后根据这个值去聚簇索引中查找到对应的行。这里做了重复的工作:两次B-Tree查找而不是一次(顺便提一下，并不是所有的非聚簇索引都能做到一次索引查询就找到行。当行更新的时候可能无法存储在原来的位置，这会导致表中出现行的碎片花或者移动行并在原位置保存"向前指针"。这两种情况都会导致查找行时需要更多的工作)，对于InnoDB，自适应哈希索引能够减少这样的重复工作

覆盖索引
通常大家都会根据查询的WHERE条件来创建合适的索引，不过这只是索引优化的一个方面。设计优秀的索引应该考虑到整个查询，而不单单是WHERE条件部分。索引确实是一种查找数据的高效方式，但是MySQL也可以使用索引来直接获取列的数据，这样就不再需要读取数据行。如果索引的叶子几点钟已经包含要查询的数据，那么还有什么必要再回表查询呢？如果一个索引包含(或者说覆盖)所有需要查询的字段的值，我们就称之为"覆盖索引"。
覆盖索引是非常有用的工具，能够极大地提高性能。考虑一下如果查询只需要扫描索引而无须回表，会带来多少好处:
1.索引条目通常远小于数据行大小，所以如果只需要读取索引，那MySQL就会极大地减少数据访问量。这对缓存的负载非常重要，因为这种情况下相应时间大部分花费在数据拷贝上。覆盖索引对于IO密集型的应用也有帮助，因为索引比数据更小，更容易全部放入内存中(这对于MyISAM尤其正确，因为MyISAM能压缩索引以变得更小)
2.因为索引是按照列值顺序存储的(至少在单个页内是如此)，所以对于IO密集型的范围查询会比随机从磁盘读取每一行数据的IO要少得多。对于某些存储引擎，例如MyISAM和Percona XtraDB，甚至可以通过OPTIMIZE命令使得索引完全顺序排列，这让简单的范围查询能使用完全的顺序的索引访问
3.一些存储引擎如MyISAM在内存中只缓存索引，数据则依赖于操作系统缓存，因此要访问数据需要一次系统调用。这可能会导致严重的性能问题，尤其是那些系统调用占了数据访问中的最大开销的场景
4.由于InnoDB的聚簇索引，覆盖索引对InnoDB表特别有用。InnoDB的二级索引在叶子节点中保存了行的主键值，所以如果二级主键能够覆盖查询，则可以避免对主键索引的二次查询

在所有这些场景中，在索引中满足查询的成本一般要比查询行要小得多。不是所有类型的索引都可以成为覆盖索引。覆盖索引必须要存储索引列的值，而哈希索引、空间索引和全文索引等都不存储索引列的值，所以MySQL只能使用B-Tree索引做覆盖索引。另外，不同的存储引擎实现覆盖索引的方式也不同，而且不是所有的引擎都支持覆盖索引(如Memory存储引擎就不支持覆盖索引)，当发起一个被索引覆盖的查询(也叫做索引覆盖查询时)，在EXPLAIN的Extra列可以看到"Using index"的信息(很容易把Extra列的"Using index"和type列的"index"搞混淆。其实这两者完全不同，type列和覆盖索引毫无关系:它只是表示这个查询访问数据的方式，或者说是MySQL查找行的方式，MySQL手册中称之为连接方式(join type))。例如，表sakila.inventory有一个多列索引(store_id,film_id).MySQL如果只需访问这两列，就可以使用这个索引做索引覆盖，如下所示
```sql
mysql> EXPLAIN SELECT store_id,film_id FROM sakila.inventory\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: inventory
   partitions: NULL
         type: index
possible_keys: NULL
          key: idx_store_id_film_id
      key_len: 3
          ref: NULL
         rows: 4581
     filtered: 100.00
        Extra: Using index
1 row in set, 1 warning (0.00 sec)
```
索引覆盖查询还有很多陷阱可能会导致无法实现优化。MySQL查询优化器会在执行查询前判断是否有一个索引能进行覆盖。假设索引覆盖了WHERE条件中的字段，但是不是整个查询涉及的字段。如果条件为假(false)，MySQL5.5和更早的版本也总是会回表获取数据行，尽管并不需要这一行且最终会被过滤掉。
来看看为什么会发生这样的情况，以及如何重写查询以解决该问题。从下面的查询开始

使用索引扫描来做排序。
MySQL有两种方式可以生成有序的结果:通过排序操作；或者按索引顺序扫描(MySQL有两种排序算法)；如果EXPLAIN出来的type列的值为"index"，则说明使用了索引扫描来做排序(不要和Extra列的"Using index")搞混淆了。扫描索引本身是很快的。因为只需要从一条索引记录移动到紧接着的下一条记录。但如果索引不能覆盖查询所需的全部列，那就不得不每扫描一条索引记录就都回表查询一次对应的行。这基本上都是随机IO,因此按索引顺序读取数据的速度通常要比顺序地全表扫描慢，尤其是在IO密集型地工作负载时。MySQL可以使用同一个索引即满足排序，又用于查找行。因此，如果可能，设计索引时应该尽可能地同时满足这两种任务，这样是最好地。只有当索引的列顺序和ORDER BY子句的顺序完全一致，并i企鹅所有列的排序方向(倒序或正序)都一样时，MySQL才能够使用索引来对结果排序。如果查询需要关联多张表，则只有当ORDER BY子句引用的字段全部为第一个表时，才能使用索引做排序。ORDER BY子句和查找型查询的限制是一样的:需要满足索引的最左前缀的要求，否则MySQL都需要执行排序操作，而无法利用索引排序。有一种情况ORDER BY子句可以不满足索引的最左前缀的要求，就是前导列为常量的时候。如果WHERE子句或者JOIN子句中对这些列指定了常量,就可以"弥补"索引的不足。
例如，Sakila示例数据库的表rental在列(rental_date,inventory_id,customer_id)上有名为rental_date的索引.(rental_date,inventory_id,customer_id):
```sql
CREATE TABLE `rental` (
....
  PRIMARY KEY (`rental_id`),
  UNIQUE KEY `rental_date` (`rental_date`,`inventory_id`,`customer_id`),
  KEY `idx_fk_inventory_id` (`inventory_id`),
  KEY `idx_fk_customer_id` (`customer_id`),
  KEY `idx_fk_staff_id` (`staff_id`),
  ....
);
```
MySQL可以使用rental_date索引为下面的查询做排序，从EXPLAIN张可以看到没有出现文件排序(filesort)操作(MySQL这里称其为文件排序(filesort)，其实并不一定使用磁盘文件):
```sql
mysql> EXPLAIN SELECT rental_id, staff_id FROM sakila.rental WHERE rental_date = '2005-05-25' ORDER BY inventory_id,customer_id\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: rental
   partitions: NULL
         type: ref
possible_keys: rental_date
          key: rental_date
      key_len: 5
          ref: const
         rows: 1
     filtered: 100.00
        Extra: Using index condition
1 row in set, 1 warning (0.00 sec)
```
即使ORDER BY 子句不满足索引的最左前缀的要求，也可以用于查询排序，这是因为索引的第一列被指定为一个常数。还有更多可以使用索引做排序的查询示例。下面这个查询可以利用索引排序，是因为查询为索引的第一列提供了常量条件，而使用第二列进行排序，将两列组合在一起，就形成了索引的最左前缀:
```sql
.... WHERE rental_date = '2005-05-25' ORDER BY inventory_id DESC;
```
下面这个查询也没问题，因为ORDER BY 使用的两列就是索引的最左前缀:
```sql
... WHERE rental_date > '2005-05-25' ORDER BY rental_date,inventory_id;
```

压缩(前缀压缩)索引
MyISAM使用前缀压缩来减少索引的大小，从而让更多的索引可以放入内存中，这在某些情况下能极大地提高性能。默认只压缩字符串，但通过参数设置也可以对整数做压缩。MyISAM压缩每个索引块的方法是，先完全保存索引块中的第一个值，然后将其他值和第一个值进行比较得到相同前缀的字节数和剩余不同后缀部分，把这部分存储起来即可。例如，索引块中的第一个值是"perform"，第二个值是"performance"，那么第二个值得前缀压缩后存储得是类似"7,ance"这样的形式。MyISAM对行指针也采用类似的压缩方式。
压缩块使用更少的空间，代价是某些操作可能更慢，因为每个值得压缩前缀都依赖前面的值，所以MyISAM查找时无法在索引块使用二分查找而只能从头开始扫描。正序的扫描速度还不错，但是如果时倒序扫描——例如ORDER BY DESC——就不是很好了，所有在块中查找某一行的操作平均都需要扫描半个索引块。
测试表明，对于CPU密集型应用，因为扫描需要随机查找，压缩索引使得MyISAM在索引查找上要慢好几倍。压缩索引的倒序扫描就更慢了。压缩索引需要在CPU内存资源与磁盘之间做权衡。压缩索引可能只需要十分之一大小的磁盘空间，如果时IO密集型应用，对某些查询带来的好处会比成本多很多。

冗余和重复索引
MySQL允许在相同列上创建多个索引，无论时有意的还是无意的。MySQL需要单独维护重复的索引，并且优化器在优化查询的时候也需要逐个地进行考虑，这会影响性能。重复索引是指在相同的列上按照相同的顺序创建的相同类型的索引，应该避免这样创建重复索引，发现以后也应该立即移除。有时会在不经意间创建了重复索引，例如下面的代码:
```sql
CREATE TABLE test (
ID INT NOT NULL PRIMARY KEY,
A INT NOT NULL,
B INT NOT NULL,
UNIQUE(ID),
INDEX(ID)
) ENGINE=InnoDB;
```
一个经验不足的用户可能是想创建一个主键，先加上唯一限制，然后再加上索引以供查询使用。事实上，MySQL的唯一限制和主键限制都是通过索引实现的，因此，上面的写发实际上在相同的列上创建了三个重复索引。通常并没有理由这样做，除非是在同一列上创建不同类型的索引来满足不同的查询需求(如果索引类型不同，并不算是重复索引。例如经常有很好的理由创建KEY(col)和FULLTEXTKEY(col)两种索引)。冗余索引和重复索引有一些不同。如果创建了索引(A,B)，再创建索引(A)就是冗余索引，因为这只是前一个索引的前缀索引。因此索引(A，B)也可以当作索引(A)来使用(这种冗余索引只是对B-Tree索引来说的)。但是如果再创建索引(B,A)则不是冗余索引，索引(B)也不是，因为B不是索引(A,B)的最左前缀列。另外，其他不同类型的索引(例如哈希索引或者全文索引)也不会是B-Tree索引的冗余，而无论覆盖的索引列是什么。冗余索引通常发生在为表添加新索引的时候。例如，有人可能会增加一个新的索引(A,B)而不是扩展已有的索引(A)。还有一种情况是将一个索引扩展为(A,ID)，其中ID是主键，对于InnoDB来说主键列已经包含在二级索引中了，所以这也是冗余的。大多数情况下都不需要冗余索引，应该尽量扩展已有的索引而不是创建新索引。但有时候处于性能方面的考虑需要冗余索引，因为扩展已有的索引会导致其变得太大，从而影响其他使用该索引的查询的性能。
例如，如果在整数列上有一个索引，现在需要额外增加一个很长的VARCHAR列来扩展该索引，那性能可能会急剧下降。特别是有查询把这个索引当作覆盖索引，或者这是MyISAM表并且有很多范围查询(由于MyISAM的前缀压缩)的时候。例如前面提到的userinfo表，这个表有1 000 000行，对每个state_id值大概有20 000条记录。在state_id列有一个索引对下面的查询有用，假设查询名为Q1:
```sql
mysql> SELECT COUNT(*) FROM user_info WHERE state_id=5;
```
一个简单的测试表明该查询的执行速度大概是每秒115次(QPS).还有一个相关查询需要检索几个列的值，而不是只统计行数，假设名为Q2:
```sql
mysql> SELECT state_id,city,address FROM userinfo WHERE state_id =5;
```
对于这个查询，测试结果QPS小于10(这里使用了全内存的案例，如果表逐渐变大，导致工作负载变成IO密集型时，性能测试结果差距会更大。对于COUNT()查询。覆盖索引性能提升100倍也是很有可能的)。提升该查询性能的最简单办法就是扩展索引为(state_id,city,address)，让索引能覆盖查询:
```sql
mysql> ALTER TABLE userinfo DROP KEY state_id, ADD KEY state_id2 (state_id,city,address);
```
索引扩展后，Q2运行得更快了，但是Q1却变慢了。如果我们想让两个查询都变快，就需要两个索引，尽管这样一来原来的单列索引是冗余的了。如表所示，显示这两个查询在不同的索引策略下的详细结果，分别使用MyISAM和InnoDB存储引擎。注意到只有state_id_2索引时，InnoDB引擎上的查询Q1的性能下降并不明显，这是因为InnoDB没有使用索引压缩。有两个索引的缺点时索引成本更高。如表所示显示了向表中插入100万行数据所需要的时间

未使用的索引。
除了冗余索引和重复素银，可能还会有一些服务器永远不同的索引。这样的索引完全是累赘，建议考虑删除(有些索引的功能相当于唯一约束，虽然该索引一致没有被查询使用，却可能是用于避免产生重复数据的)有两个工具可以帮助定位未使用的索引。最简单有效的办法是在Percona Server或者MariaDB中线打开userstates服务器变量(默认是关闭的)，然后让服务器正常运行一段时间，再通过查询INFORMATION_SCHEMA.INDEX_STATISTICS就能查到每个索引的使用频率。另外，还可以使用Percona Toolkit中的pt-index-usage，该工具可以读取查询日志，并对日志中的每条查询进行EXPLAIN操作，然后打印出关于索引和查询的报告。这个工具不仅可以找出哪些索引是未使用的，还可以了解查询的执行计划——例如在某些情况有些类似的查询的执行方式不一样，这可以帮助定位到哪些偶尔服务质量差的查询，优化它们以得到一致的性能表现。该工具也可以将结果写入到MySQL的表中，方便查询结果

索引和锁。
索引可以让查询锁定更少的行。如果你的查询从不访问那些不需要的行，那么就会锁定更少的行，从两个方面来看这对性能都有好处。首先，虽然InnoDB的行锁效率很高，内存使用也很少，但是锁定行的时候仍然会带来额外开销，其次，锁定超过需要的行会增加锁争用并减少并发性。InnoDB只有在访问行的时候才会对其加锁，而索引能够减少InnoDB访问的行数，从而减少锁的数量。但这只有当InnoDB在存储引擎层能够过滤掉所有不需要的行时才有效。如果索引无法过滤掉无效的行，那么在InnoDB检索到数据并返回给服务器层以后，MySQL服务器才能应用WHERE子句。这是已经无法避免锁定行了；InnoDB已经锁住了这些行，到适当的时候才会释放。在MySQL5.1和更新的版本中，InnoDB可以在服务器器端过滤掉行后就释放锁，但是在早期的MySQL版本中，InnoDB只有在事务提交后才能释放锁。通过下面的例子再次使用数据库Sakila很好地解释了这些情况：
```sql
mysql> SET autocommit=0;
Query OK, 0 rows affected (0.00 sec)

mysql> BEGIN;
Query OK, 0 rows affected (0.01 sec)

mysql> SELECT actor_id FROM sakila.actor WHERE actor_id < 5 AND actor_id <> 1 FOR UPDATE;
+----------+
| actor_id |
+----------+
|        2 |
|        3 |
|        4 |
+----------+
```
这条查询仅仅会返回2~4之间的行，但是实际上获取了1~4之间的行的排他锁。InnoDB会锁住第1行，这是因为MySQL为该查询选择的执行计划是索引范围扫描:
```sql
mysql> EXPLAIN SELECT actor_id FROM sakila.actor WHERE actor_id < 5 AND actor_id <> 1 FOR UPDATE;
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+--------------------------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref  | rows | filtered | Extra                    |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+--------------------------+
|  1 | SIMPLE      | actor | NULL       | range | PRIMARY       | PRIMARY | 2       | NULL |    4 |   100.00 | Using where; Using index |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+--------------------------+
1 row in set, 1 warning (0.00 sec)
```
换句话说，底层存储引擎的操作是"从索引的开头开始获取满足条件acotr_id < 5"的记录，服务器并没有告诉InnoDB可以过滤第1行的WHERE条件。注意到EXPLAIN的Extra列出现了"Using where"，这表示MySQL服务器将存储以前宁返回行以后再应用WHERE过滤条件。
下面的第二个查询就能证明第1行确实已经被锁定，尽管第一个查询的结果中并没有这个第1行。保持第一个链接打开，然后开启第二个连接并执行如下查询:
```sql
mysql> SET autocommit=0;
Query OK, 0 rows affected (18.96 sec)

mysql> BEGIN;
Query OK, 0 rows affected (0.02 sec)

mysql> SELECT actor_id FROM sakila.actor WHERE actor_id =1 FOR UPDATE;
1205 - Lock wait timeout exceeded; try restarting transaction
```
这个查询将会挂起，直到第一个事务释放第一行的锁。这个行为对于基于语句的复制的正常运行来说是必要的。就像这个例子显示的，即使使用了索引，InnoDB也可能锁住一些不需要的数据。如果不能使用索引查找和锁定行的问题可能会更糟糕，MySQL会做全表扫描并锁住所有的行，而不管是不是需要。关于InnoDB、索引和锁有一些很少有人直到的细节:InnoDB在二级索引上使用共享(读)锁，但访问主键索引需要排他(写)锁。这消除了使用覆盖索引的可能性，并且使得SELECT FOR UPDATE比LOCK IN SHARE MODE或非锁定查询要慢得多

支持多种过滤条件
现在需要看看那些列拥有不同的取值，那些列再WHERE子句中出现得最频繁。再有更多不同值得列上创建索引的选择性会更好。一般来说这样做都是对的，因为可以让MySQL更有效地过滤掉不需要的行。country列的选择性通常不高，但可能很多查询都会用到。sex列的选择性肯定很低，但也会再很多查询中用到。所以考虑到使用的频率，还是建议在创建不同的组合索引的时候将(sex,country)列作为前缀。根据传统的经验不是说不应该在选择性低的列上创建索引的吗？那为什么这里将两个选择性都很低的字段作为所以你的前缀列?我们的脑子坏了？
我们的脑子当然没坏。这么做有两个理由:第一点，如前所述几乎所有的查询都会用到sex列。前面曾提到，几乎每一个查询都会用到sex列，甚至会把网站设计成每次都只能按某一种性别搜索用户。更重要的是，索引中加上这一列也没有坏处，即使查询没用使用sex列也可以通过一些"诀窍"绕过。
这个"诀窍"就是:如果某个查询不限制性别，那么可以通过在查询条件中新增AND SEX IN('m','f')来让MySQL选择该索引。这样写并不会过滤任何行，和没有这个条件时返回的结果相同。但是必须加上这个列的条件，MySQL才能够匹配索引的最左前缀。这个"诀窍"在这类场景中非常有效，但如果列有太多不同的值，就会让IN()列表太长，这样做就不行了。这个案例显示了一个基本原则:考虑表上所有的选项。当设计索引时，不要只为现有的查询考虑需要哪些索引，还需要考虑对查询进行优化。如果发现某些查询需要创建新索引，但是这个索引又会降低另一些查询的效率，那么应该想一下是否能优化原来的查询。应该同时优化查询和索引以找到最佳的平衡，而不是闭门造车去设计最完美的索引。

接下来，需要考虑其他场景WHERE条件的组合，并需要了解哪些组合在没有合适索引的情况下会很慢。(sex,country,age)上的索引就是一个明显的选择，另外很有可能还需要(sex,country,region,age)和(sex,country,region,city,age)这样的组合个索引。这样就会需要大量的索引。如果想尽可能地重用索引而不是建立大量的组合索引，可以使用前面提到的IN()的技巧来避免同时需要(sex,country,age)和(sex,country,region,age)的索引。如果没有指定这个字段搜索，就需要定义一个全部国家列表，或者国家的全部地区列表，来确保索引前缀有同样的约束(组合所有国家、地区、性别将会是一个非常大的条件)

避免多个范围条件。
假设我们有一个last_online列并系统通过下面的查询显示在过去几周上线过的用户:
```sql
WHERE eye_color IN ('brown','blue','hazel')
AND hair_color IN('blackj','red','blonde','brown')
AND sex IN ('M','F')
AND last_online > DATE_SUB(NOW, INTERVAL 7 DAY)
AND age BETWEEN 18 AND 25
```
什么是范围条件?
从EXPLAIN的输出很难区分MySQL是要查询范围值还是查询列表值.EXPLAIN使用同样的词"range"来描述这两种情况.例如，从type列来看，MySQL会把下下面这种查询当作是"range"类型:
```sql
mysql> EXPLAIN SELECT actor_id FROM sakila.actor WHERE actor_id > 45\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: actor
   partitions: NULL
         type: range
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 2
          ref: NULL
         rows: 155
     filtered: 100.00
        Extra: Using where; Using index
1 row in set, 1 warning (0.00 sec)
```
但是下面这条查询呢？
```sql
mysql> EXPLAIN SELECT actor_id FROM sakila.actor WHERE actor_id IN(1,4,99)\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: actor
   partitions: NULL
         type: range
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 2
          ref: NULL
         rows: 3
     filtered: 100.00
        Extra: Using where; Using index
1 row in set, 1 warning (0.00 sec)
```
从EXPLAIN的结果是无法区分这两者的，但可以从值的范围和多个等于条件来得出不同。在我们看来，第二个查询就是多个等值条件查询的。我们不是挑剔:这两种访问效率是不同的。对于范围条件查询，MySQL无法再使用范围列后面的其他索引列了，但是对于"多个等值条件查询"则没有这个限制

优化排序.
最后要介绍的是排序。使用文件排序对小数据集是很快的，但如果一个查询匹配的结果有上百万行的话会怎样?例如如果WHERE子句只有sex列，如何排序？对于那些选择性非常低的列，可以增加一些特殊的索引来做排序。例如，可以创建(sex,rating)索引用于下面的查询:
```sql
mysql SELECT <cols>  FROM profiles WHERE sex= 'M'  ORDER BY rating LIMIT 10;
```
这个查询同时使用了ORDER BY 和LIMIT，如果没有索引的话会很慢。即使有索引，如果用户界面山需要翻页，并且翻页翻到比较靠后时查询也可能非常慢。下面这个查询就通过ORDER BY 和LIMIT偏移量的组合翻页到很后面的时候:
```sql
mysql> SELECT <cols> FROM profiles WHERE sex='M' ORDER BY rating LIMIT 1000000，10；
```
无论如何创建索引，这种查询都是个严重的问题，因为随者偏移量的增加，MySQL需要花费大量的时间来扫描需要丢弃的数据。反范式化、预先计算和缓存可能是解决这类查询的仅有策略。一个更好的办法是限制yoghurt能够翻页的数量，实际上这对用户体验的影响不大，因为用户很少会真正在乎搜索结果的第10 000页。优化这类索引的另一个比较好的策略是使用延迟关联，通过使用覆盖索引查询返回需要的主键，再根据这些主键关联源表获得需要的行。这可以减少MySQL扫描那些需要丢弃的行数。下面这个查询显示了如何高效地使用(sex,rating)索引进行排序和分页:
```sql
mysql> SELECT <cols> FROM profiles INNER JOIN(SELECT <primary key cols> FROM profiles WHERE x.sex ='M' ORDER BY rating LIMIT 1000000,10) AS x USING(<primary key cols>);
```

找到并修复损坏的表
表损坏(corruption)是很糟糕的事情。对于MyISAM存储引擎，表损坏通常是系统崩溃导致的。其他的引擎也会由于硬件问题、MySQL本身的缺陷或者操作系统的问题导致索引损坏。损坏的索引会导致查询返回错误的结果或者莫须有的主键冲突等问题，严重时甚至还会导致数据库的崩溃。如果你遇到了古怪的问题——例如一些不应该发生的错误——可以尝试运行CHECK TABLE来检查是否发生了表损坏(注意有些存储引擎不支持该命令；二有些引擎则支持以不同的选项来控制完全检查表的方式)。CHECK TABLE通常能够找出大多数的表和索引的错误。可以使用REPAIR TABLE命令来修复损坏的表，但同样不是所有的存储引擎都支持该命令。如果存储疫情不支持，也可通过一个不做任何操作(no-op)的ALTER操作来重建表，例如修改表的存储引擎为当前欸度引擎。下面是一个针对InnoDB表的例子：
```sql
mysql> ALTER TABLE actor ENGINE=INNODB;
```
此外，也可以使用一些存储引擎相关的离线工具，例如myisamchk;或者将数据导出一份，然后再冲洗内倒入。不过，如果损坏的是系统区域，或者是表的"行数据"区域，而不是索引，那么上面的办法就没有用了。在这种情况下，可以从备份中恢复表，或者尝试从损坏的数据文件中尽可能地恢复数据。如果InnoDB引擎的表出现了损坏，那么一定是发生了严重的错误，需要立刻调查一下原因。InnoDB一般不会出现损坏。InnoDB的设计保证了它并不容易被损坏。如果发生损坏，一般要么是数据库的硬件问题例如内存或者磁盘问题(有可能)，抑或是InnoDB本身的缺陷(不太可能)。常见的类似错误通常是由于尝试使用rsync备份InnoDB导致的。不存在什么查询能够让InnoDB表损坏，也不用担心暗处有"陷阱"。如果某条查询导致InnoDB数据的损坏，那一定是遇到了bug,而不是查询的问题。如果遇到数据损坏，最重要的是找出是什么导致了损坏，而不只是简单地修复，否则很有可能还会不断地损坏。可以通过设置innodb_force_recovery参数进入InnoDB地强制恢复模式来修复数据。另外，还可以使用开源地InnoDB数据恢复工具箱(InnoDB Data Recovery Toolkit)直接从InnoDB文件恢复出数据

更新索引统计信息
MySQL的查询优化器会通过两个API来了解存储引擎的索引值的分布信息，以决定如何使用索引。第一个API是recors_in_rage()，通过向存储引擎传入两个边界值获取在这个范围大概有多少条记录。对于某些存储引擎，该接口返回精确值，例如MyISAM；但对于另一些存储引擎则是一个估算值。例如InnoDB.第二个API是info()，该接口返回各种类型的数据，包括索引的基数(每个键值有多少条记录).如果存储引擎向优化器提供的扫描行数信息是不准确的数据，或者执行计划本身太复杂以致无法准确地获取各个阶段匹配地行数，那么优化器会使用索引统计信息来估算扫描行数。MySQL优化器使用地是基于成本的模型，而衡量成本的主要指标就是一个查询需要扫描多少行。如果表没有统计信息，或者统计信息不准确，优化器就很有可能做出错误的决定。可以通过运行ANALYZE TABLE来重新生成统计信息解决这个问题。每种存储引擎实现索引统计信息的方式不同，所以需要进行ANALYZE TABLE的频率也因不同的引擎而不同，每次运行的成本也不同:
1.Memory引擎根本存储索引统计信息
2.MyISAM将索引统计信息存储在磁盘中，ANALYZE TABLE需要进行一次全索引扫描来计算索引基数。在整个过程需要锁表
3.直到MySQL5.5版本，InnoDB也不在磁盘存储索引统计信息，而是通过随机的索引访问进行评估并将其存储在内存中

可以使用SHOW INDEX FROM命令来查看索引的基数(Cardinality)。例如:
```sql
mysql> SHOW INDEX FROM actor\G
*************************** 1. row ***************************
        Table: actor
   Non_unique: 0
     Key_name: PRIMARY
Seq_in_index: 1
  Column_name: actor_id
    Collation: A
  Cardinality: 200
     Sub_part: NULL
       Packed: NULL
         Null:
   Index_type: BTREE
      Comment:
Index_comment:
*************************** 2. row ***************************
        Table: actor
   Non_unique: 1
     Key_name: idx_actor_last_name
Seq_in_index: 1
  Column_name: last_name
    Collation: A
  Cardinality: 121
     Sub_part: NULL
       Packed: NULL
         Null:
   Index_type: BTREE
      Comment:
Index_comment:
2 rows in set (0.00 sec)
```
这个命令输出了很多关于索引的信息，在MySQL手册中对上面每个字段的含义都有详细的解释。这里需要特别提及的是索引列的基数(Cardinality)，其显示了存储引擎估算索引列有多少个不同的取值(离散程度)。在MySQL5.0和更新的版本中，还可以通过INFORMATION_SCHEMA.STATISTICS表很方便地查询到这些信息。例如基于INFORMATION_SCHEMA的表，可以编写一个查询给出当前选择性比较低的索引。需要注意的是，如果服务器上的库表非常多，则从这里获取元数据的速度可能会非常慢，而且会给MySQL带来额外的压力

减少索引和数据的碎片。
B-Tree索引可能会碎片化，这会降低查询的效率。碎片化的索引可能会以很差或者无序的方式存储在磁盘上。根据设计，B-Tree需要随机磁盘访问才能定位到叶子页，所以随机访问是不可避免地。然而，如果叶子页在物理分布上是顺序且紧密地，那么查询的性能就会更好。否则，对于范围查询、索引覆盖扫描等操作来说，速度可能会降低很多倍；对于索引覆盖扫描这一点更加明显。表的数据存储也可能碎片化。
然而，数据存储的碎片化比索引更加复杂。有三种类型的数据碎片:
1.行碎片(Row fragmentation)
这种碎片指的是数据行被存储在多个地方的片段中，即使查询只从索引中访问一行记录，行碎片也会导致性能下降
2.行间碎片(Intra-row fragmentation)
行间碎片是指逻辑上顺序的页，或者行在磁盘上不是顺序存储的。行间碎片对诸如全表扫描和聚簇索引扫描之类的操作有很大的影响，因为这些操作原本能从磁盘上顺序存储的数据中获益
3.剩余空间碎片(Free space fragmentation)
剩余空间碎片是指数据页中有大量的空余空间。这会导致服务器读取大量不需要的数据，从而造成浪费。
对于MyISAM表，这三类碎片化都可能发生。但InnoDB不会出现短小的行碎片；InnoDB会移动短小的行并重写到另一个片段中。可以通过执行OPTIMIZE TABLE或者导出再导入的方式来重新整理数据。这对多数存储引擎都是有效地。对于一些存储引擎如MyISAM，可以通过排序算法重建索引的方式来消除碎片。老版本的InnoDB没有什么消除碎片化的方法。不过最新版本InnoDB新增了"在线"添加和删除索引的功能，可以通过先删除，然后再重新创建索引的方式来消除索引的碎片化。对于那些不支持OPTIMIZE TABLE的存储引擎，可以通过一个不做任何操作(no-op)的ALTER TABLE操作来重建表。只需要将表的存储引擎修改为当前的存储引擎即可:
```sql
mysql>ALTER TABLE <table> ENGINE=<engine>;
```
对于开启了expand_fast_index_creation参数的Percona Server，按这种方式重建表，则会同时消除表和索引的碎片化。但对于标准版本的MySQL则只会消除表(实际上是聚簇索引)的碎片化。可用先删除所有索引，然后重建表，最后重新创建索引的方式模拟Percona Server的这个功能。应该通过一些实际测量而不是随意假设来确定是否需要消除索引和表的碎片化。Percona的XtraBackup有个--stats参数以非备份的方式运行，而只是打印索引和表的统计情况。包括页中的数据量和空余空间。这可以用来确定数据的碎片化程度。另外也要考虑数据是否已经达到稳定状态，如果你进行碎片整理将数据压缩到一起，可能反而会导致后续的更新操作触发一系列的页分裂和重组，这会对性能造成不良的影响(直到数据再次达到新的稳定状态)

是否向数据库请求了不需要的数据。
有些查询会请求超过实际需要的数据，然后这些多余的数据会被应用程序丢弃。这回给MySQL服务器带来额外的负担，并增加网络开销(如果应用服务器和数据库不在同一台主机上，网络开销就显得很明显了。即使在同一台服务器上仍然会有数据传输的开销)。另外也会消耗应用服务器的CPU和内存资源。下面是一些典型案例:
1.查询不需要的记录:一个常见的错误是常常误以为MySQL会只返回需要的数据，实际上MySQL却是先返回全部结果集再进行计算。我们经常会看到一些了解其他数据库系统的人会设计出这类应用程序。这些开发者习惯适用这样的使用，先使用SELECT语句查询大量的结果，然后获取前面的N行后关闭结果集(例如在新闻网站中取出100条记录，但是只是在页面上显示前面10条)。它们认为MySQL会执行查询，并只返回它们需要的10条数据，然后停止查询。实际情况是MySQL会查询出全部的结果集，客户端的应用程序会接收全部的结果集数据，然后抛弃其中大部分数据。最简单有效的解决方法就是在这样的查询后面加上LIMIT
2.多表关联时返回全部列:如果你想查询所有在电影Academy Dinosaur中出现的演员，千万不要按下面的写法编写查询:
```sql
mysql> SELECT * FROM actor
    -> INNER JOIN film_actor USING(actor_id)
    -> INNER JOIN film USING(film_id)
    -> WHERE film.title='Academy Dinosaur';
```
这将返回这三个表的全部数据列。正确的方式应该时像下面这样只取需要的列:
```sql
mysql>SELECT actor.* FROM actor .....
```
3.总是取出全部列:每次看到SELECT * 的时候都需要用怀疑的眼光审视，是不是真的需要返回全部的列？很可能不是必需的。取出全部列，会让优化器无法完成索引覆盖扫描这类优化，还会为服务器带来额外的IO、内存和CPU的消耗。因此，一些DBA是严格禁止SELECT * 的写法的，这样做有时候还能避免某些列被修改带来的问题。当然，查询返回超过需要的数据也不总是坏事。在许多案例中，人们会说这种有点浪费数据库资源的方式可以简化开发，因为能提高相同代码片段的复用性，如果清除这样做的性能影响，那么这种做法也是值得考虑的。如果应用程序使用了某种缓存机制，或者有其他考虑，获取超过需要的数据也可能有其他好处，但不要忘记这样做的代价是什么。获取并缓存所有的列的查询相比多个独立的只获取部分列的查询可能就更有好处。
4.重复查询相同的数据:如果你不太小心，很容易出现这样的错误——不断地重复执行相同的查询，然后每次都返回完全相同的数据。例如，在用户评论的地方需要查询用户头像的URL,那么用户多次评论的时候，可能就会反复查询这个数据。比较好的方案是，当初次查询的时候将这个数据缓存起来，需要的时候从缓存中取出，这样性能显然会更好。

MySQL是否扫描额外的记录。
在确定查询只返回需要的数据以后，接下来应该看看查询为了返回结果是否扫描了许多的数据。对于MySQL，最简单的衡量查询开销的三个指标如下:
1.响应时间
2.扫描的行数
3.返回的行数
没有哪个指标能够完美地衡量查询的开销，但它们大致反映了MySQL在内部执行查询时需要访问多少数据，并可以大概推算出查询运行的时间。这三个指标都会记录到MySQL的慢日志中，所以检查慢日志记录是找出扫描行数过多的查询的好办法

一个复杂查询还是多个简单查询。
设计查询的时候一个需要考虑的重要问题是，是否需要将一个复杂的查询分成多个简单的查询，在传统实现中，总是强调需要数据库层完成尽可能多的工作，这样做的逻辑在于以前总是认为网络通信、查询解析和优化是一件代价很高的事情。但是这样的想法对于MySQL并不适用，MySQL从设计上让连接和断开连接都很轻量级，在返回一个小的查询结果方面很高效。现代的网络速度比以前要快很多，无论是贷款还是延迟。在某些版本的MySQL上，即使在一个通用服务器上，也能够运行超过10万的查询，即使是一个千兆网卡(1000Mbps / 8 bit = 125M/s)也能轻松满足每秒超过2000次的查询。所以运行多个小查询现在已经不是大问题了。MySQL内部每秒能够扫描内存中上百万行数据，相比之下，MySQL响应数据给客户端就慢得多了。在其他条件都相同的时候，适用尽可能少的查询当然是更好地。但是有时候，将一个大查询分解为多个小查询是很有必要的。别害怕这样做，好好衡量一下这样做是不是会减少工作量。
不过，在应用设计的时候，如果一个查询能够胜任时还写成多个独立查询是不明智的。例如，有些应用对一个数据表做10次独立的查询来返回10行数据，每个查询返回一条结果，查询10次

切分查询。
有时候对于一个大查询我们需要"分而治之"，将大查询切分成小查询，每个查询功能完全一样，只完成一小部分，每次只返回一小部分查询结果。删除旧的数据就是一个很好的例子。定期地清除大量数据时，如果用一个大的语句一次性完成的话，则可能需要依次锁住很多数据、占满整个事务日志、耗尽系统资源、阻塞很多小的但很重要的查询。将一个大的DELETE语句切分成多个较小的查询可以尽可能小地影响MySQL性能，同时还可以减少MySQL复制地延迟。例如，我们需要每个月运行一次下面的查询:
```sql
mysql> DELETE FROM message WHERE created < DATE_SUB(NOW(), INTERVAL 3 MONT
```
那么可以用类似下面的办法来完成同样的工作:
```sql
rows_affected=0
do {
rows_affected = do_query(
"DELETE FROM message WHERE created < DATE_SUB(NOW(), INTERVAL 3 MONTH)
LIMIT 10000"
)
} while rows_affected > 0
```
一次性删除一万行数据一般来说是一个比较高效而且对服务器影响也是最小的做法(如果是事务型引擎，很多时候小事务能够更高效)，同时，需要注意的是，如果每次删除数据后，都暂停一会儿再做下一次删除，这样也可以将服务器上原本一次性的压力分散到一个很长的时间段中，就可以大大降低对服务器的影响，还可以大大减少删除时锁的持有时间

分阶关联查询。
很多高性能的应用都会对关联查询进行分解。简单地，可以对每一个表进行一次单表查询，然后将结果在应用程序中进行关联。例如，下面这个查询:
```sql
mysql> SELECT * FROM tag
    -> JOIN tag_post ON tag_post.tag_id=tag.id
    -> JOIN post ON tag_post.post_id=post.id
    -> WHERE tag.tag = 'mysql';
```
可以分解成下面这些查询来代替:
```sql
mysql> SELECT * FROM tag WHERE tag = 'mysql';
mysql> SELECT * FROM tag_post WHERE tag_id = 1234;
mysql> SELECT * FROM post WHERE post.id IN (123,456,567,9098,8904);
```
到底为什么要这样做呢？乍一看，这样做并没有什么好处，原本一条查询，这里却变成多条查询，返回的结果又是一模一样的。事实上，用分解关联查询的方式重构查询有如下的优势:
1.让缓存的效率更高。许多应用程序可以方便地缓存单表查询对应的结果对象。例如，上面查询中的tag已经被缓存了，那么应用就可以跳过第一个查询。再例如，应用中已经缓存了ID为123、567、9098的内容，那么第三个查询中的IN()中就可以少几个ID.另外，对MySQL的查询缓存来说(Query Cache)，如果关联中的某个表发生了变化，那么就无法适用查询缓存了，而拆分后，如果某个表很少改变，那么基于该表的查询就可以重复利用查询缓存结果了
2.将查询分解后，执行单个查询可以减少锁的竞争
3.再在应用层做关联，可以更容易对数据库进行拆分，更容易做到高性能和可扩展
4.查询本身效率也可能会有所提升。这个例子中，使用IN()代替关联查询，可以让MySQL按照ID顺序进行查询，这可能比随机关联要更高效。
5.可以减少冗余记录的查询。在应用层做关联查询，意味着对于某条记录应用只需要查询一次，而在数据库中做关联查询，则可能需要重复地访问一部分数据。从这点看，这样的重构还可能会减少网络和内存的消耗
6.更进一步，这样做相当于在应用中实现了哈希关联，而不是使用MySQL的嵌套循环关联。某些场景哈希关联的效率要高很多。
在很多场景下，通过重构查询将关联放到应用程序中将会更加高效，这样的场景有很多。比如，当应用能够方便地缓存单个查询的结果的时候、当可以将数据分不到不同的MySQL服务器上的时候、当能够使用IN()的方式代替关联查询的时候、当查询中使用同一个数据表的时候

MySQL客户端/服务器通信协议。
一般来说，不需要去理解MySQL通信协议的内部实现细节，只需要大致理解通信协议是如何工作的。MySQL客户端和服务器之间的通信协议是"半双工"的，这意味着，在任何一个时刻，要么是由服务器向客户端发送数据，要么是由客户端向服务器发送数据，这两个动作不能同时发生。所以，我们也无法也无须将一个消息切成小块独立来发送。这种协议让MySQL通信简单快速，但是也从很多地方限制了MySQL.一个明显的限制是，这意味着没法进行流量控制。一旦一端开始发送消息，另一端要接收完整个消息才能响应它。这就像来回抛球的游戏:在任何时刻，只有一个人能控制球，而且只有控制球的人才能将球抛回去(发送消息)。一旦客户端发送了请求，它能做的事情就只是等待结果了。相反的，一般服务器响应给用户的数据通常很多，由多个数据包组成。当服务器开始响应客户端请求时，客户端必须完整接收整个返回结果，而不能简单地只取前面几条结果，然后让服务器停止发送数据。这种情况下，客户端若接收完整的结果，然后取前面几条需要的结果，或者接收完几条结果后就"粗暴"地断开连接，都不是好注意。这也是在必要的时候一定要在查询中加上LIMIT限制的原因。换一种方式解释这种行为:当客户端从服务器取数据时，看起来是一个拉数据的过程，但实际上是MySQL在向客户端推送数据的过程。客户端不断地接收从服务器推送的数据，客户端也没法让服务器停下来。客户端像是"从消防管喝水"(这是一个术语)。多数连接MySQL的库函数都可以获得全部结果集并缓存到内存力，还可以逐行获取需要的数据。默认一般是获得全部结果集并缓存到内存中。MySQL通常需要等所有的数据都已经发生给客户端才能释放这条查询所占用的资源，所以接收全部结果并缓存通常可以减少服务器的压力，让查询能够早点结束、早点释放相应的资源。
当使用多数连接MySQL的库函数从MySQL获取数据时，其结果看起来都像时从MySQL服务器获取数据，而实际上都是从这个库函数的缓存获取数据。多数情况下这没什么问题，但是如果需要返回一个很大的结果集的时候，这样做并不好，因为库函数会花很多时间和内存来存储所有的结果集。如果能够尽早开始处理这些结果集，就能大大减少内存的消耗，这种情况下可以不适用缓存来记录结果而是直接处理。这样做的缺点是，对于服务器来说，需要查询完成后才能释放资源，所以在和客户端交互的整个过程中，服务器的资源都是被这个查询搜占用的(你可以使用SQL_BUFFER_RESULT)
我们看啊可能当使用PHP的时候是什么情况。首先，下面是我们连接MySQL的通常写法:
```php
<?php
$link = mysql_connect('localhost','user','p4ssword');
$result = mysql_query('SELECT * FROM HUGE_TABLE', $link);
$while($row = mysql_fetch_array($result)) {
// Do something with result
}
?>
```
这段代码看起来像是只有当你需要的时候，才通过循环从服务器取出数据。而实际上，在上面的代码中，在调用mysql_query()的时候，PHP就已经将整个结果缓存到内存中。下面的while循环只是从这个缓存中逐行取出数据，相反如果使用下面的查询，用mysql_unbuffered_query()代替mysql_query(),PHP则不会缓存结果:
```php
<?php
$link = mysql_connect('localhost', 'user', 'p4ssword');
$result = mysql_unbuffered_query('SELECT * FROM HUGE_TABLE', $link);
while($row = mysql_fetch_array($result)) {
//Do something with result
}
?>
```
不同的编程语言处理缓存的方式不同。例如，在Perl的DBD:mysql驱动中需要指定C连接库的mysql_use_result属性(默认是mysql_buffer_result)。下面是一个例子:
```perl
#!usr/bin/perl
use DBI;
my $dbh = DBI->connect('DBI:mysql:;host=localhost', 'user', 'p4ssword');
my $sth = $dbh->prepare('SELECT * FROM HUGE_TABLE', {mysql_use_result => 1});
$sth -> execute();
while (my $row = $sth->fetchrow_array()) {
# Do something with result
}
```
注意到上面的prepare()调用指定了mysql_use_result属性为1，所以应用将直接"使用"返回的结果集而不会将其缓存。也可以在连接MySQL的时候指定这个属性，这会让整个连接都使用不缓存的方式处理结果集:
```perl
my $dbh = DBI->connect('DBI:mysql:;mysql_use_result=1', 'user','p4ssword');
```

查询缓存(这里是指Query Cache).
在解析一个查询语句之前，如果查询缓存是打开的，那么MySQL会优先检查这个查询是否命中查询缓存中的数据。这个检查是通过一个对大小写敏感的哈希查找实现的。查询和缓存中的查询即使只有一个字节不同，那也不会匹配缓存结果(Percona版本的MySQL中提供了一个新的特性，可以在计算查询语句哈希值时，先将注释移除再计算哈希值，这对于不同注释的相同查询可以命中相同的查询缓存结果)。这种情况下查询就会进入下一个阶段的处理。如果当前的查询恰好命中了查询缓存，那么再返回查询结果之前MySQL会检查一次用户权限。这仍然时无须解析查询SQL语句的，因为在查询缓存中已经存放了当前查询需要访问的表信息。如果权限没有问题，MySQL会跳过所有其他阶段，直接从缓存中拿到结果并返回给客户端。这种情况下，查询不会被解析，不用生成执行计划，不会被执行 

查询优化处理
查询的生命周期的下一步时将一个SQL转换成一个执行计划，MySQL再依照这个执行计划和存储引擎进行交互。这包括多个子阶段:解析SQL、预处理、优化SQL执行计划。这个过程中任何错误(例如语法错误)都可能终止查询。接下来选择性地介绍其中几个独立的部分，在实际执行中，这几部分可能一起执行也可能单独执行。目的是帮助大家理解MySQL是如何执行查询，以便写出更优秀的查询。

查询执行引擎
在解析和优化阶段，MySQL将生成查询对应的执行计划，MySQL的查询执行引擎根据这个执行计划来完成整个查询。这里执行计划是一个数据结构，而不是和其他的关系型数据库那样生成对应的字节码。相对于查询优化阶段，查询执行阶段不是那么复杂:MySQL只是简单地根据执行计划给出的指令逐步执行。在根据执行计划逐步执行的过程中，有大量的操作需要通过调用存储引擎实现的接口来完成，这些接口也就是我们成为"handler API"的接口。查询中的每一个表由一个handler的实例表示。实际上，MySQL在优化阶段就为每个表创建了一个handler实例，优化器根据这些实例的接口可以获取表的相关信息，包括表的所有列名、索引统计信息，等等。
存储引擎接口有着非常丰富的功能，但是底层接口却只有几十个，这些接口像"搭积木"一样能够完成查询的大部分操作。例如，有一个查询某个索引的第一行的解耦，再有一个查询某个索引条目的下一个条目的功能，有了这两个功能我们就可以完成全索引扫描的操作了。这种简单的接口模式，让MySQL的存储引擎插件式架构成为可能，但是正如前面的讨论，也给优化器带来了一定的限制。
并不是所有的操作都有handler完成。例如，当MySQL需要进行表锁的时候，handler可能会实现自己的级别的、更细粒度的锁，如InnoDB就实现了自己的行基本锁，但这并不能代替服务器层的表锁。如果是所有存储引擎共有的特性则由服务器层实现，比如时间和日期函数、视图、触发器等等。
为了执行查询，MySQL只需要重复执行计划中的各个操作，知道完成所有的数据查询。

返回结果给客户端。
查询执行的最后一个阶段是将结果返回给客户端。即使查询不需要返回结果集给客户端，MySQL仍然会返回这个查询的一些信息，如该查询影响到的行数。如果查询可以被缓存，那么MySQL在这个阶段也会将结果存放到查询缓存中。MySQL将结果集返回客户端是一个增量、逐步返回的过程。例如，我们回头看看前面的关联操作，一旦服务器处理完成最后一个关联表，开始生成第一条结果时，MySQL就可以开始向客户端逐步返回结果集了。这样处理有两个好处:服务器端无须存储太多的结果，也就不会因为要返回太多结果而消耗太多内存。另外，这样的处理也让MySQL客户端第一时间获得返回的结果。结果集中的每一行会以一个满足MySQL客户端/服务器通信协议的封包发送，再通过TCP协议进行传输，在TCP传输的过程中，可能对MySQL的风暴进行缓存然后批量传输。

关联子查询。
MySQL的子查询实现得非常糟糕。最糟糕的一类查询是WHERE条件中包含IN()的子查询语句。例如，我们希望找到Sakila数据库中，演员Penelope Guinness(他的actor_id为1)参演过的所有影片信息。很自然的，我们会按照下面的方式用子查询实现:
```sql
mysql> SELECT * FROM sakila.film WHERE film_id IN(SELECT film_id FROM sakila.film_actor WHERE actor_id =1);
```
因为MySQL对IN()列表的选项有专门的优化策略，一般会认为MySQL会先执行子查询返回所有包含actor_id为1的film_id。一般来说，IN()列表查询速度很快，所以我们会认为上面的查询会这样执行:
```sql
-- SELECT GROUP_CONCAT(film_id) FROM sakila.film_actor WHERE actor_id=1;
-- Result :1,23,25,106,140,166,277,361,438,499,506,509,605,635,749,832,939,970,980
SELECT * FROM sakila.film WHERE film_id IN(1,23.....................,980);
```
很不幸，MySQL不是这样做的。MySQL会讲相关的外层表压到子查询中，它认为这样可以更高效率地查找到数据行。也就是说，MySQL会将查询改写成下面的样子:
```sql
SELECT * FROM sakila.film WHERE EXISTS (SELECT * FROM sakila.film_actor WHERE actor_id = 1 AND film_actor.film_id = film.film_id)
```
这时，子查询需要根据film_id来关联外部表film,因为需要film_id字段，所以MySQL认为无法先执行这个查询。通过EXPLAIN可以看到子查询是一个相关子查询(DEPENDENT SUBQUERY)(可以使用EXPLAIN EXTENDED来查看这个查询被改写成了什么样子)
```sql

mysql> EXPLAIN SELECT * FROM sakila.film WHERE EXISTS (SELECT * FROM sakila.film_actor WHERE actor_id = 1 AND film_actor.film_id = film.film_id)
    -> ;
+----+--------------------+------------+------------+--------+------------------------+---------+---------+---------------------------+------+----------+-------------+
| id | select_type        | table      | partitions | type   | possible_keys          | key     | key_len | ref                       | rows | filtered | Extra       |
+----+--------------------+------------+------------+--------+------------------------+---------+---------+---------------------------+------+----------+-------------+
|  1 | PRIMARY            | film       | NULL       | ALL    | NULL                   | NULL    | NULL    | NULL                      | 1000 |   100.00 | Using where |
|  2 | DEPENDENT SUBQUERY | film_actor | NULL       | eq_ref | PRIMARY,idx_fk_film_id | PRIMARY | 4       | const,sakila.film.film_id |    1 |   100.00 | Using index |
+----+--------------------+------------+------------+--------+------------------------+---------+---------+---------------------------+------+----------+-------------+
2 rows in set (0.10 sec)
```
根据EXPLAIN的输出我们可以看到，MySQL先选择对flim表进行全表扫描，然后根据返回的film_id逐个进行子查询。如果是一个很小的表，这个查询的糟糕的性能可能还不会引起注意，但是如果外层的表是一个非常大的表，那么这个查询的性能会非常糟糕。当然我们很容易用下面的办法来重写这个查询:
```sql
mysql>SELECT  film.* FROM sakila.film INNER JOIN sakila.film_actor USING(film_id) WHERE actor_id = 1;
```
另一个优化的办法是使用函数GROUP_CONCAT()在IN()中构造一个由逗号分割的列表，有时这比上面的使用关联改写更快。因为使用IN()加子查询，性能经常会非常糟，所以通常建议使用EXISTS()等效的改写查询来获取更好的效率。下面是另一种改写IN()加子查询的办法:
```sql
mysql>SELECT * FROM sakila.film WHERE EXISTS (SELECT * FROM sakila.film_actor WHERE actor_id = 1 AND film_actor.film_id = film.film_id)
```

UNION的限制。
有时，MySQL无法将限制条件从外层"下推"到内层，这使得原本能够限制部分返回结果的条件无法应用到内层查询的优化上。如果希望UNION的各个子句能够根据LIMIT只取部分结果集，或者希望能够先排好序再合并结果集的话，就需要在UNION的各个子句中分别使用这些子句。例如，想将两个子查询结果联合起来，然后再取前20条记录，那么MySQL会将两个表都存放到同一个临时表中，然后再取出前20行记录:
```sql
(SELECT first_name,last_name FROM sakila.actor ORDER BY last_name)
UNION ALL
(SELECT first_name,last_name FROM sakila.customer ORDER BY last_name)
LIMIT 20
```
这条查询将会把actor中的200条记录和customer表中的599条记录存放在一个临时表中，然后再从临时表中取出前20条。可以通过在UNION的两个子查询中分别加上一个LIMIT 20来减少临时表中的数据:
```sql
(SELECT first_name,last_name FROM sakila.actor ORDER BY last_name LIMIT 20)
UNION ALL
(SELECT first_name,last_name FROM sakila.customer ORDER BY last_name LIMIT 20)
LIMIT 20
```
现在中间的临时表只会包含40条记录了，除了性能考虑之外，在这里还需要注意一点:从临时表中取出数据的顺序并不是一定的，所以如果想获得正确的顺序，还需要加上一个全局的ORDER BY 和LIMIT操作

索引合并优化。
前面已经讨论过，在5.0和更新的版本中，当WHERE子句中包含多个复杂条件的时候，MySQL能够访问单个表的多个索引以合并和交叉过滤的方式来定位需要查找的行(索引下推)

等值传递。
某些时候，等值传递会带来一些意想不到的额外消耗。例如，有一个非常大的IN()列表，而MySQL优化器发现存在WHERE、ON或者USING的子句，将这个人列表值和另一个表的某些列相关联。那么优化器会将IN()列表都复制应用到关联的各个表中。通常，因为各个表新增了过滤条件，优化器可更高效地从存储引擎过滤记录，但是如果这个列表非常大，则会导致优化和执行都会变慢。

并行执行。
MySQL无法利用多核特性来并行执行查询。很多其他的关系型数据库能够提供这个特性，但是MySQL做不到。这里特别指出是想说不要花时间取尝试寻找并行执行查询的方法。MySQL在处理OLTP场景下的短查询效果很好，但对于复杂大查询则能力有效。最直接一点就是，对于一个SQL语句，MySQL最多只能使用一个CPU核来处理，在这种场景下无法发挥主机CPU多核的能力。MySQL没有停滞不前，一直在发展，新推出的MySQL8.0.14版本第一次引入了并行查询特性，使得check table和select count(*)类型的语句性能成倍提升。虽然目前使用场景还比较优先，但后续的发展值得期待。
1.使用方式
通过配置参数innodb_parallel_read_threads来设置并发线程数，就能开始并行扫描功能，默认这个值为4.有个简单的实验，通过sysbench导入2亿条数据，分别配置innodb_parallel_read_threads为1，2，4，8，16，32，64,测试并行执行的效果。测试语句为SELECT COUNT(*) FROM sbtest1;
如图所示。横轴是配置并发线程数，纵轴是语句执行时间。从测试结果来看，整个并行表现还是不错的，扫描2亿条记录，从单线程的18s，下降到32线程的1s。后面并发开再多，由于数量优先，多线程的管理消耗超过了并发带来的性能提升，不能再继续缩短SQL执行时间
2.MySQL并行执行
实际上MySQL的并行执行还处于非常初级阶段，如下图所示，左边是之前MySQL串行处理单个SQL形态；中间的是目前MySQL版本提供的并行能力，InnoDB引擎并行扫描的形态；最右边的是未来MySQL要发展的形态，优化器根据系统负载和SQL生成并行计划，并将分区计划下发给执行器并行执行。并行执行不仅仅是并行扫描，以及并行排序等。目前版本MySQL的上层优化器以及执行器并没有配套的修改。InnoDB的并行扫描主要应用在了分区，并行扫描，预读，以及与执行器交互的适配器类(详细分析请见https://www.cnblogs.com/cchust/p/12347166.html)

哈希关联。
MySQL并不支持哈希关联——MySQL的所有关联都是嵌套循环关联。不过，可以通过建立一个哈希索引来曲线地实现哈希关联。如果使用的是Memeory存储引擎，则索引都是哈希索引，所以关联的时候也类似于哈希关联，另外,MariaDB已经实现了真正的哈希关联

松散索引扫描。
由于历史原因，MySQL并不支持松散索引扫描，也就无法按照不连续的方式扫描一个索引。通常，MySQL的索引扫描需要先定义一个起点和终点，即使需要的数据只是这段索引中很少数的几个，MySQL仍需要扫描这段儿索引中的每一个条目。下面我们通过一个示例说明这点。假设我们有如下索引(a,b)，有下面的查询:
```sql
mysql>SELECT ... FROM tbl WHERE b BETWEEN 2 AND 3;
```
因为索引的前导字段是列a，但是在查询中只指定了字段b,MySQL无法使用这个索引，从而只能通过全表扫描找到匹配的行，如图所示。了解索引的物理结构的话，不难发现还可以有一个更快的办法执行上面的查询。索引的物理结构(不是存储引擎的API)使得可以先扫描a列的第一个值对应的b列的范围，然后再跳到a列不同第二个不同值扫描对应的b列的范围。如图所示展示了如果由MySQL来实现这个过程会怎样。注意到，这时就无须再使用WHERE子句过滤，因为松散索引扫描已经跳过了所有不需要的记录。上面是一个简单的例子，除了松散索引扫描，新增一个合适的索引当然也可以优化上述查询。但对于某些场景，增加索引是没用的，例如，对于第一个索引列是范围条件，第二个索引列是等值条件的查询，靠增加索引就无法解决问题。
MySQL5.0之后的版本，在某些特殊的场景下是可以使用松散索引扫描的，例如，在一个分组查询中需要找到分组的最大值和最小值:
```sql
mysql> EXPLAIN SELECT actor_id, MAX(film_id)
    -> FROM sakila.film_actor
    -> GROUP BY actor_id\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: film_actor
   partitions: NULL
         type: range
possible_keys: PRIMARY,idx_fk_film_id
          key: PRIMARY
      key_len: 2
          ref: NULL
         rows: 201
     filtered: 100.00
        Extra: Using index for group-by
```
在EXPLAIN中的Extra字段显示"Using index for group-by"，表示这里将使用松散索引扫描，不过如果MySQL能写上"loose index probe"，相信会更好理解。在MySQL很好地支持松散索引扫描之前，一个简单的绕过问题的办法就是给前面的列加上可能的常数值。在MySQL5.6之后的版本，关于松散索引扫描的一些限制将会通过"索引下推(index condition pushdown)"的方式解决

最大值和最小值优化。
对于MIN()和MAX()查询，MySQL的优化做得并不好。这里有一个例子:
```sql
mysql> SELECT MIN(actor_id) FROM sakila.actor WHERE first_name='PENELOPE';
```
因为在first_name字段上并没有索引，因此MySQL将会进行一次全表扫描。如果MySQL能够进行主键扫描，那么理论上，当MySQL读到的第一个满足条件的记录的时候，就是我们需要找到的最小值了，因为主键是严格按照actor_id字段的大小顺序排列的。但是MySQL这时只会做全表扫描，我们可以通过查看SHOW STATUS的全表扫描计数器来验证这一点。一个曲线的优化办法是移除MIN(),然后使用LIMIT来讲查询重写如下:
```sql
mysql> SELECT actor_id FROM sakila.actor USE INDEX(PRIMARY)
    -> WHERE first_name = 'PENELOPE' LIMIT 1;
+----------+
| actor_id |
+----------+
|        1 |
+----------+
1 row in set (0.00 sec)
```
这个策略可以让MySQL扫描尽可能少的记录数。如果你是一个完美主义者，可能会说这个SQL已经无法表达她的本意了。一般我们通过SQL告诉服务器我们需要什么数据，由服务器来决定如何最优地获取数据，不过在这个案例中，我们其实是告诉MySQL如何去获取我们需要的数据，通过SQL并不能一眼就看出我们其实是想要一个最小值。确实如此，有时候为了获得更高的性能，我们不得不放弃一些原则

在同一个表上查询和更新。
MySQL不允许对同一个张表同时进行查询和更新。这其实并不是优化器的限制，如果清楚MySQL是如何执行查询，就可以避免这种情况。下面是一个无法运行的SQL，虽然这是一个符合标准的SQL语句。这个SQL语句尝试将两个表中相似行的数量记录到字段cnt中:
```sql
mysql> UPDATE tbl AS outer_tbl
    -> SET cnt = (
    -> SELECT COUNT(*) FROM tbl AS inner_tbl
    -> WHERE inner_tbl.type = outer_tbl.type
    -> );
ERROR 1093(HY000):You can't specify target table 'outer_tbl' for update in FROM clause
```
可以通过使用生成表的形式来绕过上面的限制，因为MySQL只会把这个表当作一个临时表来处理。实际上，这执行了两个查询:一个是子查询中的SELECT语句，另一个是多表关联UPDATE，只是关联的表是一个临时表。子查询会在UPDATE语句打开表之前就完成。所以下面的查询将会正常执行:
```sql
mysql> UPDATE tbl
    -> INNER JOIN (
    -> SELECT type, count(*) AS cnt
    -> FROM tbl
    -> GROUP BY type
    -> ) AS der USING(type)
    -> SET tbl.cnt = der.cnt;
```

6.SQL_CACHE和SQL_NO_CACHE
这个提示告诉MySQL这个结果集是否应该缓存在查询缓存中
7.SQL_CALC_FOUND_ROWS
严格来说，这并不是一个优化器提示。它不会告诉优化器任何关于执行计划的东西，它会让MySQL返回的结果集包含更多的信息。查询中加上该提示MySQL会计算除去LIMIT子句后这个查询要返回的结果集的总数，而实际上只返回LIMIT要求的结果集。可以通过函数FOUND_ROW()获得这个值
8.FOR UPDATE和LOCK IN SHARE MODE
这也不是真正的优化器提示。这两个提示主要控制SELECT语句的所机制，但只对实现了行级锁的存储引擎有效。使用该提示会对符合查询条件的数据行加锁。对于INSERT...SELECT语句是不需要这两个提示的，因为对于MySQL5.0和更细那版本会默认给这些记录加上读锁(可以禁用该默认行为，但不是个好主意)。唯一内置的支持这两个提示的引擎就是InnoDB。另外需要记住的是，这两个提示会让某些优化无法正常使用，例如索引覆盖扫描。InnoDB不能再不访问主键的情况下排他地锁定行，因为行的版本信息保存在主键中。糟糕的是，这两个提示经常被滥用，很容易造成服务器的锁争用问题应该尽可能地避免使用这两个提示，通常都有其他更好的方式可以实现同样的目的。
9.USE INDEX、IGNORE INDEX和FORCE INDEX
这几个提示会告诉优化器使用或者不适用哪些索引来查询记录(例如，在决定关联顺序的时候使用哪个索引)。在MySQL5.0和更早的版本，这些提示并不会影响到优化器选择哪个索引进行排序和分组，在MySQL5.1和之后的版本可以通过新增选项FOR ORDER BY和FOR GROUP BY来指定是否对排序和分组有效。FORCE INDEX和USE INDEX基本相同，除了一点:FORCE INDEX会告诉优化器全表扫描的成本会远远高于索引扫描，哪怕实际上该索引用处不大。当发现优化器选择了错误的索引，或者因为某些原因(比如在不适用ORDER BY的时候希望结果有序)要使用另一个索引时，可以使用该提示。

MySQL5.0和更新版本中，新增了一些参数用来控制优化器的行为：
1.optimizer_search_depth
这个参数控制优化器在穷举执行计划时的限度。如果查询长时间处于"Statistics"状态，那么可以考虑调低此参数。
2.optimizer_prune_level
该参数默认是打开的，这让优化器会根据需要扫描的行数来决定是否跳过某些执行计划
3.optimizer_switch
这个变量包含了一些开启/关闭优化器特性的标志位。例如在MySQL5.1中可以通过这个参数来控制禁用索引合并的特性

前两个参数是用来控制优化器可以走的一些"结晶"。这些结晶可以让优化器在处理非常复杂的SQL语句时，仍然可以很搞笑，但这也可能让优化器错过一些真正最优的执行计划。所以应该根据实际需要来修改这些参数。

MySQL升级后的验证。
在优化器面前耍一些"小聪明"是不好的。这样做收效甚小，但是却给维护带来了很多额外的工作量。在MySQL版本升级的时候，这个问题就很突出了，你设置的"优化器提示"很可能会让新版的优化策略失效。MySQL5.0版本引入了大量优化策略，在还没有正式发布的5.6版本中，优化器的改进也是近些年来最大的一次改进。如果要更新到这些版本，当然希望能够从这些改进中受益。新版MySQL基本上在各个方面都有非常大的改进，5.5和5.6这两个版本尤为突出。升级操作一般来说都很顺利，但仍然建议仔细检查各个细节，以防止一些边界情况影响你的应用程序。不过还好，要避免这些，你不需要符出太多的经历，使用Percona ToolKit中的pt-upgrade工具，就可以检查在新版本中运行的SQL是否和老版本一样，返回相同的结果

优化COUNT()查询.
COUNT()聚合函数，以及如何优化使用了该函数的查询，很可能是MySQL中最容易被误解的10个话题之一。在网上随便一搜就能看到很多错误的理解，可能比我们想象的多得多。在做优化之前，先来看看COUNT()函数真正的作用是什么
1.COUNT()的作用
COUNT()是一个特殊的函数，有两种非常不同的作用:它可以统计某个列值的数量，也可以统计行数，在统计列值时要求列值是非空的(不统计NULL).如果在COUNT()的括号中指定了列或者列的表达式，则统计的就是这个表达式有值的结果数(而不是NULL).因为很多人对NULL理解有问题，所以这里很容易产生误解。COUNT()的另一个作用是统计结果集的行数。当MySQL确认括号内的表达式值不可能为空时，实际上就是在统计行数。最简单的就是当我们使用COUNT(*)的时候，这种情况下通配符*并不会像我们猜想的那样扩展成所有的列，实际上，它会忽略所有的列而直接统计所有的行数。
我们发现一个最常见的错误就是，在括号内指定了一个列却希望统计结果集的行数。如果希望知道的是结果集的行数，最好使用COUNT(*)，这样些意义清晰，性能也会很好
2.关于MyISAM的神话
一个容易产生的误解就是:MyISAM的COUNT()函数总是非常快，不够这是有前提条件的，即只有没有任何WHERE条件的COUNT(*)才非常快，因为此时无须实际地去计算表的行数。MySQL可以利用存储引擎的特性直接获得这个值。如果MySQL知道某列col不可能为NULL值，那么MySQL内部会将COUNT(col)表达式优化为COUNT(*)。当统计带WHERE子句的结果集行数，可以是统计某个列值得数量时，MyISAM得COUTN()和其他存储引擎没有任何不同，就不再有神话般得速度了，所以在MyISAM引擎表上执行COUNT()有时候比别得引擎块，有时候比别的引擎慢，这受很多因素影响，要视具体情况而定
3.简单的优化
有时候可以使用MyISAM在COUNT(*)全表非常快得这个特性，来加速一些特定条件的COUNT()查询。在下面的例子中，我们使用标准数据库world来看看如何快速查找到所有ID大于5的城市。可以像下面这样来写这个查询:
```sql
mysql> SELECT COUNT(*) FROM world.City WHERE ID > 5;
```
通过SHOW STATUS的结果可以看到该擦汗寻需要扫描4097行数据。如果将条件反转一下，先找到ID小于等于5的城市数，然后用总城市数一减就能得到同样的结果，却可以将扫描的行数减少到5行以内:
```sql
mysql> SELECT (SELECT COUNT(*) FROM world.City) - COUNT(*)
    -> FROM world.City WHERE ID <= 5;
```
这样做可以大大减少需要扫描的行数，是因为在查询优化阶段会将其中的子查询当作一个常数来处理。在邮件组和IRC聊天频道中，通常会看到这样的问题:如何在同一个查询中统计同一个列的不同值的数量，以减少查询的语句量。例如，假设可能需要通过一个查询返回各种不同颜色的商品数量，此时不能使用OR语句(比如SELECT COUNT(color='blur' OR color='red') FROM items;)因为这样做就无法区分不同颜色的商品数量；也不能在WHERE条件中指定颜色(比如SELECT COUNT(*) FROM items WHERE color='blue' AND color = 'RED')因为颜色的条件是互斥的。下面的查询可以在一定程度上解决这个问题。
```sql
mysql> SELECT SUM(IF(color='blue', 1,0)) AS blue, SUM(IF(color='red',1,0)) AS red FROM items;
```
也可以使用COUNT()而不是SUM()实现同样的目的，只需要将满足条件设置为真，不满足条件设置为NULL即可
```sql
mysql> SELECT COUNT(color = 'blue' OR NULL) AS blue, COUNT(color= 'read' OR NULL) AS red FROM items;
```

优化关联查询。
这个话题基本上一直在讨论，这里需要特别提到的是:
1.确保ON或者USING子句中的列上有索引。在创建索引的时候就要考虑到关联的顺序。当表A和表B用到c关联的时候，如果优化器的关联顺序是B、A,那么久不需要在B表的对应列上建上索引。没有用到的索引只会带来额外的负担。一般来说，除非有其他理由，否则只需要在关联顺序中的第二个表的相应列上创建索引。
2.确保任何的GROUP BY 和ORDER BY中的表达式只涉及到一个表中的列，这昂MySQL才有可能使用索引来优化这个过程
3.当升级MySQL的时候需要注意:关联语法、运算符优先级等其他可能会发生变化的地方。因为以前是普通关联的地方可能会变成笛卡儿积，不同类型的关联可能会生成不同的结果等

优化子查询
关于子查询优化给出的最重要的优化建议就是尽可能使用关联查询，至少当前的MySQL版本需要这样，"尽可能使用关联"并不是绝对的,如果使用的是MySQL5.6或更新的版本或者MariaDB，那么久可以直接忽略关于子查询的这些建议了

优化GROUP BY和DISTINCT
在很多场景下，MySQL都使用同样的方法优化这两种查询，事实上，MySQL优化器会在内部处理的时候相互转化这两类查询。它们都可以使用索引来优化，这也是最有效的优化办法。在MySQL中，当无法使用索引的时候，GROUP BY使用两种策略来完成:使用临时表或者文件排序来做分组。对于任何查询语句，这两种策略的性能都有可以提升的地方。可以通过使用提示SQL_BIG_RESULT和SQL_SMALL_RESULT来让优化器按照你希望的方式运行。如果需要对关联查询做分组(GROUP BY)，并且是按照查找表中的某个列进行分组，那么通常采用查找表的标识列分组的效率会比其他列更高。例如下面的查询效率不会很好:
```sql
mysql> SELECT actor.first_name,actor.last_name, COUNT(*)
    -> FROM sakila.film_actor
    -> INNER JOIN sakila.actor USING(actor_id)
    -> GROUP BY actor.first_name,actor.last_name;
```
如果查询按照下面的写法效率则会更高:
```sql
mysql> SELECT actor.first_name,actor.last_name, COUNT(*) FROM sakila.film_actor INNER JOIN sakila.actor USING(actor_id) GROUP BY film_actor.actor_id;
```
使用actor.actor_id列分组的效率甚至会比使用film_actor.actor_id更好。这点通过简单的测试即可验证。这个查询利用了演员的姓名和ID直接相关的特点，因此改写后的结果不受影响，但显然不是所有的关联语句的分组查询都可以改写成在SELECT中直接使用非分组列的形式的。甚至可能会在服务器上设置SQL_MODE来禁止这样的写法。如果是这样，也可以通过MIN()或者MAX()函数来绕过这种限制，但一定要清楚，SELECT后面出现的非分组列一定是直接依赖分组列，并且在每个组内的值是唯一的，或者是业务上根本不在乎这个值具体是什么:
```sql
mysql>SELECT MIN(actor.first_name), MAX(actor.last_name), .....;
```
较真的人可能会说这样写的分组查询是有问题的，确实如此。从MIN()或者MAX()函数的用法就可以看出这个查询是有问题的。但若更在乎的是MySQL运行查询的效率时这样做也无可厚非。如果实在较真的话也可以改写成下面的形式
```sql
mysql> SELECT actor.first_name,actor.last_name, cnt FROM sakila.actor INNER JOIN (  SELECT actor_id, COUNT(*) AS cnt FROM sakila.film_actor GROUP BY actor_id ) AS c USING(actor_id);
```
这样写更满足关系理论，但成本有点高，因为子查询需要创建和填充临时表，而子查询中创建的临时表是没有任何索引的(值得一提的是，MariaDB修复了这个限制)。在分组查询的SELECT中直接使用非分组列通常不是什么好主意，因为这样的结果通常是补丁的，当索引改变，或者优化器选择不同的优化策略时都可能导致结果不一样。碰到的大多数这种查询最后都导致了故障(因为MySQL不会对这类查询返回错误)，而且这种写法大部分是由于偷懒而不是为优化而故意这么设计的。建议始终使用含义明确的语法。事实上，建议对MySQL的SQL_MODE设置为包含ONLY_FULL_GROUP BY，这时MySQL会对这类查询直接返回一个错误，提醒你需要重写这个查询。如果没有通过ORDER BY子句显示地指定排序列，当查询使用GROUP BY子句地时候，结果集会自动按照分组的字段进行排序。如果不关心结果集的顺序，而这种默认排序又导致了需要文件排序，则可以使用ORDER BY NULL，让MySQL不再进行文件排序。也可以在GROUP BY子句中直接使用DESC或者ASC关键字

优化GROUP BY WITH ROLLUP
分组查询的一个变种就是要求MySQL对返回的分组结果再做一次超级聚合。可以使用WITH ROLLUP子句来实现这种逻辑，但可能会不够优化。可以通过EXPLAIN来观察其执行计划，特别要注意是否通过文件排序或者临时表实现的，然后再去掉WITH ROLLUP子句看执行计划是否相同。也可以通过前面介绍的优化器提示来固定执行计划。很多时候，如果可以，在应用程序中做超级聚合是更好的，虽然这需要返回给客户端更多的结果。也可以在FROM子句中嵌套使用子查询，或者是通过一个临时表存放中间数据，然后和临时表执行UNION来得到最终结果。最好的办法是尽可能地将WITH ROLLUP功能转移到应用程序中处理

优化排名语句。
使用用户自定义变量的一个特性是你可以在给一个变量赋值的同时使用这个变量，换句话说，用户自定义变量的赋值具有"左值"特性。下面的例子展示了如何使用变量来实现一个类似"行号(row number)"的功能：
```sql
mysql> SET @rownum := 0;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT actor_id, @rownum := @rownum + 1 AS rownum FROM sakila.actor ORDER BY actor_id ASC  LIMIT 3;
+----------+--------+
| actor_id | rownum |
+----------+--------+
|        1 |      1 |
|        2 |      2 |
|        3 |      3 |
+----------+--------+
3 rows in set (0.01 sec)
```
这个例子的实际意义不打，它只是实现了一个和该主键一样的列。不过，我们也可以把这当作是一个排名。现在我们来看一个更复杂的用法。我们先编写一个查询获取演过最多电影的前10位演员，然后根据它们的出演电影次数做一个排名，如果出演的电影数量一样，则排名相同，我们先编写一个查询，返回每隔演员参演电影的数量:
```sql
mysql> SELECT actor_id,COUNT(*) AS cnt
    -> FROM sakila.film_actor
    -> GROUP BY actor_id
    -> ORDER BY cnt DESC
    -> LIMIT 10;
+----------+-----+
| actor_id | cnt |
+----------+-----+
|      107 |  42 |
|      102 |  41 |
|      198 |  40 |
|      181 |  39 |
|       23 |  37 |
|       81 |  36 |
|       60 |  35 |
|       13 |  35 |
|      158 |  35 |
|      144 |  35 |
+----------+-----+
10 rows in set (0.00 sec)
```

避免重复查询刚刚更新的数据。
如果在更新行的同时又希望获得该行的信息，要怎么做才能避免重复的查询呢？不幸的是，MySQL并不支持像PostgreSQL那样的UPDATE RETURNING语法，这个语法可以帮你在更新行的时候同时返回该行的信息。还好在MySQL中你可以使用变量来解决这个问题。例如，一个用户希望能够更高效地更新一条记录地时间戳，同时希望查询当前记录中存放地时间戳是什么。简单地，可以用下面地代码来实现:
```sql
UPDATE t1 SET lastUpdated = NO() WHERE id =1;
SELECT lastUpdated FROM t1 WHERE id = 1;
```
使用变量，我们可以按如下方式重写查询：
```sql
UDPATE t1 SET lastUpdated = NOW() WHERE id = 1 AND @now:=NOW();
```
上面查询看起来仍然需要两个查询，需要两次网络来回，但是这里的第二个查询无须访问任何数据表，所以会快非常多。(如果网络延迟非常大，那么这个优化的意义可能不大，不过这对这个用户，这样做的效果很好)

统计更新和插入的数量
当使用了INSERT ON DUPLICATE KEY UPDATE的时候，如果想知道到底插入了多少行数据，到底有多少数据是因为冲突而改写成更新操作的？Kerstian Kohntopp在他的博客上给出了一个解决这个问题的办法，实现办法的本质如下:
```sql
INSERT INTO t1 (c1, c2) VALUES(4,4),(2,1), (3,1)
ON DUPLICATE KEY UPDATE
c1 = VALUES(c1) + () * (@x:=@x+1));
```
当每次由于冲突导致更新时对变量@x自增一次。然后通过对这个表达式乘以0来让其不影响要更新的内容。另外，MySQL的协议会返回被更改的总行数，所以不需要单独统计这个值

确定取值的顺序
使用用户自定义变量的一个最常见的问题就是没有注意到在赋值和读取变量的时候可能是在查询的不同的阶段。例如，在SELECT子句中进行赋值然后在WHERE子句中读取变量，则可能变量取值并不如你所想。下面的查询看起来只返回一个结果，但事实并非如此:
```sql
mysql> SET @rownum := 0;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT actor_id, @rownum := @rownum + 1 AS cnt
    -> FROM sakila.actor
    -> WHERE @rownum <= 1;
+----------+------+
| actor_id | cnt  |
+----------+------+
|       58 |    1 |
|       92 |    2 |
+----------+------+
2 rows in set (0.00 sec)
```
因为WHERE和SELECT是在查询执行的不同阶段被执行的。如果在查询中再加入ORDER BY的化，结果可能会更不同:
```sql
mysql> SELECT actor_id, @rownum := @rownum + 1 AS cnt FROM sakila.actor WHERE @rownum <= 1 ORDER BY first_name;
```
这是因为ORDER BY 引入了文件排序，而WHERE条件是文件排序操作之前取值的，所以这条查询会返回表中的全部记录。解决这个问题的办法是让变量的赋值和取值发生在执行查询的同一阶段:
```sql
mysql> SET @rownum :=0;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT actor_id, @rownum AS rownum
    -> FROM sakila.actor
    -> WHERE (@rownum := @rownum + 1) <= 1;
+----------+--------+
| actor_id | rownum |
+----------+--------+
|       58 |      1 |
+----------+--------+
1 row in set (0.00 sec)
```

编写偷懒的UNIO。
假设需要编写一个UNION查询，其第一个子查询作为分支条件先执行，如果找到了匹配的行，则跳过第二个分支。在某些业务场景中确实会有这样的需求，比如先在一个频繁访问的表中查找"热"数据，找不到再去另外一个较少访问的表中查找"冷"数据(区分热数据和冷叔是一个很好的提高缓存命中率的方法)。
下面的查询会在两个地方查找一个用户——一个主用户表，一个长事件不活跃的用户表，不活跃用户表的目的是为了实现更高效的归档(Baron认为在一些社交网站上归档一些常见不活跃用户后，用户重新回到网站时有这样的需求，当用户再次登录时，一方面我们需要将其从归档中重新拿出来，另外，还可以给他发送一份欢迎邮件。这对一些不活跃的用户是非常好的一个优化)
```sql
SELECT id FROM WHERE id = 123
UNION ALL
SELECT id FROM users_archived WHERE id = 123;
```
上面这个查询是可以正常工作的，但是即使在users表中找到了记录，上面的查询还是会去归档表user_archived中再查找一次。我们可以用一个偷懒的UNION查询来抑制这样的数据返回，而且只有当第一个表中没有数据时，我们才在第二个表中查询。一旦在第一个表中找到记录，我们就定义一个变量@found.我们通过在结果列中做一次赋值来实现，然后将赋值放在CREATEST中来避免返回额外的数据。为了明确我们的结果到底来自哪张表，我们新增了一个包含表名的列。最后我们需要在查询的末尾将变量重置为NULL。这样保证遍历时不会干扰后面的结果。完成的查询如下:
```sql
SELECT GREATEST(@found := -1, id) AS id, 'users' AS which_tbl
FROM users WHERE id = 1
UNION ALL
SELECT id, 'users_archived'
FROM users_archived WHERE id = 1 AND @found IS NULL
UNION ALL
SELECT 1, 'reset' FROM DUAL WHERE (@found := NULL) IS NOT NULL;
```

用户自定义变量的其他用处
不仅是在SELECT语句中，在其他任何类型的SQL语句中都可以对变量进行赋值。事实上，这也是用户自定义变量最大的用途。例如，可以像前面使用子查询的方式改进排名语句一样改进UPDATE语句。不过我们需要使用一些技巧来获得我们希望的效果。有时，优化器会把变量当作一个编译时常量来对待，而不是对其进行赋值。将函数放在类似于LEAST()这样的函数中通常可以避免这样的问题。另一个办法是在查询被执行前检查变量是否被赋值。不同的场景下使用不同的办法。通过一些实际，可以了解所有用户自定义变量能够做的有趣的事情，例如下面这些用法:
1.查询运行时计算总数和平均值
2.模拟GROUP 语句中的函数FIRST()和LAST()
3.对大量数据做一些数据计算
4.计算一个大表的MD5散列值
5.编写一个样本处理函数，当样本中的数值超过某个边界值的时候将其变成0
6.模拟读/写游标
7.在SHOW语句的WHERE子句中加入变量值

使用MySQL构建一个对列表。
使用MySQL来实现对列表是一个取巧的做法，我们看到很多系统在高流量、高并发的情况下表现并不好。典型的模式是一个表包含多种类型的记录:未处理记录、已处理记录、正在处理记录等。一个或者多个消费者线程在表中查找未处理的记录，然后声称正在处理、当处理完成后，再将记录更新成已处理状态。一般的，例如邮件发送、多命令处理、评论修改等会使用类似模式。通常有两个原因使得大家认为这样的处理方式并不合适。第一，随者队列表越来越大和索引深度的增加，找到未处理记录的速度会随之变慢。你可以通过将队列表分成两部分来解决这个问题，就是将已处理记录归档或者存放到历史表，这可以始终保证队列表很小。第二，一般的处理过程分两步，先找到未处理记录然后加锁。找到记录会增加服务器的压力，而加锁操作则会让各个消费者线程增加竞争，因为这时一个串行化的操作。找到未处理记录一般来说都没问题，如果有问题则可以通过使用消息的方式来通知各个消费者。具体的，可以使用一个带有注释的SLEEP()函数做超时处理，如下:
```sql
SELECT /* wating on unsent_email */ SLEEP(10000);
```
这让线程一直阻塞，直到两个条件之一满足:10 000秒后超时，或者另一个线程使用KILL QUERY结束当前的SLEEP。因此，当再向队列表中新增一批数据后，可以通过SHOW PROCESSLIST，根据注释找到当前正在休眠的线程，并将其KILL。你可以使用函数GET_LOCK()和RELEASE_LOCK()来实现通知，或者可以在数据库之外实现，例如使用一个消息服务。最后需要解决的问题是如何让消费者标记正在处理的记录，而不至于让多个消费者重复处理一个记录。我们看到大家一般使用SELECT FOR UPDATE来实现。这通常是扩展性问题的根源，这会导致大量的事务阻塞并等待。
一般，我们要尽量避免使用SELECT FOR UPDATE。不光是队列表，任何情况下都要尽量避免。总是有别的更好的办法来实现你的目的。在队列表的案例中，可以直接使用UPDATE来更新记录，然后检查是否还有其他的记录需要处理。先建立如下的表:
```sql
CREATE TABLE unsent_emails (
id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
`status` ENUM ( 'unset', 'claimed', 'sent' ),
`owner` INT UNSIGNED NOT NULL DEFAULT 0,
ts TIMESTAMP,
KEY ( owner,status, ts )
);
```

该表的列owner用来存储当前正在处理这个记录的连接ID，即由函数CONNECTION_ID()返回的ID。如果当前记录没有被任何消费者处理，则该值为0.我们经常看到的一个办法是，如下面所示的一次处理10条记录:
```sql
BEGIN;
SELECT
id
FROM
unsent_emails
WHERE
`owner` = 0
AND `status` = 'unsent'
LIMIT 10 FOR UPDATE;-- result : 123,456,789
UPDATE unsent_emails
SET STATUS = 'claimed',
`owner` = CONNECTION_ID()
WHERE
id IN ( 123, 456, 789 );
COMMIT;
```
看到这里的SELECT查询可以使用索引的两个列，因此理论上查找的效率应该更快。问题是，在上面两个查询之间的"间隙时间"，这里的锁会让所有其他同样的查询全部被阻塞。所有的这样的查询将使用相同的索引，扫描索引相同的部分，所以很可能会被阻塞。如果该进程下面的写法，则会更加高效:

```sql
SET AUTOCOMMIT = 1;
COMMIT;
UPDATE unsent_emails
SET `status` = 'claimed', `owner` = CONNECTION_ID()
WHERE `owner` = 0 AND `status` = 'unsent'
LIMIT 10;
SET AUTOCOMMIT = 0;
SELECT id FROM unsent_emails
WHERE `owner`=CONNECTION_ID() AND `status` = 'claimed';
-- result:123,456,789
```
根本就无须使用SELECT查询去找到哪些记录还没有被处理。客户端的协议会告诉你更新了几条记录，所以可以直到这次需要处理多少条记录。所有的
SELECT FOR UPDATE都可以使用类似的办法改写。最后还需要处理一种特殊情况:那些正在被进程处理，而进程本身却由于某种原因退出的情况。这种情况处理起来很简单。你只需要定期运行UPDATE语句将它都更新成原始状态就可以了，然后执行SHOW PROCESSLIST,获取当前正在工作的线程ID,并使用一些WHERE条件避免取到那些刚开始处理的进程。假设我们获取的线程ID有(10、20、30),下面的更新语句会将处理时间超过10分钟的记录状态都更新成初始化状态:
```sql
UPDATE unsent_emails
SET `owner` = 0, `status` = 'unsent'
WHERE `owner` NOT IN (0,10,20,30) AND `status` = 'claimed'
AND ts  < CURRENT_TIMESTAMP - INTERVAL 10 MINUTE;
```
另外，注意看看是如何巧妙地设计索引让这个查询更加高效的。因为我们将范围条件放在WHERE条件的末尾，这个查询恰好能够使用索引的全部列。其他的查询也都能用上这个索引，这就避免了再新增一个额外的索引来满足其他的查询。
这里我们将总结一下这个案例中的一些基础原则:
1.尽量少做事，可以的话就不要做任何事情。除非不得已，否则不要使用轮询，因为这会增加负载，而且还会带来很多低产出的工作
2.尽可能快地完成需要做的事情。尽量使用UPDATE 代替先SELECT FOR UPDATE再UPDATE的写法，因为事务提交的速度越快，持有的锁时间就越短，可以大大减少竞争和加速串行执行效率。将已经处理完成和未处理的数据分开，保证数据集足够小
3.这个案例的另一个启发是，某些查询是无法优化的;考虑使用不同的查询或者不同的策略去实现相同的目的。通常对于SELECT FOR UPDATE就需要这样处理。

有时，最好的办法就是将任务队列从数据库中迁移出来。Redis就是一个很好地队列容器，也可以使用memcached来实现。另一个选择是使用Q4M存储引擎，RabbitMQ等其他消息中间件也可以实现类似的功能

自然语言的全文索引。
自然语言搜索引擎将计算每一个文档对象和查询的相关度。这里，相关度是基于匹配的关键词个数，以及关键词在文档中出现的次数。在整个索引中出现次数越少的词语，匹配时的相关度就越高。相反，非常常见的单词将不会搜索，即使不再停用词列表中出现，如果一个词语在超过50%的记录中都出现了，那么自然语言搜索不会搜索这类词语(在测试使用的一个常见错误就是，只是用很小的数据结合进行全文索引，所以总是无法返回结果，原因在于，每隔搜索u干建祠都可能在一半以上的记录里面出现过)。
全文索引的语法和普通查询略有不同。可以根据WHERE子句中的MATCH AGAINST来区分查询是否使用全文索引。我们来看一个示例。在标准的数据库Sakila中，数据表film_text在字段title和description上建立了全文索引:如图所示。下面时一个使用自然语言搜索的查询:
```sql
mysql> SELECT film_id, title, RIGHT(description ,25),
    -> MATCH (title, description) AGAINST('factory casualties') AS relevance
    -> FROM sakila.film_text
    -> WHERE MATCH(title, description) AGAINST('factory casualties');
+---------+-----------------------+---------------------------+-------------------+
| film_id | title                 | RIGHT(description ,25)    | relevance         |
+---------+-----------------------+---------------------------+-------------------+
|     831 | SPIRITED CASUALTIES   | a Car in A Baloon Factory | 8.640907287597656 |
|     126 | CASUALTIES ENCINO     | Face a Boy in A Monastery | 6.364917278289795 |
|     193 | CROSSROADS CASUALTIES | a Composer in The Outback | 6.364917278289795 |
|       3 | ADAPTATION HOLES      | rjack in A Baloon Factory | 2.275989532470703 |
|     103 | BUCKET BROTHERHOOD    | rjack in A Baloon Factory | 2.275989532470703 |
|     110 | CABIN FLASH           | Shark in A Baloon Factory | 2.275989532470703 |
|     186 | CRAFT OUTFIELD        | rator in A Baloon Factory | 2.275989532470703 |
|     187 | CRANES RESERVOIR      | ogist in A Baloon Factory | 2.275989532470703 |
|     291 | EVOLUTION ALTER       | lorer in A Baloon Factory | 2.275989532470703 |
|     299 | FACTORY DRAGON        | jack in The Sahara Desert | 2.275989532470703 |
|     345 | GABLES METROPOLIS     |  Chef in A Baloon Factory | 2.275989532470703 |
|     365 | GOLD RIVER            | ntist in A Baloon Factory | 2.275989532470703 |
|     369 | GOODFELLAS SALUTE     | d Cow in A Baloon Factory | 2.275989532470703 |
|     370 | GORGEOUS BINGO        | tress in A Baloon Factory | 2.275989532470703 |
```
MySQL将搜索词语分成两个独立的关键词进行搜索，搜索在title和description字段组成的全文索引上进行。注意，只有一条记录同时包含全部的两个关键词，查询结果时根据与关键词的相似度来进行排序的。(和普通查询不同，这类查询自动按照相似度进行排序。在使用全文索引进行排序的时候，MySQL无法再使用索引排序。所以如果不想使用文件排序的话，那么就不要在查询中使用ORDER BY 子句)。从上面的例子中可以看到，函数MATCH()将返回关键词匹配的相关度，是一个浮点数字。你可以根据相关度进行匹配，或者将词直接展现给用户。在一个查询中使用两次MATCH()函数并不会有额外的消耗，MySQL会自动识别并只进行一次搜索。不过，如果你将MATCH()函数放在ORDER  BY 子句中，MySQL将会使用文件排序。在MATCH()函数中指定的列必须和在全文索引中指定的列完全相同，否则就无法啊使用全文索引。这是因为全文索引不会记录关键字是来自哪一列的。这也意味着无法使用完全索引来查询某个关键字是否在某一列上存在。这里介绍一个绕过该问题的办法:根据关键词在多个不同列的全文索引上的相关度来算出排名值，然后依次来排序。我们可以在某一列上加上如下索引:
```sql
mysql>ALTER TABLE film_text ADD FULLTEXT KEY(title);
```
这样，我们可以将title匹配乘以2来提高它的相似度的权重:
```sql
mysql> SELECT film_id, RIGHT ( description, 25 ), ROUND( MATCH ( title, description ) AGAINST ( 'factor casualties' ), 3 ) AS full_rel, ROUND( MATCH ( title ) AGAINST ( 'factory
casualties' ), 3 ) AS title_rel FROM sakila.film_text  WHERE MATCH ( title, description ) AGAINST ( 'factory casualties' )  ORDER BY (2 * MATCH ( title ) AGAINST ( 'factory casualties' )) DESC;
+---------+---------------------------+----------+-----------+
| film_id | RIGHT ( description, 25 ) | full_rel | title_rel |
+---------+---------------------------+----------+-----------+
|     299 | jack in The Sahara Desert |    0.000 |     9.000 |
|     831 | a Car in A Baloon Factory |    6.365 |     6.365 |
|     126 | Face a Boy in A Monastery |    6.365 |     6.365 |
|     193 | a Composer in The Outback |    6.365 |
```
因为上面的查询需要做文件排序，所以这并不是一个高效的做法

布尔全文索引。
在布尔搜索中，用户可以查询中自定义某个被搜索的词语的相关性。布尔搜索通过停用词列表过滤掉那些"噪声"词，除此之外，布尔搜索还要求搜索关键词长度必须大于ft_min_word_len，同时小于ft_max_word_len（事实上，全文索引根本不会对太短或者太长的词语进行索引，但是这里说的不是一回事。一般地，MySQL本身并不会因为搜索关键词过长或过短而忽略这些词语，但是查询优化器的某些部分却可能这样做）。搜索返回的结果是未经排序的。当编写一个布尔搜索查询时，可以通过一些前缀修改时符来定制搜索，表中列出了最常用的修饰符。如表所示。还可以使用其他的操作，例如使用括号分组。基于此，就可以构造出一些复杂的搜索查询。还是继续使用sakila.film_text来举例，现在我们需要搜索既包含词"factory"又包含"casualties"的记录。在前面我们已经使用自然语言搜索查询实现找到这两个词中的任何一个SQL写法。使用布尔搜索查询，我们可以指定返回结果必须同时包含"factory"和"casualties":
```sql
mysql> SELECT film_id, title, RIGHT(description, 25) FROM sakila.film_text WHERE MATCH(title, description) AGAINST ('+factory +casualties' IN BOOLEAN MODE);
+---------+---------------------+---------------------------+
| film_id | title               | RIGHT(description, 25)    |
+---------+---------------------+---------------------------+
|     831 | SPIRITED CASUALTIES | a Car in A Baloon Factory |
+---------+---------------------+---------------------------+
1 row in set (0.00 sec)
```
查询中还可以使用括号进行"短语搜索"，让返回结果精确匹配指定的短语:
```sql
mysql> SELECT film_id,title, RIGHT(description, 25) FROM sakila.film_text WHERE MATCH(title, description) AGAINST ('"spirited casualties"' IN BOOLEAN MODE);
+---------+---------------------+---------------------------+
| film_id | title               | RIGHT(description, 25)    |
+---------+---------------------+---------------------------+
|     831 | SPIRITED CASUALTIES | a Car in A Baloon Factory |
+---------+---------------------+---------------------------+
1 row in set (0.00 sec)
```
短语搜索的速度会比较慢。只使用全文索引是无法判断是否精确匹配短语的，通常还需要查询原文确定记录中是否包含完整的短语。由于需要进行回表过滤，所以速度会比较慢慢。要完成上面的查询，MySQL需要先从索引中找出所有同时包含"spirited"和"casualties"的索引条目，然后取出这些记录再判断是否精确匹配短语，因为这个操作会先从索引中过滤出一些记录，所以通常认为这样做的速度是很快的——比LIKE操作要快很多。事实上，这样做的确很快，但是搜索的关键词不能是太常见的词语。如果搜索的关键词太常见，因为前一步的过滤会返回太多的记录需要判断，因此LIKE操作反而更快。这种情况下LIKE操作是完全的顺序读，相比索引返回值的随机读。会快很多。只有MyISAM引擎才能使用布尔全文索引，但并不是一定要有全文索引才能使用布尔全文搜索。当没有全文搜索的时候，MySQL就通过全表扫描来实现。所以，你甚至还可以在多表上使用布尔全文索引，例如在一个关联结果上进行。只不过，因为是全表扫描速度可能会很慢

MySQL5.1中全文索引的变化。
在MySQL5.1中引入了一些和全文索引相关的改进，包括一些性能上的提升和新增插件式的解析，通过此用户可以自己定制增强搜索功能。例如，插件可以该笔那索引文本的方式。可以用更灵活的方式进行分词（例如，可以指定C++作为一个单独的词语）、预处理可以对不同的文档类型进行索引(如PDF),还可以做一些自定义的词干规则。插件还可以直接影响全文搜索的工作方式——例如，直接使用词干进行搜索。

全文索引的限制和替代方案。
MySQL的全文索引实现有很多的设计本身带来的限制。在某些场景下这些限制是致命的，不过也有很多办法绕过限制。例如，MySQL全文索引中只有一种判断相关性的方法:词频。索引也不会记录索引词在字符串中的位置，所以位置也就无法用在相关性上。虽然大多数情况下，尤其是数据量很小的时候，这些限制都不会影响使用，但也可能不是你锁想要的。而且MySQL的全文索引也没有提供其他可选的相关性排序算法(它无法存储基于相对位置的相关性排序数据)。数据量的大小也是一个问题。MySQL的全文索引只有全部在内存的时候，性能才非常好。如果内存无法装在全部索引，那么搜索速度可能会非常慢。当你使用精确短语搜索时，想要好的性能，数据和索引都需要在内存中。相比其他的索引类型，当INSERT、UPDATE和DELETE操作进行时，全文索引的操作代价都很大:
1.修改一段文本中的100个单词，需要100词索引操作，而不是一次
2.一半来说列长度并不会太影响其他的索引类型，但是如果是全文索引，三个单词的文本和10 000个单词的文本，性能可能会相差几个数量级
3.全文索引会有更多的碎片，可能需要做跟更多的OPTIMIZE TABLE操作

全文索引还会影响查询优化器的工作。索引选择、WHERE子句、ORDER BY都有可能不是按照你所预想的方式来工作:
1.如果查询中使用了MATCH AGAINST子句，而对应列上又有可用的全文索引，那么MySQL就一定会使用这个全文索引。这时，即使有其他列的索引可以使用，MySQL也不会比较到底哪个索引的性能更好。所以，即使这时有更合适的索引可以使用，MySQL仍然会置之不理
2.全文索引只能用作全文搜索匹配。任何其他操作，如WHERE条件比较，都必须在MySQL完成全文搜索返回记录后才能进行。这和其他普通索引不同，例如，在处理WHERE条件时，MySQL可以使用普通索引一次-判断多个表达式。
3.全文索引不存储索引列的实际值。也就不可能用作索引覆盖扫描
4.除了相关行排序，全文索引不能用作其他的排序。如果查询需要做相关性以外的排序操作，都需要使用文件排序。

让我们看看这些限制如何影响查询语句。来看一个例子，假设有一百万个文档记录，在文档的作者author字段上有一个普通的索引，在文档内容字段content上有全文索引。先在我们要搜索作者123，文档中又包含特定词语的文档。很多人可能会按照下面的方式来写查询语句
```sql
... WHERE MATCH(content) AGAINST('High Performance MySQL') AND author = 123;
```
而实际上，这样做的效率非常低。因为这里使用MATCH AGAINST，而且恰好上面有全文索引，所以MySQL优先选择使用全文索引，即先搜索所有的文档，查找是否有包含关键词的文档，然后返回记录看看作者是否是123.所以这里也就没有使用author字段上的索引。一个替代方案时将author列包含到全文索引中。可以在author列的值前面附上一个不常见的前缀，然后将这个带前缀的值存放到一个单独的filters列中，并单独维护该列(也许可以使用触发器来做维护工作)。
```sql
... WHERE MATCH(content, filters) AGAINST ('High Performance MySQL +author_id_123' IN BOOLEAN MODE);
``
这个案例中，如果author列的选择性非常高，那么MySQL能够根据作者信息很快地将需要过滤的文档记录限制在一个很小的范围内，这个查询的效率也就会非常耗。如果author列的选择性很低，那么这个替代方案的效率会比前面那个更糟，所以使用的时候要谨慎。全文索引有时候还可以实现一些简单的"边框"搜索。例如，希望搜索某个坐标范围时，将坐标按某种方式转换成文本再进行全文搜索。假设某条记录的坐标为X=123和Y=456.可以按照这样的方式交错存储坐标XY123456,然后对此进行全文搜索。这时，希望查询某矩形——X取值100至199,Y取值400至499——范围时，可以再查询直接搜索"+XY14*".这比使用WHERE条件过滤的效率要高很多。全文索引的另一个常用技巧时缓存全文索引返回的主键值，这在分页显示的时候经常使用。当应用程序真的需要输出结果时，才通过主键值将所有需要的数据返回。这个查询就可以自由地使用其他索引、或者自由地关联其他表。在早期版本中虽然只有MyISMA表支持全文索引，但是如果仍然希望使用InnoDB或其他引擎，可以将原表赋值到一个备库，再将备库上的表改成MyISAM并建上相应的全文索引。如果不希望再另一个服务器上完成查询，还可以对表进行垂直拆分，将需要索引的列放到一个单独的MyISAM表中。将需要索引的列额外地冗余再另一个MyISAM表中也是一个办法。再测试库sakila.film_text就是使用这个策略，这里使用触发器来维护这个表的数据。最后，你还可以使用一个包含内置全文索引的引擎，，如Lucene或者Sphinx。因为使用全文索引的时候，通常会返回大量结果并产生大量随机IO,如何和GROUP BY 一起使用的话，还需要通过临时表或者文件排序进行分组，性能会非常非常糟糕。这类查询通常只是希望查询分组后的前几名结果，所以一个有效的优化办法是对结果进行抽样而不是精确计算。例如，仅查询前面的
1 000条记录，进行分组并返回前几名的结果。

全文索引的配置和优化。
全文索引的日常维护通常能够大大提升性能。"双B-Tree"的特殊结构、再某些文档中比其他文档要包含多得多的关键字，这都使得全文索引比起普通索引有更多的碎片问题，所以需要经常使用OPTIMIZE TABLE来减少碎片。如果应用时IO密集型的，那么定期地进行全文索引重建可以让性能提升很多。如果希望全文索引能够高效地工作，还需要保证索引缓存足够大，从而保证所有的全文索引都能够缓存在内存中。通常，可以为全文索引设置单独的键缓存(Key Cache),保证不会被其他的索引缓存挤出内存。
提供一个好的停用词表也很重要。默认的停用词表对常用英语来说可能还不错，但是如果时其他语言或者某些专业文档就不合适了，例如技术文档。例如，若要索引一批MySQL相关的文档，那么最好将mysql放入停用词表，因为在这类文档中，这个词会出现得非常频繁。忽略一些太短的单词也可以提升全文索引的效率。索引单词的最小长度可以通过参数ft_min_word_len配置。修改该参数可以过滤更多的单词，让查询速度更快，但是也会降低精确度。还需要注意一些特殊的而场景，有时确实需要索引某些非常短的词语。例如，对一个电子消费品文档进行索引，除非我们允许对很短的单词进行索引，否则搜索
"cd player"可能会返回大量的结果。因为单词"cd"比默认允许的最短长度4还要小，所以这里只会对"Player"进行搜索，而通常搜索"cd player"的客户，其实对MP3或者DVD播放器并不感兴趣。停用词表和最小词长都可以通过减少索引词语来提升全文索引的效率，但是同时地也会降低搜索的精确度。这需要根据实际的应用场景找到合适的平衡点。如果你希望同时获得好的性能和好的搜索质量，那么需要自己定制这些参数。一个好的办法时通过日志系统来研究用户的搜索行为，看看一些异常的查询，包括没有结果返回的查询或者返回过多结果的用户查询。通过这些用户行为和被搜索的内容来判断应该如何调整索引策略。
(需要注意，当调整"允许最小词长"后，需要通过OPTIMIZE TABLE来重建索引才会生效。另一个参数ft_max_word_len和该参数行为类似，它限制了允许索引的最大词长)。
当向一个有全文索引的表中导入大量数据的时候，最好先通过命令DISABLE KEYS来禁用全文索引，然后再导入结束后使用ENABLE KEYS来建立全文索引。因为全文索引的更新是一个消耗很大的操作，所以上面的细节会帮你节省大量时间。另外，这样还顺便为全文索引做了一次碎片整理工作。如果数据集特别大，则需要对数据进行手动分区，然后将数据分布到不同的节点，再做并行的搜索。这是一个复杂的工作，最好通过一些外部的搜索引擎来实现，如Lucene或者Sphinx，经验显示这样做性能会有指数级的提升

内部XA事务。
MySQL本身的插件式架构导致在其内部需要使用XA事务。MySQL中各个存储引擎是完全独立的，彼此不知道对方的存在，所以一个跨存储引擎的事务就需要一个外部的协调者，如果不使用XA协议，例如，跨存储引擎的事务提交就只是顺序地要求每个存储引擎各自提交。如果在某个存储提交过程中发生系统崩溃，就会破坏事务的特性(要么全部提交，要么就不做任何操作)如果将MySQL记录的二进制日志操作看作一个独立的"存储引擎"，就不难理解为什么即使是一个存储引擎参与的事务仍然需要XA事务了。在存储引擎提交的同时，需要将"提交"的信息写入二进制日志，这就是一个分布式事务，只不过二进制日志的参与者是MySQL本身。XA事务为MySQL带来巨大的性能下降。从MySQL5.0开始，它破坏了MySQL内部的"批量提交"()一种通过单磁盘IO操作完成多个事务提交的技术)，使得MySQL不得不进行多次额外的fsync()调用。具体的，一个事务如果开启了二进制日志，则不仅需要对二进制日志进行持久化操作，InnoDB事务日志还需要两次日志持久化操作。换句话说，如果希望有二进制日志安全的事务实现，则至少需要做三次fsync()操作。唯一避免这个问题的办法就是关闭二进制日志，并将innodb_support_xa设置为0.(一个常见的误区是认为innodb_support_xa只有在需要XA事务的时候才需要打开。这是醋无的:该参数还会控制MySQL内部存储引擎和二进制日志之间的分布式事务。如果你真正关心你的数据，你需要将这个参数打开)。
但这样的设置是非常不安全的，而且这回导致MySQL赋值也没法正常工作。复制需要二进制日志和XA事务的支持，另外——如果希望数据尽可能安全——最好还要将sync_binlog设置成1， 这时存储引擎和二进制日志才是真正同步的(否则，XA事务支持就没有意义了，因为事务提交了二进制日志却可能没有"提交"到磁盘)。这也是为什么强烈建议使用带电池保护的RAID卡写缓存:这个缓存可以大大加快fsync()操作的效率

外部XA事务。
MySQL能够作为参与者完成一个外部的分布式事务。但它对XA协议支持并不完整。例如XA协议要求在一个事务中的多个连接可以做关联，但目前的MysQL版本还不能支持。因为通信延迟和参与者本身可能失败，所以外部XA事务比内部消耗会更大。如果在广域网中使用XA事务，通常会因为不可预测的网络性能导致事务失败。如果有太多不可控因素，例如，不稳定的网络通信或者用户长时间等待而不提交，则最好避免使用XA事务。任何可能让事务提交发生延迟的操作代价都很大,因为它影响的不仅仅是自己本身，它还会让所有参与者都在等待。
通常，还可以使用别的方式实现高性能的分布式事务。例如，可以在本地写入数据，并将其放入队列，然后在一个更小、更快的事务中自动分发。还可以使用MySQL本身的复制机制来发送数据。我们看到很多应用程序都可以完全彼岸使用分布式事务。也就是说，XA事务是一种在多个服务器之间同步的方法。如果由于某些原因不能使用MySQL本身的复制，或者性能并不是瓶颈的时候，可以尝试使用。

MySQL如何判断缓存命中。
MySQL判断缓存命中的办法很简单:缓存放在一个引用表，通过一个哈希值引用，整个哈希值包括了如下因素，即查询本身、当前要查询的数据库、客户端协议的版本等一些其他可能会影响返回结果的信息。当判断缓存是否命中时，MySQL不会解析、"正规化"或者参数化查询语句，而是直接使用SQL语句和客户端发送过来的其他原始信息。任何字符上的不同，例如空格、注释——任何的不同——都会导致缓存的不命中。(对于这个规则，Percona Server是个例外。它会先将所有的注释语句删除，然后再比较查询语句是否有缓存。这是一个通用的需求，这样可以在查询语句中带入更多的处理过程信息)。所以在编写SQL语句的时候，需要特别注意这点。通常使用统一的编码规则是一个好的习惯，在这里这个好习惯会让你系统运行得更快。当查询语句中有一些不确定的数据时，则不会被缓存。例如包含函数NOW()或者CURRENT_DATE()的查询不会被缓存。类似的，包含CURRENT_USER或者CONNECTION_ID()的查询语句因为会根据不同的用户返回不同的结果，所以也不会被缓存。事实上，如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、mysql库中的系统表，或者任何包含列级别权限的表，都不会被缓存。
我们常听到:"如果查询中包含一个不确定的函数，MySQL则不会检查查询缓存"。这个说法是不正确的。因为在检查查询缓存的时候，还没有解析SQL语句，所以MySQL并不知道查询语句中是否包含这类函数。在检查查询缓存之前，MySQL只做一件事情，就是通过一个大小写不敏感的检查看看SQL语句是不是以SEL开头。准确的说法应该是:"如果查询语句中包含任何的不确定函数，那么在查询缓存中是不可能找到缓存结果的"。因为即使之前刚刚执行了这样的查询，结果也不会放在查询缓存中。MySQL在任何时候只要发现不能被缓存的部分，就会禁止这个查询被缓存。所以，如果希望换成一个带日期的查询，那么最好将日期提前计算好，而不是直接使用函数。例如:
```sql
... DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY) -- Not cacheable!
... DATE_SUB('2007-07-14', INTERVAL 1 DAY) -- Cacheable
```
因为查询缓存是在完整的SELECT语句基础上的，而且只是在刚刚收到SQL语句的时候才检查，所以子查询和存储过程都没办法使用查询缓存。在MySQL5.1之前的版本中，绑定变量也无法使用查询缓存。MySQL的查询缓存在狠毒哦时候可以提升查询性能，在使用的时候，有一些问题需要特别注意。手下你打开查询缓存对读和写操作都会带来额外的消耗:
1.读查询在开始之前必须先检查是否命中缓存
2.如果这个读查询可以被缓存，那么当完成执行后，MSQL若发现查询缓存中没有这个查询，会将其结果存入查询缓存，这回带来额外的系统消耗
3.这对写操作也会有影响，因为当向这某个表写入数据的时候，MySQL必须将对应表的所有缓存都设置失效。如果查询缓存非常大或者碎片很多，这个操作就可能带来很大系统消耗(设置了很多的内存给查询缓存用的时候).
虽然如此，查询缓存仍然可能给系统带来性能提升。但是，如上所述，这些额外的消耗也可能不断增加，再加上对查询缓存操作是一个加锁排他操作，这个消耗可能不容小觑。对InnoDB用户来说，事务的一些特性会限制查询缓存的使用。当一个语句再事务中修改了某个表，MySQL会将这个表对应的查询缓存都设置失效，而事实上，InnoDB的多版本特性会暂时将这个修改对其他事务屏蔽。在这个事务提交之前，这个表的相关查询是无法被缓存的，所以所有在这个表上的查询——内部或外部的事务——都只能在该事务提交后才能被缓存。因此，长事件运行的事务，会大大降低查询缓存的命中率。
如果查询缓存使用了很大量鞥多内存，缓存失效操作就可能成为一个非常严重的问题瓶颈。如果缓存中存放了大量的查询结果，那么缓存失效操作时整个系统都可能会僵死一会儿。因为这个操作是靠一个全局锁操作保护的，所有需要做该操作的查询都要等待这个锁，而且无论是检测是否命中缓存、还是缓存失效检测都需要等待这个全局锁。

查询缓存如何使用内存。
查询缓存是完全存储在内存中的，所以在配置和使用它之前，我们需要先了解它是如何使用内存的。除了查询结果之外，需要缓存的还有很多别的维护相关的数据。这和文件系统有些类似：需要一些内存专门用来确定哪些内存目前是可用的、哪些是已经用掉的、哪些用来存储数据表和查询结果之前的映射、哪些用来存储查询字符串和查询结果。这些基本的管理维护数据结构大需要需要40KB的内存资源，除此之外，MySQL用于查询缓存的内存被分成一个个的数据块，数据块是变长的。每一个数据块中，存储了自己的类型、大小和存储的数据本身，还外加指向前一个和后一个数据块的指针。数据块的类型有:存储查询结果、存储查询和数据表的映射、存储查询文本，等等。不同的存储快，在内存使用上并没有什么不同，从用户角度来看无须区分它们。当服务器启动的时候，它先初始化查询缓存需要的内存。这个内存池初始是一个完整的空闲块。这个空闲块的大小就是你所配置的查询缓存大小再减去用于维护元数据的数据结构所消耗的空间。当有查询结果需要缓存的时候，MySQL先从大的空间块中申请一个数据块用于存储结果。这个数据块需要大于参数query_cache_min_res_unit的配置，即使查询结果远远小于此，仍需要至少申请query_cache_min_res_unit空间。因为需要在查询开始返回结果的时候就分配空间，而此时是无法预知查询结果到底多大的，所以MySQL无法为每一个查询结果精确分配大小恰好匹配的缓存空间。
因为需要先锁住空间块，然后找到合适大小数据块，所以相对来说，分配内存块是一个非常慢的操作。MySQL尽量避免这个操作的次数。当需要缓存一个查询结果的时候，它先选择一个尽可能小的内存块(也可能选择较大的)，然后将结果存入其中。如果数据块全部用完，但仍有剩余数据需要存储，那么MySQL会申请一块新数据块——仍然是尽可能小的数据块——继续存储结果数据。当查询完成时，如果申请的内存空间还有剩余，MySQL会将其释放，并放入空闲内存部分。该过程如图所示。
我们上面说的"分配内存块"，并不是指通过函数malloc()向操作系统申请内存，这个操作只在初次创建查询缓存的时候执行一次。这里"分配内存块"是指在空闲块列表中找到一个合适的内存块，或者从正在使用的、待淘汰的内存块中回收再使用。也就是说这里MySQL自己管理一大块内存，而不依赖操作系统的内存管理。至此，一些都看起来很简单。不过实际情况要比上图更复杂。例如，我们假设平均查询结果非常小，服务器在并发地向不同的两个连接返回结果，返回完结果MySQL回收剩余数据块空间时发现，回收的数据块小于query_cache_min_res_unit，所以不能够直接在后续的内存块分配中使用。如果考虑到这种情况，数据块的分配就更复杂些，

什么情况下查询缓存能发挥作用。
并不是什么情况下查询缓存都会提高系统性能的。缓存和失效都会带来额外的消耗，所以只有当缓存带来的资源节约大于本身的资源消耗时才会给系统带来性能提升。这跟具体的服务器压力模型有关。理论上，可以通过观察打开或者关闭查询缓存时候的系统效率来决定是否需要开启查询缓存。关闭查询缓存时，每个查询都需要完整的执行，每一次写操作执行完成后立刻返回；打开查询缓存时，每次读请求先检查缓存是否命中，如果命中则立刻返回，否则就完整地执行查询，每次写操作则需要检查查询缓存中是否有需要失效的缓存，然后再返回。这个过程还比较简单明了，但是要评估打开查询缓存是否能够带来性能提升却并不容易。还有一些外部的因素需要考虑，例如，查询缓存可以降低查询执行的时间，但是却不能减少查询结果传输的网络消耗，如果这个消耗是系统的主要瓶颈，那么查询缓存的作用也很小。
因为MySQL再SHOW STATUS中只能提供一个全局的性能指标，所以很难根据此来判断查询缓存是否能够提升性能(Percona和MariaDB对MySQL慢日志进行了改进，会记录慢日志中的查询是否命中查询缓存)。很多时候，全局平均不能反应实际情况。例如，打开查询缓存可以使得一个很慢的查询变得非常快，但是也会让其他查询稍微慢一点点。有时候如果能够让某些关键的查询速度更快，稍微降低一下其他查询的速度是值得的。不过这种情况我们推荐使用SQL_CACHE来优化对查询缓存的使用。
对于哪些需要消耗大量资源的查询通常都是非常适合缓存的。例如一些汇总计算查询，具体的如COUNT()等。总的来说，对于复杂的SELECT语句都可以使用查询缓存，例如多表JOIN后还需要做排序和分页，这类查询每次执行消耗都很大，但是返回的结果集却很小，非常适合查询缓存。不过需要注意的是，涉及的表上UPDATE、DELETE和INSERT操作相比SELECT来说要非常少才行。
一个判断查询缓存是否有效地直接数据是命中率，就是使用查询缓存返回结果占总查询的比率。当MySQL接收到一个SELECT查询的时候，要么增加Qcache_hits的指，要么增加Com_select的值。所以查询缓存命中率可以由如下公式计算:Qcache_hits/(Qcache_hits+Com_select)
不过，查询缓存命中率是一个很难判断的数值。命中率多大才是好的命中率？具体情况要具体分析。只要查询缓存带来的效率提升大于查询缓存带来的额外消耗，即使30%命中率对系统性能提升也有很大好处。另外，缓存了哪些查询也很重要，例如，被缓存的查询本身消耗非常巨大，那么即使缓存命中率非常低，也仍然会对系统性能提升有好处。所以，没有一个简单的规则可以判断查询缓存是否对系统有好处。
任何SELECT语句没有从查询缓存中返回都成为"缓存未命中"。缓存未命中可能有如下几种原因:
1.查询语句无法被缓存，可能是因为查询种包含一个不确定的函数(如CURRENT_DATE)，或者查询结果太大而无法缓存。这都会导致状态值Qcache_not_cached增加
2.MySQL从未处理这个查询，所以结果也从不曾被缓存过
3.还有一种情况是虽然之前缓存了查询结果，但是由于查询缓存的内存用完了，MySQL需要将某些缓存"逐出"，或者由于数据表被修改导致缓存失效。
如果你的服务器上有大量缓存未命中，但是实际上绝大数查询都被缓存了，那么一定是有如下情况发生:
1.查询缓存还没有完成预热。也就是说，MySQL还没有机会将查询结果都缓存起来。
2.查询语句之前从未执行过，如果你的应用程序不会重复执行一条查询语句，那么即使完成预热仍然会有很多缓存未命中
3.缓存失效操作太多了
缓存碎片、内存不足、数据修改都会造成缓存失效。如果配置了足够的缓存空间，而且query_cache_min_res_unit设置也合理的化，那么缓存失效应该主要是数据修改导致的。可以通过参数Com_*来查看数据修改的情况(包括Com_update,Com_delete，等等)，还可以通过Qcache_lowmem_prunes来查看多少次失效是由于内存不足导致的。
在考虑缓存命中率的同时，通常还需要考虑缓存失效带来的额外消耗。一个极端的办法是，对某一个表先做一次只有查询的测试，并且所有的查询都命中缓存，而另一个相同的表只做修改操作。这是，查询缓存的命中率就是100%。但因为会给更新操作带来额外的消耗，所以查询缓存并不一定会带来总体效率的提升。这里，所有的更新语句都回做一次缓存失效检查，而检查的结果都是相同的，这会给系统带来额外的资源浪费。所以，如果你只是观察查询缓存的命中率的话，可能完全不会发现这样的问题。
在MySQL张入股更新操作和带缓存的读操作混合，那么查询缓存带来的好处通常很难很亮。更新操作会不断地使得缓存失效，而同时每次查询还会像缓存中再写入新的数据。所以甚至有当后续的查询能够在缓存失效前使用缓存才会有效地利用查询缓存。

如何配置和维护查询缓存。
一旦理解查询缓存工作的原理，配置起来就很容了。它也只有少数的参数可供配置。如下所示:
1.query_cache_type
是否打开查询缓存。可以设置成OFF、ON或DEMAND。DEMAND表示只有在查询语句中明确写明SQL_CACHE的语句才放入查询缓存。这个变量可以是会话级别的也可以是全局级别的
2.query_cache_size
查询缓存使用的总内存空间，单位是字节。这个值必须是1024的整数倍,否则MySQL实际分配的数据会和你指定的略有不同
3.query_cache_min_res_unit
在查询缓存中分配内存块时的最小单位。
4.query_cache_limit
MySQL能够缓存的最大查询结果。如果查询结果大于这个值，则不会被缓存。因为查询缓存在数据生成的时候就开始尝试缓存数据，所以只有当结果全部返回后，MySQL才直到查询结果是否超出限制。如果超出，MySQL则增加状态值Qcache_not_cached,并将结果从查询缓存张删除。如果你事先直到有很多这样的情况发生，那么建议在查询语句中加入SQL_NO_CACHE来避免查询缓存带来的额外消耗
5.query_cache_wlock_invalidate
如果某个数据表被其他的连接锁住，是否仍然从查询缓存中返回结果。这个参数默认是OFF,这可能在一定程序上会改变服务器的行为，因为这使得数据库可能返回其他线程锁住的数据，将参数设置成ON,则不会从缓存中读取这类数据，但是这可能会增加锁等待。对于绝大数应用来说无须注意这个细节，所以默认设置通常是没有问题的。

配置查询缓存通常很简单，但是如果想直到修改这些参数会带来哪些改变，则是一项很复杂的工作。

InnoDB和查询缓存。
因为InnoDB有自己的MVCC机制，所以相比其他存储引擎，InnoDB和查询缓存的交互要更加复杂。MySQL4.0版本中，在事务处理中查询缓存是被禁用的，从4.1和更新的InnoDB版本开始，InnoDB会控制在一个事务中是否可以使用查询缓存，InnoDB会同时控制对查询缓存的读(从缓存中获取查询结果)和写操作(向查询缓存写入结果)。事务是否可以访问查询缓存取决于当前事务ID,以及对应的数据表上是否有锁。每一个InnoDB表的内存数据字典都保存了一个事务ID号，如果当前事务ID小于该事务ID,则无法访问查询缓存。如果表上有任何的锁，那么对这个表的任何查询语句都是无法被缓存的。例如，某个事务执行了SELECT FOR UPDATE语句，那么在这个锁释放之前，任何其他的事务都无法从查询缓存中读取与这个表相关的缓存结果。当事务提交时，InnoDB持有锁，并使用当前的一个系统事务ID更新当前表的计数器。锁一定程度上说明事务需要对表进行修改操作，当然有可能事务获得锁，却不进行任何更新操作，但是如果想要更新任何表的内容，获得相应锁则是前提条件。InnoDB将每个表的计数器设置成某个事务ID,而这个事务ID就代表了当前存在的且修改了该表的最大的事务ID.那么下面的一些事实也就成立:
1.所有大于该表计数器的事务才可以使用查询缓存。例如当前系统系统的事务ID是5，且事务获取了该表的某些记录的锁，然后进行事务提交操作，那么事务1至4，都不应该再读取或者向查询缓存写入任何相关的数据
2.该表的计数器并不是直接更新为对该表进行加锁的事务ID,而是被更新成一个系统事务ID,而是被更新成一个系统事务ID.搜易，会发现该事务自身后续的更新操作也无法读取和修改查询缓存。

查询缓存存储、检索和失效操作都是在MySQL层面完成，InnoDB无法绕过或者延迟这个行为。但InnoDB可以在事务中显式地告诉MySQL何时应该让讴歌表地查询缓存都失效。在有外键限制地时候这是必须地，例如某个SQL语句有ON DELEETE CASCADE那么相关关联表地查询缓存也是要一起失效的。
原则上，在InnoDB的MVCC架构下，当某些修改不影响其他事务读取一致的数据时，是可以使用查询缓存的。但是这样实现起来会非常复杂，InnoDB做了一个简化，让所有有加锁操作的事务都不适用任何查询缓存，这个限制其实并不是必须的。

通用查询缓存优化。
库表结构的涉及、查询语句、应用程序涉及都可能会影响到查询缓存的效率。除了前面的介绍之外，还有一些要点需要注意:
1.用多个淆表代替一个大表对查询缓存有好处。这个涉及将会使得失效策略能够在一个更合适的粒度上进行。当然，不要让这个原则过分影响你的涉及，毕竟其他的一些有时可能很容易就弥补了这个问题
2.批量写入时只需要做一次缓存失效，所以相比单条写入效率更好(另外需要注意，不要同时做延迟写和批量写，否则可能会因为失效导致服务器僵死较长时间)
3.因为缓存空间太大，在过期操作的时候可能会导致服务器僵死。一个简单的解决办法就是控制缓存空间的大小(query_cache_size)或者直接禁用查询缓存
4.无法在数据库或者表级别控制查询缓存，但是可以通过SQL_CACHE和SQL_NO_CACHE来控制某个SELECT语句是否需要进行缓存。你还可以通过修改会话级别的变量query_cache_type来控制查询缓存
5.对于写密集型的应用来说，直接禁用查询缓存可能会提高系统的性能。关闭查询缓存可以移除所有相关的消耗。例如将query_cache_size设置成0，那么至少这部分就不再消耗任何内存了
6.因为对互斥信号量的竞争，有时直接关闭查询缓存对读密集型的应用也会有好处。如果你希望提高系统的并发，那么最好做一个相关的测试，对比打开和关闭查询缓存时候的性能差异。

如果不像所有的查询都进入查询缓存，但是有希望某些查询走查询缓存，那么可以将query_cache_type设置成DEMAND，然后在希望缓存的查询中加上SQL_CACHE，这虽然需要在查询中加入一些额外的语法，但是可以让你非常自由地控制哪些查询需要被缓存。相反，如果希望缓存多数查询，而少数查询又不希望缓存，那么你可以使用关键字SQL_NO_CACHE

查询缓存的替代方案。
MySQL查询缓存工作的原则是：执行查询最快的方式就是不执行，但是查询仍然需要发送到服务器，服务器也还需要做一点点工作。如果对于某些查询完全不需要与服务器通信效果会如何呢？这是客户端的缓存可以很大程度上帮你分担MySQL服务器的压力。

InnoDB的IO配置.
InnoDB不仅允许控制怎么恢复，还允许控制怎么打开和刷新数据(文件)，这会对恢复和整体性能产生巨大的影响。尽管可以影响它的行为，InnoDB的恢复流程实际上是自动的，并且经常在InnoDB启动时运行。撇开恢复并假设InnoDB没有崩溃或者出错，InnoDB依然有很多需要配置的地方。它有一系列复杂的缓存和文件涉及可以提升性能，以及保证ACID特性，并且每一部分都是可配置的，如图所示。对于常见的应用，最重要的一小部分内容是InnoDB日志文件大小、InnoDB怎样刷新它的日志缓冲，以及InnoDB怎样执行IO.

MyISAM的IO配置。
让我们从分析MyISAM怎么为索引操作IO开始。MyISAM通常每次操作之后就把索引变更刷新磁盘。如你打算在一张表上做很多修改，那么毫无疑问，批量操作会更快一些，一种办法是用LOCK TABLES延迟写入，知道解锁这些表。这是个提升性能的很有价值的技巧，因为它使得你精确控制哪些写被延迟，以及什么时候把它们刷到磁盘。可以精确延迟那些希望延迟的语句。
通过设置delay_key_write变量，也可以延迟索引的写入。如果这么做，修改的键缓冲块直到表被关闭才会刷新。(表可能因为多种原因被关闭。例如，服务器因为表缓存没有空间了就会关闭表，或者有人执行了FLUSH TABLES).可能的配置如下:
1.OFF
MyISAM每次写操作后刷新键缓冲(键缓存，Key Buffer)中的脏块到磁盘，除非表被LOCK TABLES锁定了
2.ON
打开延迟键写入，但是只对用DELAY_KEY_WRITE选项创建的表有效
3.ALL
所有的MyISAM表都会使用延迟键写入

延迟键写入在某些场景下可能很有帮助，但是通常不会带来很大的性能提升。但键缓冲的杜明中很好但谢明中不好时，数据又比较小，这可能很有用。当然也有一小部分缺点:
1.如果服务器缓存并且块没有被刷到磁盘，索引可能会损坏
2.如果很多写被延迟了,MySQL可能需要花费更长时间去关闭表，因为必须等待缓冲刷新到磁盘。在MySQL5.0这可能引起很长的表缓存锁
3.由于上面提到的原因，FLUSH TABLES可能需要很长时间。如果为了做逻辑卷(LVM)快照或者其他备份操作，而执行FLUSH TABLE WITH READ LOCK，那可能增加操作的时间
4.键缓冲中没有刷灰去的脏块可能占用空间，导致从磁盘上读取的新块没有空间存放，因此，查询语句可能需要等待MyISAM释放一些键缓存的空间。

另外，除了配置MyISAM的索引IO还可以配置MyISAM怎样尝试从损坏中恢复，myisam_recover选项控制MyISAM怎样寻找和修复错误。需要在配置文件或者命令中设置这个选项。可以通过下面的SQL语句查看选项的值，但是不能修改
```sql
mysql>SHOW VARIBLES LIKE 'myisam_recover_options';
```
打开这个选项通知MySQL在表打开时，检查是否损坏，并且在找到问题的时候进行修复。可以设置的值如下:
1.DEFAULT(或者不设置)
使MySQL尝试修复任何被标记为崩溃或者没有标记为完全关闭的表。默认值不要求在恢复时执行其他动作。跟大多数变量不同，这里DEFAULT值不是重置变量的值为编译值，它本质上意味着没有设置
2.BACKUP
让MySQL将数据文件的备份写到.BAK文件，以便随后进行检查
3.QUICK
除非又删除块，否则跳过恢复。块中有已经删除的行也依然会占用空间，但是可以被后面的INSERT语句宠用。这可能比较有用，因为MyISAM大表的恢复可能花费相当长的时间

innodb_old_blocks_time。
InnoDB有两段缓冲池LRU(最近最少使用)链表，设计目的是防止换出长期很多次的页面。像mysqldump产生的这种一次性的(大)查询，通常会读取页面到缓冲池的LRU列表，从中读取需要的行，然后移动到下一页。理论上，两段LRU链表将阻止此页取代很长一段时间内都需要用到的页面被放入"年轻(Young)"子链表，并且只在它被已被浏览过多次后将其移动到"年老(Old)"子链表。但是InnoDB默认没有配置为防止这种情况，因为页内有很多行，所以从页面读取的行的多次访问，会导致它立即被转移到"年老(Old)"子链表，对哪些需要长时间缓存的页面带来换出的压力。这个变量指定一个页面从LRU链表的"年轻"部分转移到"年老"部分之前必须经过的毫秒数。默认情况下将它设置为0，将它设为诸如1000毫秒(一秒)这样的小一点的值，在基准测试中已被证明非常有效。

如何阅读vmstat的输出。
我们先看一个vmstat的例子。用下面的命令让它每5秒钟打印出一个报告:
```c
vmstat 5
```
可以用Ctrl +C停止vmstat，可以看到输出依赖于所用的操作系统，因此可能需要阅读一下手册来解读报告。刚启动不久，即使采用增量报告，第一行的值还是显示自系统启动以来的平均值，第二行展示现在正在发生的情况，接下来的行会展示每5秒的间隔内发生了什么。每一列的含义在头部，如下所示:
1.procs
r这一列展示了多少进程正在等待CPU。b列显示多少进程正在不可中断地休眠(通常意味着它们在等待IO,例如磁盘、网络、用户输入，等等)。
2.memory
swapd列显示多少块被换出到了磁盘(页面交换)/剩下地三列显示了多少块时空闲的(未被使用)、多少块正在被用作缓冲，以及多少正在被用作操作系统的缓存。
3.swap
这些列显示页面交换活动:每秒有多少块正在被换入(从磁盘)和换出(到磁盘)。它们比监控swapd列重要多了。大部分时间我们喜欢看到si和so列时0，并且我们很明确不希望看到每秒超过10个块。突发性的高峰一样很糟糕。
4.io
这些列显示有多少块从块设备读取(bi)和写出(bo)。这通常反应了硬盘IO
5.system
这些列显示了每秒中断(in)和上下文切换(cs)的数量
6.cpu
这些列显示所有的CPU时间花费在各类操作的百分比，包括执行用户代码(非内核)、执行系统代码(内核)、空闲，以及等待IO.如果正在使用虚拟化，则第五个列可能是st,显示了从虚拟机中"偷走"的百分比。这关系到那些虚拟机想运行但是系统管理程序转而运行其他的对象的时间。如果虚拟机不希望运行任何对象，但是系统管理程序运行了其他对象，这不算被偷走的CPU时间

vmstat的输出跟系统有关，所以如果看到跟展示的例子不同的输出，应该阅读系统的vmstat(8)手册。一个重要的提示是:内存、交换区，以及IO统计是块数而不是i字节。在GNU/Linux，块大小通常是1024字节

如何阅读iostat的输出。
现在让我们转移到iostat。默认情况下，它显示了与vmstat相同的CPU使用信息。我们通常只是对IO统计感兴趣，所以使用下面的命令之战是扩展的设备统计:
```c
iostat -dx 5
```
与vmstat一样，第一行报告显示的是自系统启动以来的平均值(通常删掉它节省空间)，然后接下来的报告显示了增量的平均值，每个设备一行。有多种选项显示和隐藏列。官方文档有点难以理解，因此我们必须从源码中挖掘真正显示的内容是什么。说明的列信息如下:
1.rrqm/s和wrqm/s
每秒合并的读和写请求。"合并的"意味着操作系统从队列中拿出多个逻辑请求合并为一个请求到实际磁盘
2.r/s和w/s
每秒发送到设备的读和写请求
3.rsec/s和wsec/s
每秒读和写的扇区数。有些系统也输出为rkB/s和wkB/s，意味着每秒读写的千字节数。为了简洁，省略了那些指标说明。
4.avgrq-sz
请求的扇区数
5.avgqu-sz
在设备队列中等待的请求数
6.await
磁盘队列上花费的毫秒数。很不幸，iostat没有独立统计读和写的请求，它们实际上不应该被一起平均
7.svctm
服务请求花费的毫秒数，不包括排队时间
8.%util
至少有一个活跃请求所占时间的百分比。如果熟悉队列理论张利用率的标准定义，那么这个命名很莫名其妙。它其实不是设备的利用率。超过一块硬盘的设备(例如RAID控制器)比一块硬盘的设备可以支持更高的并发，但是%util从来不会超过100%，除非在计算机时有四舍五入的错误。因此，这个指标无法真实反映设备的利用率，实际上跟文档说的相反，除非只有一块物理磁盘的特殊例子。

可以用iostat的输出推断某些关于机器IO自系统的实际情况。一个重要的度量标准时请求服务的并发数。因为读写的单位时每秒而服务时间的单位是千分之一秒，所以可以利用利特尔法则(Littele's Law)得到下面的公式，计算出设备服务的并发请求数(另一种计算并发的方式是通过平均队列大小、服务时间，以及平均等大i时间:(avuqu_sz * svctm) / await):
```c
concurrency = (r/s + w/s) * (svctm/1000)
```
把数字带入并发公式，可以得到(0.38 + 0.02) * (0.43 / 1000) = 0.000172.由于我这台服务器配置是乞丐版的，所以得到的并发数比较低。这意味着在一个采样周期内，这个设备平均要服务0.000172次的请求。

CPU密集型的机器。
CPU密集型服务器的vmstat输出通常在us列会有一个很高的值，报告了花费在非内核代码上的CPU时钟;也可能在sy列有很高的值，表示系统CPU利用率，超过20%就足以令人不安了。在大部分情况下，也会有进程队列排队时间(在r列报告的)。如图所示。注意，这里也可能有合理数量的上下文切换(cs列)，除非每秒超过100 000次或更多，一般都不用担心上下文切换。当操作系统停止一个进程转而运行另一个进程时，就会产生上下文切换。例如，一查询语句在MyISAM上执行了一个非覆盖索引扫描，就会先从索引中读取元素，然后根据索引再从磁盘上读取页面。如果页面不在操作系统缓存中，就需要从磁盘进行物理读取，着就会导致上下文切换中断进程处理，直到IO完成。这样一个查询可以导致大量的上下文切换。

IO密集型的机器。
在IO密集型工作负载下，CPU花费大量时间在等待IO请求完成。这意味着vmstat会显示很多处理器在非中断休眠(b列)状态，并且在wa这一列的值很高,如果你查询这台机器的iostat输出显示硬盘一直很忙。%util的值可能因为四舍五入的错误超过100%.什么迹象意味着机器是IO密集的呢？只要有足够的缓冲来服务写请求，即使机器正在做大量的写操作，也可能满足，但是却通常意味着可能会无法满足读请求。这听起来好像违反直觉，但是如果思考读和写的本质，就不会这儿认为了:
1.写请求能够缓冲或同步操作。它们可以被任意一层缓冲:操作系统层、RAID控制器层，等等
2.读请求就其本身而言都是同步的。当然程序可以猜测可能需要某些数据，并异步地提前读取(预读)。无论如何，通常程序在继续工作前得到它们需要的数据。这就强制读请求为同步操作:程序必须被阻塞直到请求完成。

想想这种方式:你可以发出一个写请求到缓冲区的某个地方，然后过一会儿完成。甚至可以每秒发出很多这样的请求。如果缓冲区正确工作，并且有足够的空间，每个请求都可以很快地完成，并且实际上写到物理硬盘是被重新排序后更有效地批量操作的。然而，没有办法对读操作这么做——不管多小或多少的请求，都不可能让硬盘响应说"这是你的数据，我等一会儿读它"。这就是为什么读需要IO等待是可以理解的原因

发生内存交换的机器。
一台正在发生内存交换的机器可能在swapd列有一个很高的值，也可能不高。但是可以看到si和so列有很高的值，这是我们不希望看到的

空闲的机器。
为完整期间，下面也给出一台空闲机器上的vmstat输出。注意，没有在运行或或被阻塞的进程，idle列显示CPU是100%空闲，st列展示了从"虚拟机"偷来的时间

复制解决的问题。
下面是复制常见的用途。
1.数据分布
MySQL复制通常不会对贷款造成很大的压力，但在5.1版本引入的基于行的复制会比传统的基于语句的复制模式的带宽压力大，你可以随意地停止或开始复制，并在不同的地理位置来分布数据备份，例如不同的数据中心。即使在不稳定的网络环境下，远程复制也可以工作。但如果为了保持很低的复制延迟，最好有一个稳定的低延迟连接
2.负载均衡
通过MySQL复制可以将读操作分布到多个服务器上，实现对读密集型应用的优化，并且实现很方便，通过简单的代码修改就能实现基本的负载均衡。对于小规模的应用，可以简单地对机器名做硬编码或使用DNS轮询(将一个机器指向多个IP地址)。当然也可以使用更复杂的方法，例如网络负载均衡这一类的标准负载均衡解决方案，能够很好地将负载分配到不同的MySQL服务器上。Linux虚拟服务器(Linux Virtual Server，LVS)也能很好地工作，
3.备份
对于备份来说，复制是一项很有意义的技术补充，但复制既不是备份也不能够取代备份
4.高可用性和故障切换
复制能够帮助应用程序避免MySQL单点失败，一个包含复制的设计良好的故障切换系统能够显著地缩短宕机时间
5.MySQL升级测试
这种做法比较普遍，使用一个更高版本的MySQL作为备库，保证在升级全部实例前，查询能够在备库按照预期执行。

复制如何工作。
在详细介绍如何设置复制之前，让我们先看看MySQL实际上是如何复制数据的。总的来说，复制有三个步骤:
1.在主库上把数据更改记录到二进制日志(Binary Log)中(这些记录被称为二进制日志事件)
2.备库将主库上的日志复制到自己的中继日志(Relay Log)中
3.备库读取中继日志中的事件，将其重放到备库数据之上
以上只是概述，实际上每一步都很复杂，如图所示
第一步是在主库上记录二进制日志.在每次准备提交事务完成数据更新前，主库将数据更新的事件记录到二进制日志中。MySQL会按事务提交的顺序而非每条语句的执行顺序来记录二进制日志。在记录二进制日志后，主库会告诉存储引擎可以提交事务了。
下一步，备库将主库的二进制日志复制到其本地的中继日志中。首先，备库会启动一个共组哦县城，称为IO线程，IO线程跟主库建立一个普通的客户端连接，然后在主库上启动一个特殊的二进制转储(binlog dump)线程(该线程没有对应的SQL命令)，这个二进制转储线程会读取主库上二进制日中的事件。它不会对事件进行轮询。如果该线程追赶上了主库，它将进入睡眠状态，直到主库发送信号量通知其有新的事件产生时才会被幻行，贝克IO线程会将接收到的事件记录到中继日志中。
MySQL4.0之前的复制与之后的版本相比改变很大，例如MySLQ最初的复制功能没有使用中继日志，所以复制只用到了两个线程，而不是现在的三个线程。目前大部分人都是使用的最新版本。
备库的SQL线程执行最后异步，该线程从中继日志中读取事件并在备库执行，从而实现备库数据的更新。当SQL线程追赶上IO线程时，终极日志通常已经在系统缓存中，所以中继日志的开销很低。SQL线程执行的事件也可以通过配置选项来决定是否写入其自己的二进制日志中。
上图显示了在备库有两个运行的线程，在主库上也有一个运行的线程:和其他普通连接一样，由备库发起的连接，在主库上同样拥有一个线程。
这种复制架构实现了获取事件和重放事件的解耦，允许这两个过程异步进行。也就是说IO线程能够独立于SQL线程之外工作。但这种架构也限制了复制的过程，其中最重要的一点时在主库上并发运行的查询在备库只能串行化执行，因为只有一个SQL线程来重放中继日志中的事件。后面我们将会看到，这是很多工作负载的性能瓶颈所在，虽然有一些针对该问题的解决方案，但大多数用户仍然会受制于单线程

创建复制账号
MySQL会赋予一些特殊的权限给复制线程。在备库运行的IO线程会建立一个到主库的TCP/IP连接，这意味着必须在主库创建一个用户，并赋予其合适的权限。备库IO线程以该用户名连接到主库并读取其二进制日志。通过如下语句创建用户账号:
```sql
mysql>GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@'192.168.0.%' IDENTIFIED BY 'p4ssword';
```
我们在主库和备库都创建该账号。注意我们把这个账户限制在本地网络，因为这是一个特权账号(尽管该账号无法执行select或修改数据，但仍然能从二进制日中获得一些数据)。复制账户事实上只需要有主库上的REPLICATION SLAVE权限，并不一定需要每一端服务器都有REPLICATION CLIENT权限，那为什么我们要把这两种权限给主/备库都赋予呢？这有两个原因:
1.用来监控和管理复制的账号需要REPLICATION CLIENT权限，并且针对这两种目的的使用同一个账号更加容易(而不是为某个目的单独创建一个账号)
2.如果在主库上建立了账号，然后从主库将数据克隆到备库上时，备库也就设置好了——变成主库所需要的配置。这样后续有需要可以方便地交换主备库的角色

配置主库和备库。
下一步需要在主库上开启一些设置，假设主库是服务器server1,需要打开二进制日志并指定一个独一无二的服务器ID(serverID)，在主库的my.cnf文件中增加或修改如下内容:
```c
log_bin = mysql-bin
server_id = 10
```
实际取值由你决定，这里只是为了简单起见，当然也可以设置更多需要的配置。必须明确地指定一个唯一的服务器ID,默认服务器ID通常为1(这和版本相关，一些MySQL版本根本不允许使用这个值)。使用默认值可能会导致和其他服务器的ID冲突，因此这里选择10来作为服务器ID.一种通用的做法是使用服务器IP地址的末8位，但要保证它是不变且唯一的(例如，服务器都在一个子网里)。最好选择一些有意义的约定并遵循。
如果之前没有在MySQL的配置文件中指定log_bin选项，就需要重新启动MySQL.为了确认二进制日志吻技安是否已经在主库上创建，使用SHOW MASTER STATUS命令，检查输出是否与如下的一直。MySQL会为文件名增加一些数字，所以这里看到的文件名和你定义的会有点不一样:
```sql
mysql>SHOW MASTER STATUS;
File:mysql-bin.000001
Position:98
Binlog_Do_DB:
Binlog_Ignore_DB:
```
备库上也需要在my.cnf中增加类似的配置，并且同样需要重启服务器。
```c
log_bin = mysql-bin
server_id = 2
relay_log = /var/lib/mysql/mysql-relay-bin
log_slave_updates = 1
read_only =1
```
从技术上来说，这些选项并不总是必要的。其中一些选项只是显式地列出了默认值。事实上只有server_id是必需地。这里我们同样也使用了log_bin，并赋予一个明确的名字。默认情况下，它是根据机器名来命名的，但如果机器名变化了可能会导致问题。为了简便起见，将主库和备库上的log-bin设置为相同的值。当然如果你愿意的化，也可以设置成别的值。另外我们还增加了两个配置选项:relay_log(指定中继日志的位置和命名)和log_salve_updates(允许备库将其重放的事件也记录到自身的二进制日中中)，后一个选项会给备库增加额外的工作，但正如后面将会看到的，我们有理由为每个备库设置该选项。
有时候只开启了二进制日志，但却没有开启log_slave_updates,可能会碰到一些奇怪的现象，例如，当配置错误时可能会导致备库数据被修改。如果可能的化，最好使用read_only配置选项，该选项会阻止任何没有特权权限的线程修改数据(所以最好不要给予用户超出需要的权限)。但read_only选项常常不是很使用，特别是对于那些需要在备库建表的应用。
(不要再配置文件my.cnf中设置master_port或master_host这些选项，这是老的配置方式，已经被废弃，它只会导致问题，不会有任何好处)

启动复制。
下一步是告诉备库如何连接到主库并重放其二进制日志。这一步要通过修改my.cnf来配置，而是使用CHANGE MASTER TO语句，该语句完全替代了my.cnf中相应的设置，并且允许以后指向别的主库时无须重启备库。下面时开始复制的基本命令:
```sql
mysql> CHANGE MASTER TO MASATER_HOST = 'server1', MASTER_USER='repl',MASTER_PASSWORD='p4ssword',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=0;
```
MASTER_LOG_POS参数被设置为0，因为要从日志的开头独起。当执行完这条语句后，可以通过SHOW SLAVE STATUS语句来检查复制是否正确执行
```sql
mysql>SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State:
Master_Host:server1
Master_User:repl
Master_Port:3306
Connect_Retry:60
Master_Log_File:mysql-bin.000001
Read_Master_Log_Pos:4
Relay_Log_File:mysql-relay-bin.000001
Relay_Log_Pos:4
Relay_Master_Log_File:mysql-bin.000001
Slave_IO_Running:No
Slave_SQL_Running:No
.......
Seconds_Behind_Master:NULL
```
Slave_IO_State、Slave_IO_Running和Slave_SQL_Running这三列显示当前备库复制尚未运行。可鞥已经注意到日志的开头是4而不是0，这是因为0其实不是日志真正开始的位置，它仅仅意味着"在日志文件头"，MySQL知道第一个事件从文件的第4位(事实上，正如之前从SHOW MASTER STAUS看到的，真正的日志起始位置是98，一旦备库连接到主库就开始工作，现在连接还未发生)开始读。

从另一个服务器开始复制。
前面的设置都是嘉定主备库均为刚刚安装好且都是默认的数据，也就是说两台服务器上数据相同，并且知道当前主库的二进制日志。这不是典型的案例，大多数情况下有一个已经运行了一段时间的主库，然后用一台新安装的备库与之同步，此时这台备库还没有数据。有几种办法来初始化备库或者从其他服务器克隆到备库。包括从主库复制数据、从另外一台备库克隆数据，以及使用最近的一次备份来启动备库，需要由三个条件来让主库和备库保持同步:
1.在某个时间点的主库的数据快照
2.主库当前的二进制日志文件，和获得数据快照时在该二进制日志文件中的偏移量，我们把这两个值称为日志文件坐标(log file coordinates)。通过这两个值可以确定二进制日志的位置。可以通过SHOW MASTER STATUS命令来获取这些值
3.从快照时间到现在的二进制日志
下面是一些从别的服务器克隆备库的方法:
1.使用冷备份
最基本的方法是关闭主库，把数据复制到备库.重启主库后，会使用一个新的二进制文件，我们在备库通过执行CHANGE MASTER TO 指向这个文件的起始处。这个方法的缺点很明显:在复制数据时需要关闭主库
2.使用热备份
如果仅使用了MyISAM表，可以在主库运行时使用mysqlhotcopy或rsync来复制数据
3.使用mysqldump
如果只包含InnoDB表，那么可以使用以下命令来转储主库数据并将其加载到备库，然后设置相应的二进制日志坐标
```c
$ mysqldump --single-transaction --all-databases --master-data=1--host=server1 \| mysql --host=server2
```
选项--single-transaction使得转储的数据为事务开始前的数据。如果使用的是非事务型表，可以使用--lock-all-tables选项来获得所有表的一致性转储
4.使用快照或备份
只要知道对应的二进制日志坐标，就可以使用主库的快照或者备份来初始化备库(如果使用备份，需要确保从备份的时间点开始的主库二进制日志都要存在)。只需要把备份或快照恢复到备库，然后使用CHANGE MASTER TO指定二进制日志的坐标。也可以使用LVM快照、SAN快照、EBS快照——任何快照都可以
5.使用Percona Xtrabackup
Percona的Xtrabackup是一款开源的热备份工具。它能够再备份时不阻塞服务器的操作，因此可以在不影响主库的情况下设置备库。可以通过克隆主库或另一个已存在的备库的方式来建立备库。创建一个备份(不管是从主库还是从别的备库),并将其转储到目标机器，然后根据备份获得正确的开始复制的位置。
5.1 如果是从主库获得备份，可以从xtrabackup_binlog_pos_innodb文件中获得复制开始的位置
5.2 如果是从另外的备库获得备份，可以从xtrabackup_slave_info文件重获得复制开始的位置。
6.使用另外的备库
可以使用任何一种提及的克隆或者拷贝技术来从任意一台备库上将数据克隆到另外一台服务器。但是如果使用的是mysqldump,--master-data选项就会不起作用。此外，不能使用SHOW MASTER STATUS来获得主库的二进制日志坐标，而是在获取快照时使用SHOW SLAVE STATUS来获取备库在主库上的执行位置。使用另外的备库进行数据克隆最大的缺点是，如果这台备库的数据已经和主库不同步，克隆得到的就是脏数据。
不要使用LOAD DATA FROM MASTER或者LOAD TABLE FROM MASTER!这些命令过时、缓慢，并且非常危险，并且只适用于MyISAM存储引擎。
不管选择哪种技术，都要能熟练运用，要记录详细的文档或编写脚本。因为可能不止一次需要做这样的事情。甚至当错误发生时，也需要能够处理

推荐的复制配置。
有许多参数来控制复制，其中一些会对数据安全和性能产生影响。推荐一种"安全"的配置，可以最小化问题发生的概率。在主库上二进制最重要的选项是sync_binlog：
```c
sync_binlog=1
```
如果开启该选项，MySQL每次在提交事务前会将二进制日志同步到磁盘上，保证在服务器崩溃时不会丢失事件。如果禁止该选项，服务器会少做一些工作，但二进制日志文件可能在服务器崩溃时损坏或丢失信息。在一个不需要作为主库的备库上，该选项带来了不必要的开销。它只适用于二进制日志，而非中继日志。如果无法容忍服务器崩溃导致表损坏，推荐使用InnoDB。在表损坏无关紧要时，MyISAM是可以接受的，但在一次备库服务器崩溃重启后，MyISAM表可能已经处于不一致状态。一种可能是语句没有完全应用到一个或多个表上，那么即使修复了表，数据也可能是不一致的。
如果使用InnoDB，强烈推荐设置如下选项:
```c
innodb_flush_logs_at_trx_commit #Flush every log write
innodb_support_xa=1 # MySQL 5.0 and newer only
innodb_safe_binlog # MySQL 4.1 only,rounghly equivalent to innodb_support_xa
```
这些事MySQL5.0及最新版本中的默认配置，我们推荐明确指定二进制日志的名字，以保证二进制日志名在所有服务器上是一致的，避免因为服务器名的变化导致日志文件名变化。你可能认为以服务器名来命名二进制日志无关紧要，但经验表明，当在服务器间转移文件、克隆新的备库、转储备份或者其他一些你想象不到的场景下，可能会导致很多问题。为了避免这些问题，需要给log_bin选项指定一个参数。可以随意地给一个绝对路径，但必须明确地指定基本的命名:
```c
log_bin=/var/lib/ysql/mysql-bin # Good,specifies a path and base name
# log_bin   # Bad, base name will be server's hostname
```
在备库上，我们同样推荐开启如下配置选项，为中继日志制定绝对路径:
```c
relay_log=/path/to/logs/relay-bin
skip_slave_start
read_only
```
通过设置relay_log可以避免中继日志文件基于机器名来命名，防止之前提到的可能在主库发生的问题。制定绝对路径可以避免多个MySQL把本中存在的Bug,这些Bug可能会导致中继日志在一个意料外的位置创建。skip_slave_start选项能够阻止备库在崩溃后自动启动复制。这可以给你一些机会来修复可能发生的问题。如果备库在崩溃后自动启动并且处于不一致的状态，就可能导致更多的损坏，最后将不得不把所有数据丢弃，并重新开始配置备库。
read_only选项可以阻止大部分用户更改非临时表，除了复制SQL线程和其他拥有超级权限的用户之外，这也是要尽量避免给正常账号授予超级权限的原因之一。
即使开启了所有我们建议的选项，备库仍然可能在崩溃后被中断，因为master.info和中继日志文件都不是崩溃安全的。默认情况下甚至不会刷新到磁盘，直到MySQL5.5版本才有选项来控制这种行为。如果正在使用MySQL5.5并且不会介意额外的fsync()导致的性能开销，最好设置以下选项:
```c
sync_master_info=1
sync_relay_log=1
sync_relay_log_info=1
```
如果备库与主库的延迟很大，备库的IO线程可能会写很多中继日志文件，SQL线程在重放完一个中继日志中的事件后会尽快将其删除(通过relay_log_purge选项来控制)。但如果延迟非常严重，IO线程可能会把整个磁盘撑满。解决办法是配置relay_log_space_limit变量。如果所有中继日志的大小之和超过这个值，IO线程会停止，等待SQL线程释放磁盘空间。
尽管听起来很美好，但有一个隐藏的问题。如果备库没有从主库上获取所有的中继日志，这些日志可能在主库崩溃时丢失。早先这个选项存在一些Bug，使用率也不高，所以用到这个选项遇到Bug的风险会更高。除非磁盘空间真的非常紧张，否则最好让中继日志使用其需要的磁盘空间，这也是为什么没有将relay_log_space_limit列入推荐配置选项的原因

基于语句的复制。
在MySQL5.0及之前的版本中只支持基于语句的复制(也称为逻辑复制)，这在数据库领域是很少见的，基于语句的复制模式下，主库会记录那些造成数据更改的查询，当备库读取并重放这些事件时，实际上只是把主库上执行过的SQL再执行一遍。这种方式既有好处、也有缺点。
最明显的好处是实现相当简单。理论上讲，简单地记录和执行这些语句，能够让主备保持同步。另一个好处是二进制日志里的事件更加紧凑，所以相对而言，基于语句的模式不会使用太多带宽。一条更新好几兆数据的语句在二进制日志里可能只占几十个字节。另外mysqlbinlog工具是使用基于语句的日志的最佳工具。但事实上基于语句的方式可能并不如看起来那么便利。因为主库上的数据更新除了执行的语句外，可能还依赖于其他因素。例如，同一条SQL在主库和备库上执行的事件可能稍微或很不相同，因此在传输的二进制日志中，除了查询语句，还包括了一些元数据信息，如当前的时间戳。即便如此，还存在着一些无法被正确复制的SQL.例如使用CURRENT_USER()函数的语句。存储过程和触发器在使用基于语句的复制模式时也可能存在问题。
另外一个问题是更新必须是串行的。这需要更多的锁——有时候要特别关注这一点，另外不是所有的存储引擎都支持这种复制模式。尽管这些存储引擎是包括在MySQL5.5及之前版本中发行的。

基于行的复制。
MySQL5.1开始支持基于行的复制，这种方式会将实际数据记录在二进制日志中，跟其他数据库的实现比较相像。它有其自身的一些优点和缺点。最大的好处是可以正确地复制每一行。一些语句可以被更加有效地复制。
(基于行的复制没有向后兼容性，和MySQL 5.1 一起发布的mysqlbinlog工具可以读取基于行的复制的时间格式(它对人是不可读的，但MySQL可以解释)，但是早期版本的mysqlbinlog无法识别这类事件，在遇到错误时会退出)
由于无须重放更新主库数据的查询，使用基于行的复制模式能够更高效地复制数据，重放一些查询的代价可能会很高。例如，下面有一个查询将数据从一个大表中汇总到小表:
```sql
mysql> INSERT INTO summary_table(col1,col2,sum_col3)
    -> SELECT col1,col2,sum(col3)
    -> FROM enormous_table
    -> GROUP BY col1, col2;
```
想象一下，如果表enormous_table的列col1和col2有三种组合，这个查询可能在源表上扫描多次，但最终只在目标表上产生三行数据。但使用基于行的复制方式，在备库上开销会小很多。这种情况下，基于行的复制模式更加高效。但在另一方面，下面这条语句使用基于语句的复制方式代价会小很多:
```sql
mysql>UPDATE enormous_table SET col1 =0;
```
由于这条语句做了全表更新，使用基于行的复制开销会很大，因为每一行的数据都会被记录到二进制日志中，这使得二进制日志事件非常庞大。并且会给主库上记录日志和复制增加额外的负载，更慢的日志记录则会降低并发度。
由于没有哪种模式对所有的情况都是完美的，MySQL能够在这两种复制模式间动态切换，默认情况下使用的是基于语句的复制方式，但如果发现语句无法被正确地复制，就切换到基于行的复制模式。还可以根据需求来设置会话级别的变量binlog_format，控制二进制日志格式。对于基于行的复制模式，很难进行时间点恢复，但这并非不可能

基于行或基于语句:哪种更优？
上面已经讨论了这两种复制模式的优点和缺点，那么在实际应用中哪种方式更优呢？理论上基于行的复制模式整体上更优，并且在实际应用中也适用于大多数场景，但这种方式太新了以至于没有将一些特殊的功能加入到其中来满足数据库管理员的操作需求。因此一些人直到现在还没有开始使用。以下详细地阐述两种方式的优点和缺点，以帮助你决定哪种方式更合适。
1.基于语句的复制模式的优点
当主备的模式不同时，逻辑复制能够在多种情况下工作。例如，在主备上的表的定义不同但数据类型相兼容、列的顺序不同等情况。这样就很容易现在备库上修改schema,然后将其提升为主库，减少停机事件。基于语句的复制方式一般允许更灵活的操作。
基于语句的方式执行复制的过程基本上就是执行SQL语句。这意味着所有在服务器上发生的变更都以一种容易理解的方式运行。这样当出现问题时可以很好地去定位
2.基于语句的复制模式的缺点
很多情况下通过基于语句的模式无法正确复制，几乎每一个安装的备库都会至少碰到一次。事实上对于存储过程，触发器以及其他的一些语句的复制在5.0和5.1的一系列版本中存在大量的Bug。这些语句的复制的方式已经被修改了很多次，以使其更好地工作。简单地说：如果正在使用触发器或者存储过程，就不要使用基于语句的复制模式，除非能够清楚地确定不会碰到复制问题
3.基于行的复制模式的优点
几乎没有基于行的复制模式无法处理的场景。对于所有的SQL构造、触发器、存储过程等都能正确执行。只是当你试图做一些诸如在备库修改表的schema这样的事情时才可能导致复制失败。这种方式同样可能减少锁的使用，因为它并不要求这种强串行化是可重复的。
基于行的复制模式会记录数据变更，因此在二进制日志中记录的都是实际上在主库上发生了变化的数据。你不需要查看一条语句去猜测它到底修改了哪些数据。在某种程度上，该模式能够更加清楚地直到服务器上发生了哪些更改，并且哟一个更好的数据变更记录。另外在一些情况下基于行的二进制日志还会记录发生改变之前的数据，因此这可能有利于某些数据恢复。
在很多情况下，由于无须向基于语句的复制那样需要为查询建立执行计划并执行查询，因此基于行的复制占用更少的CPU.最后在某些情况下，基于行的复制能够帮助更快地找到并解决数据不一致的情况。举个例子，如果是使用基于语句的复制模式，在备库更新一个不存在的记录时不会失败，但在基于行的复制模式下则会报错并停止复制
4.基于行的复制模式的缺点
由于语句并没有在日志里记录，因此无法判断执行了哪些SQL,除了需要知道行的变化外，这在很多情况下也很重要。使用一种完全不同的方式在备库进行数据变更——而不是执行SQL.事实上，执行基于行的变化的过程就像一个黑盒子，你无法知道服务器正在做什么。并且没有很好的文档和解释，因此当出现问题时，可能很难找到问题所在。例如，若备库使用一个效率低下的方式去寻找行记录并更新，你无法观察到这一点。
如果有多层的复制服务器，并且所有的都被配置成基于行的复制模式，当会话级别的变量@@binlog_format被设置成STATEMENT时，锁执行的语句在源服务器上被记录为基于语句的模式，但第一层的备库可能将其记录成行模式，并传递给其他层的备库，也就是说你期望的基于语句的日志在复制拓扑种将会被切换到基于行的模式。基于行的日志无法处理诸如在备库修改表的schema这样的情况，而基于语句的日志可以。
在某些情况下，例如找不到要修改的行时，基于行的复制可能会导致复制停止，而基于语句的复制则不会。这也可以认为是基于行的复制的一个优点。该行为可以通过slave_exec_mode来进行配置。这些缺点正在被慢慢解决。它们在大多数生产环境中依然存在。

复制文件。
接下来看看复制会使用到的一些文件，除了前面的二进制日志文件和中继日志文件，起始还有其他的文件会被用到。不同版本的MySQL默认情况下可能将这些文件放到不同的目录里，大多取决具体的配置选项。可能在data目录或者包含服务器.pid文件的目录下(对于类UNIX系统可能是/var/run/mysqld).
1.mysql-bin.index
当在服务器上开启二进制日志时，同时会生成一个和二进制日志同名的但以.index作为后缀的文件，该文件用于记录磁盘上的二进制日志文件。这里的"index"并不是指表的索引，而是说这个文件的每一行包含了二进制文件的文件名，你可能认为这个文件时多余的。可以被删除(毕竟MySQL可以在磁盘上找到它需要的文件)。事实上并非如此，MySQL依赖于这个文件，除非在这个文件里有记录，否则MySQL识别不了二进制日志文件
2.mysql-relay-bin-index
这个文件是中继日志的索引文件，和mysql-bin.index的作用类似
3.master.info
这个文件用于保存备库连接到主库所需要的信息，格式为纯文本(每行一个值)，不同的MySQL版本，其记录的信息也可能不同。此文件不能删除，否则备库在重启后无法连接到主库。这个文件以文本的方式记录了复制用户的密码，所以要注意此文件的权限控制
4.relay-log.info
这个文件包含了当前备库复制的二进制日志和中继日志坐标(例如，备库复制在主库上的位置)，同样也不要删除这个文件，否则在备库重启后将无法获知从哪个位置开始复制，可能会导致重放已经执行过的语句

使用这些文件来记录MySQL复制和日志状态是一种非常粗糙的方式。更不幸得是，它们不是同步写的。如果服务器断电并且文件数据没有被刷新到磁盘，在重启服务器后，文件中记录的数据可能是错误的。正如之前提到的，这些问题在MySQL5.5里做了改进。以.index作为后缀的文件也与设置expire_logs_days存在交互，该参数定义了MySQL清理过期日志的方式，如果文件mysql-bin.index在磁盘上不存在，在某些MySQL版本自动清理就会不起作用，甚至执行PURGE MASTER LOGS语句也没有用。这个问题的解决方法通常是使用MySQL服务器管理二进制日志，这样就不会产生误解(这意味着不应该使用rm来自己清理日志)。最好能显式地执行一些日志清理策略，比如设置expire_logs_days参数或者其他方式，否则MySQL的二进制日志i可能会将磁盘撑满。当做这些事情时，还需要考虑到备份策略。

发送复制事件到其他备库。
log_slave_updates选项可以让备库变成其他服务器的主库。在设置该选项后，MySQL会将其执行过的事件记录到它自己的二进制日志中。这样它的备库就可以从其日志中检索并执行事件。如图所示。在这种场景下，主库将数据更新事件写入二进制日志，第一个备库提取并执行这个事件。这时候一个事件的生命周期应该结束了，但由于设置了log_slave_updates，备库会将这个时间写到它自己的二进制日志中。这样第二个备库就可以将事件提取到它的中继日志中并执行。这意味着作为源服务器的主库可以将其数据变化传递给没有与其直接相连的备库上。默认情况下这个选项是被打开的，这样在连接到备库时就不需要重启服务器。
当第一个备库从主库获得鞥多事件写入到其二进制日志中时，这个事件在备库二进制日志中的位置与其在主库二进制日志中的位置几乎肯定是不相同的，可能在不同的日志文件或文件内不同鞥多位置。这意味着你不能嘉定所有拥有统一逻辑复制点的服务器拥有相同的日志坐标。这种情况会使某些任务更加复杂，例如，修改一个备库的主库或将备库提升为主库。
除非你已经注意到要给每个服务器分配一个唯一的唯一的服务器ID,否则按照这种方式配置备库会导致一些奇怪的错误，甚至还会导致复制停止。一个更常见的问题是:为什么要指定服务器ID,难道MySQL在不知道复制命令来源的情况下不能执行吗？为什么MySQL要在意服务器ID是全局唯一的。问题的答案在于MySQL在复制过程中如何防止无限循环。当复制SQL线程读中继日志时，会丢弃事件中记录的服务器ID和该服务器本身ID相同的事件，从而打破了复制过程中的无限循环。在某些复制拓扑结构下打破无限循环非常重要,例如主-主复制结构(语句在无限循环中来回传递也是多服务器环形复制拓扑结构中比较有意思的话题之一)。
如果在设置复制的时候碰到问题，服务器ID应该是需要检查的因素之一。当然只检查@@server_id是不够的，它有一个默认值，除非在my.cnf文件或通过SET命令明确指定它的值，复制才会工作。如果使用SET命令，确保同时也更新了配置文件，否则SET命令的设定可能在服务器重启后丢失。

一主库多备库。
除了前面已经提过的两台服务器的主备结构外，这是最简单的拓扑结构。事实上一主多备的结构和基本配置差不多简单，因为备库之间根本没有交互(从技术上讲这并非正确的。但如果有重复的服务器ID，它们将现如竞争，并反复将对方从主库上踢出)，它们仅仅是连接到同一个主库上，如图显示了这种结构。
尽管这是非常简单的拓扑结构，但它非常灵活，能满足多种需求。下面是它的一些用途:
1.为不同的角色使用不同的备库(例如添加不同的索引或使用不同的存储引擎)
2.把一台备库当作待用的主库，除了复制没有其他数据传输
3.延迟一个或多个备库，以备灾难恢复
4.使用其中一个备库，作为备份、培训、开发或者测试使用服务器

这种结构流行的原因是它避免了很多其他拓扑结构的复杂性。例如:可以方便地比较不同备库重放的事件在主库二进制日志中的位置。换句话说，如果在同一个逻辑点停止所有备库的复制，它们正在读取的是主库上同一个日志文件的相同物理位置。这是个很好的特性，可以减轻管理员许多工作，例如把备库提升为主库。这种特性只存在于兄弟备库之间。在没有直接的主备或兄弟关系的服务器上去比较日志文件的位置要复杂很多。

主动-主动模式下的主-主复制。
主-主复制(也叫双主复制或双向复制)包含两台服务器，每一个都被配置成对方的主库和备库，换句话说，它们是一对主库，如图显示了该结构。主动-主动模式下主-主复制有一些应用场景，但通常用于特殊的目的。一个可能的应用场景是两个处于不同地理位置的办公室，并且都需要一份可写的数据拷贝。
这种配置最大的问题是如何解决冲突，两个可写的互主服务器导致的问题非常多。这通常发生在两台服务器同时修改一行记录，或同时在两台服务器上向一个包含AUTO_INCREMENT列的表里插入数据(事实上这些问题经常一周发生三次，并且发现需要好几个月才能解决这些问题)
MySQL5.0增加了一些特性，使得这种配置稍微安全了点，就是设置auto_increment_increment和auto_increment_offset。通过这两个选项可以让MySQL自动为INSERT语句选择不互相冲突的值。然而允许向两台主库上写入仍然很危险。在两台机器上根据不同的顺序更新，可能会导致数据不同步。例如，一个只有一列的表，只有一行值为1的记录假设同时i执行下面两条语句:
1.在第一台主库上:
mysql>UPDATE tbl SET col=col +1
2.在第二台主库上:
mysql>UPDATE tbl SET col=col *2;
那么结果呢？一台服务器上值为4，另一台值为3，并且没有报告任何复制错误。数据不通过不还仅仅是开始。当正常的复制发生错误停止了，但应用在同时向两台服务器写入数据，这时候会发生什么呢？你不能简单地把数据从一台服务器复制到另外一台，因为这两台机器上需要复制的数据都可能发生了变化。解决这个问题将会非常困难。
如果足够仔细地配置这种架构，例如很好地划分数据和权限，并且你很清楚自己在做什么，可以避免一些问题(一些，但不是全部),然而这通常很难做好，并且有更好的办法来实现你所需要的。
总地来说，允许向两个服务器上写入带来的麻烦远远大于其带来的好处

主动-被动模式下的主-主复制。
这是前面描述的主-主结构的变体，它能够避免上面讨论的问题。这也是构建容错性和高可用性系统的非常强大的方式，主要区别在于其中的一台服务器是只读的被动服务器，如图所示。这种方式使得反复切换主动和被动服务器非常方便，因为服务器的配置是对称的。这使得故障转移和故障恢复很容易。它也可以让你在不关闭服务器的情况下执行维护、优化表、升级操作系统(或者应用程序、硬件等)或其他任务。
例如，执行ALTER TABLE操作可能会锁住整个表，阻塞对表的读和写，这可能会花费很长事件并导致服务中断。然而在主-主配置下，可以先停止主动服务器上的备库复制线程(这样就不会在被动服务器上执行任何更新)，然后在被动服务器上执行ALTER操作，交换角色，最后在先前的主动服务器上启动复制线程。这个服务器将会读取中继日志并执行相同的ALTER语句。这可能花费很长时间，但不要紧，因为该服务器没有为任何活跃查询提供服务。
主动-被动模式的主-主结构能够帮助会比许多MySQL的问题和限制，此外还有一些工具可以完成这种类型的操作。
让我们看看如何配置主-主服务器对，在两台服务器上执行如下设置后，会使其拥有对称的设置:
1.确保两台服务器上有相同的数据
2.启用二进制日志，选择唯一的服务器ID，并创建复制账号。
3.启用备库更新的日志记录，后面将会看到，这是故障转移和故障恢复的关键
4.把被动服务器配置成只读，防止可能与主动服务器上的更新产生冲突，这一点是可选的。
5.启动每个服务器的MySQL实例
6.将每个主库设置为对方的备库，使用新创建的二进制日志开始工作
让我们看看主动服务器上更新时会发生什么事情。更新被记录到二进制日志中，通过复制传递给被动服务器的中继日志中。被动服务器执行查询并将其记录到自己的二进制日志中(因为开启了log_slave_updates选项)。由于时间的服务器ID与主动服务器的相同，因此主动服务器将忽略这些时间。
设置主动-被动的主-主拓扑结构在某种意义上类似于创建了一个热备份，但是可以使用这个"备份"来提高性能，例如，用它来执行读操作、备份、"离线"维护以及升级等。真正的热备份做不了这些事情，然而，你不会获得比单台服务器更好的写性能。它是一种非常常见的并且重要的拓扑结构

拥有备库的主-主结构。
另外一种相关的配置是为每个主库增加一个备库，如图所示。这种配置的优点是增加了冗余，对于不同地理位置的复制拓扑，能够消除站点单点失效的问题。你也可以像平常一样，将读查询分配到备库上。如果在本地为了故障转移使用主-主结构，这种配置同样有用。当主库失效时，用备库来代替主库还是可行的，虽然这有点复杂。同样也可以把备库指向一个不同的主库，但需要考虑增加的复杂度

环形复制。
如图所示，双主结构实际上是环形结构的一种特例(也许应该说，是更明智的特例)。环形结构可以有三个或更多的主库。每个服务器都是在它之前的服务器的备库，是它在之后的服务器的主库。这种结构也称为环形复制(circular replication).环形结构没有双主结构的一些优点，例如对称配置和简单的故障转移，并且完全依赖于环上的每一个可用节点，这大大增加了整个系统失效的几率。如果从环中移除一个节点，这个节点发起的时间就会陷入无限循环:它们将永远绕着服务器链循环。总地来说，环形结构非常脆弱，应该尽量避免。可以通过为每个节点增加备库的方式来减少环形复制的风险，如图所示，但这仅仅防范了服务器失效的危险，断电或者其他一些影响到网络连接的问题都可能破坏整个环

主库、分发主库以及备库。
我们之前提到当备库足够多时，会对主库造成很大的负载。每个备库会在主库上创建一个线程，并执行binlog dump命令。该命令会读取二进制日志文件中的数据并将其发送给备库。每个备库都会重复这样的工作，它们不会共享binlog dump的资源。如果有很多备库，并且有大的事件时，例如一次很大的LOAD DATA INFILE操作，主库上的负载会显著上升，甚至可能由于备库同时请求同样的事件而耗尽内存并崩溃。另一方面，如果备库请求的数据不在文件系统的缓存中，可能会导致大量的磁盘检索，这同样会影响主库的性能并增加锁的竞争。因此，如果需要多个备库，一个好办法时从主库移除负载并使用分发主库。分发主库事实上也是一个备库，它的唯一目的就是提取和提供主库的二进制日志。多个备库连接到分发主库，这使原来的主库摆脱了负担。为了避免在分发主库上做实际的查询，可以将它的表修改为blackhole存储疫情，如图所示。很难说当备库数据达到多少时需要一个分发主库。按照通用准则，如果主库接近满负载，不应该为其建立10个以上的备库。如果有少量的写操作，或者只复制其中一部分表，主库就可以提供更多的复制。另外，也不一定只适用一个分发主库。如果需要的话，可以使用多个分发主向大量的备库进行复制，或者使用金字塔状的分发主库。在某些情况下，可以通过设置slave_compressed_protocol来节约一些主库带宽。这对跨数据中心复制很有好处。
还可以通过分发主库实现其他目的，例如，对二进制日志事件执行过滤和重写规则。这比在每个备库上重复进行日志记录、重写和过滤要高效得多。如果在分发主库上使用blackhole表，可以支持更多得备库。虽然会在分发主库执行查询，但其代价非常小，因为blackhole表中没有任何数据。blackhole表得缺点是其存在Bug，例如在某些情况下会忘记将自增ID写入到二进制日志中。所以要小心使用blackhole表。
一个比较常见得问题是如何确保分发服务器上得每个表都是blackhole存储引擎。如果有人在主库创建了一个表并指定了不同的存储引擎呢？确实，不管什么时候，在备库上使用不同的存储引擎总会导致同样的问题。常见的解决方案是设置服务器的storage_engine选项:
```c
storage_engine=blackhole
```
这只会影响哪些没有指定存储引擎的CREATE TABLE的语句。如果有一个无法控制的应用，这种拓扑结构可能会非常脆弱。可以通过skip_innodb选项禁止InnoDB，将表退化为MyISAM。但你无法禁止MyISAM或者Memory引擎。使用分发主库另外一个主要的缺点是无法使用一个备库来代替主库，因为由于分发主库的存在，导致各个备库与原始主库的二进制日志坐标已经不相同。

树或金字塔形。
如果正在将主库复制到大量的备库中，不管是把数据分发到不同的地方，还是提供更高的读性能，使用金字塔结构都能够更好地管理，如图所示。
这种设计地好处是减轻了主库地负担，就像前面提到地分发主库一样。它的缺点是中间层出现的任何错误都会影响到多个服务器。如果每个备库和主库直接相连就不会存在这样的问题。同样，中间层次越多，处理故障会更困难、更复杂。

定制的复制方案。
MySQL的复制非常灵活，可以根据需要定制解决方案。典型的定制方案包括组合过滤、分发和向不同的存储引擎复制。也可以使用"黑客手段"，例如，从一个使用blackhole存储引擎的服务器上复制或复制到这样的服务器上。可以根据需要任意设计。这其中最大的限制是合理地监控和管理，以及所拥有资源额约束(网络带宽、CPU能力等)

为什么复制无法扩展写操作。
糟糕的服务容量比例的根本原因是不能像分发读操作那样把写操作等同地分发到更多服务器上。换句话说，复制只能扩展读操作，无法扩展写操作。
你可能想知道到底有没有办法使用复制来增加写入能力。答案是否定的，根本不行。对数据进行分区是唯一可以扩展写入的方法。
一些人可能会想到使用主-主拓扑结构(主动-主动模式下的主-主复制)并为两个服务器执行写操作。这种配置比主备结构能支持稍微多一点的写入，因为可以再两台服务器之间共享串行化带来的开销。如果每台服务器上执行50%的写入，那复制的执行量也只有50%需要串行化。理论上讲，这比在一台机器上(主库)对100%的写入并发执行，而在另外一台机器上(备库)上对100%的写入做串行化更优。
这可能看起来很吸引人，然而这种配置还比不上单台服务器能支持的写入。一个有50%的写入被串行化的服务器性能比一台全部写入都并行化的服务器性能要低。这是这种策略不能扩展写入的原因。它只能在两台服务器间共享串行化写入的缺点。所以"链中最弱的一环"并不是那么弱，它只提供了比主动-被动复制稍微好点的性能。但是增加了很大的风险。通常不能带来任何好处

备库什么时候开始延迟。
一个关于备库比较普遍的问题是如何预测备库会在何时跟不上主库。很难去描述备库使用的复制容量为5%与95%的区别，但是至少能够在接近饱和前预警并估计复制容量。首先应该古纳差复制延迟的尖刺。如果有复制延迟的曲线图，需要注意到图上的一些短暂的延迟骤升，这时候可能负载加大，备库短时间内无法跟上主库。当负载接近耗尽备库的容量时，会发现曲线上的凸起会更高更宽。前面曲线地上升角度不必那，但随后当备库在产生延迟后开始追赶主库时，将会产生一个平缓的斜坡。这些突起的出现和增长是一个警告信息，意味着已经接近容量限制。
为了预测在将来的某个时间点会发生什么，可以人为地制造延迟，然后看多久备库能赶上主库。目的时为了明确地曲线上的斜坡的陡度。如果讲备库停止一个小时，然后开启并在1小时内追赶上，说明正常情况下只消耗了一半的容量。也就是说，如果中午12:00停止备库复制，在1:00开启，并且在2:00追赶上，备库在一小时内完成了两个小时内所有的变更，说明复制可以在双倍速度下运行。
最后，如果使用得时Percona Server或者MariaDB，也可以直接获取复制的利用率。打开服务器变量userstat,然后执行如下语句:
```sql
mysql> SELECT * FROM INFORMATION_SCHEMA.USER_STATISTICS WHERE USER='#mysql_system#'\G
*************************** 1. row ***************************
USER:#mysql_system#
TOTAL_CONNECTIONS:1
CONCURRENT_CONNECTIONS:2
CONNECTED_TIME:46188
BUSY_TIME:719
ROWS_FETCHED:0
ROWS_UPDATED:1882292
SELECT_COMMANDS:0
UPDATE_COMMANDS:580431
OTHER_COMMANDS:338857
COMMIT_TRANSACTIONS:1016571
ROLLBACK_TRANSACTIONS:0
```
可以讲BUSY_TIME和CONNECTED_TIME的一半(因为备库有两个复制线程)做比较,来观察备库线程实际执行命令所花费的事件(如果复制线程总是在运行，你可以使用服务器的uptime来代替CONNECTED_TIME的一半)。在该例子中，备库大约使用了其3%的能力，这并不意味着它不会遇到偶然的延迟尖刺——如果主库运行了一个超过10分钟才完成的变更，可能延迟的事件和变更执行的事件是相同的——但这很好地暗示了备库能够很快从一个延迟尖刺中恢复

规划冗余容量。
在构建一个大型应用时，有意让服务器不被充分利用，，这应该是一种聪明并且划算的方式，尤其在使用复制的时候。有多余容量的服务器可以更好地处理负载尖峰，也有更多能力处理慢速查询和维护工作(如OPTIMIZE TABLE ),并且能够更好地跟上复制，试图同时向主-主拓扑结构的两个节点写入来减少复制问题通常是不划算的。分配给每台机器的读负载应该低于50%，否则，如果某台机器失效，就没有足够的容量了，如果两台服务器都能独立处理负载，就用不着担心复制的问题了。。构建冗余容量也是实现高可用性的最佳方式之一，当然还有别的方式，例如，当错误发生时让应用在降级模式下运行

监控复制。
复制增加了MySQL监控的复杂性。尽管复制发生在主库和备库上，但大多数工作是在备库上完成的，这也正式最常出问题的地方。是否所有的备库都在工作？最慢的备库延迟是多大？MySQL本身提供了大量可以回答上述问题的信息，弹药实现自动化监控过程以及使复制更健壮还是需要用户做更多的工作。
在主库上，可以使用SHOW MASTER STATUS命令来查看当前主库的二进制日志位置和配置。还可以查看主库当前有哪些二进制日志在磁盘上的:
```sql
mysql>SHOW MASTER LOGS;
```
该命令用于给PURGE MASTER LOGS命令决定使用哪个参数。另外还可以通过SHOW BINLOG EVENTS来查看复制事件。例如，在运行前一个命令后，我们在另一个不曾使用过的服务器上创建一个表，因为知道这是唯一改变数据的语句，而且也知道语句在二进制日志中的偏移量是319，所以我们能看到如下内容:

测量备库延迟。
一个比较普遍的问题是如何监控备库落后主库的延迟有多大。虽然SHOW SLAVE STATUS输出的Seconds_behind_master列理论上显示了备库的延时，但由于各种各样的原因，并不总是准确的:
1.备库Seconds_behind_master值是通过讲服务器当前的时间戳与二进制日志中的事件的时间戳相对比得到的，所以只有在执行事件时才能报告延迟。
2.如果备库复制线程没有运行，就会报延迟为NULL
3.一些错误(例如主备的max_allowed_packet不匹配，或者网络不稳定)可能中断复制并且/或者停止复制线程，但Seconds_behind_master将显示为0而不是显示错误
4.即使备库线程正在运行，备库有时候可能无法计算延时，如果发生这种情况，备库会报0或者NULL
5.一个大事务可能会导致延迟波动，例如，有一个事务更新数据长达一个小时，最后提交。这条更新将比它实际发生时间要晚一个小时才记录到二进制日志中。当备库执行这条语句时，会临时地报告备库延迟为一个小时，然后又很快变成0
6.如果分发主库落后了，并且其本身也有已经追赶上它的备库，备库的延迟将显示为0，而事实上和源主库之间是有延迟的。

解决这些问题的办法是忽略Seconds_behind_master的值，并使用一些可以直接观察和衡量的方式来监控备库延迟。最好的解决办法是使用heartbeat record，这是一个在主库上会每秒更新一次的时间戳。为了计算延时，可以直接用备库当前的时间戳减去心跳记录的值。这个方法能够解决刚刚我们提到的所有问题，另外一个额外的好处是我们还可以通过时间戳知道备库当前的复制状况。包含在Percona Toolkit里的pt-heartbeat脚本是"复制心跳"最流行的一种实现。心跳还有其他好处，记录在二进制日志中的心跳记录拥有多种用途，例如在一些很难解决的场景下可以用于灾难恢复。
刚刚所描述的几种延迟指标都不能表明备库需要多长时间才能赶上主库，这依赖于许多因素，例如备库的写入能力以及主库持续写入的次数。

确定主备是否一致。
在理想情况下，备库和主库的数据应该是完全一样的。但事实上备库可能发生错误并导致数据不一致。即使没有明显的错误，备库同样可能因为MySQL自身的特性导致数据不一致，例如MySQL的Bug、网络中断、服务器崩溃，非正常关闭或者其他一些错误。(如果你正在使用非事务型存储引擎，不首先调用STOP SLAVE就关闭服务器是很不妥当的)。
按照经验来看，主备一致应该是一种规范，而不是例外，也就是说，检查你的主备一致性应该是一个日常工作，特别是当使用备库来做备份时尤为重要，因为你肯定不希望从一个已经损坏的备库里获得备份数据。MySQL并没有内建的方法来比较一台服务器与别的服务器的数据是否相同。它提供了一些组建来为表和数据生成校验值，例如CHECKSUM TABLE。但当复制正在进行时，这种方法是不可行的。
Percona Toolkit里的pt-table-checksum能够解决上述几个问题。其主要特性是用于确认备库与主库的数据是否一致。工作方式是通过在主库执行INSERT ...SELECT查询。这些查询对数据进行校验并将结果插入到一个表中。这些语句通过复制传递到备库，并在备库执行一遍，然后可以比较主备上的结果是否一样。由于该方法是通过复制工作的。它能够给出一致的结果而无须同时把主备上的表都锁上。
通常情况下可以在主库上运行该工具，参数如下:
```c
$ pt-table-checksum  --replicate=test.checksum <master_host>
```
该命令将检查所有的表，并将结果插入到test.checksum表中。当查询在备库执行完后，就可以简单地比较主备之间的不同了。pt-table-checksum能够发现服务器所有的备库，在每台备库上运行查询，并自动地输出结果。

从主库重新同步备库。
在职业生涯中，也许会不止一次需要去处理未被同步的备库。可能是使用校验工具发现了数据不一致，或是因为已经知道是备库忽略了某条查询或者有人在备库上修改了数据。传统的修复不一致的办法是关闭备库，然后重新从主库复制一份数据。当备库数据不一致的问题可能导致严重后果时，一旦发现就应该将备库停止并从生产环境移除，然后再从一个备份中克隆或恢复备库。
这种方法的缺点是不太方便，特别是数据量很大时。如果能够找出并修复不一致的数据，要比从其他服务器上重新克隆数据要有效得多。如果发现的不一致并不严重，就可以保持备库在线，并重新同步受影响的数据。最简单的办法是使用mysqldump转储受影响的数据并重新导入。在整个过程中，如果数据没有发生变化，这种方法会很好。你可以在主库上简单地锁住表然后进行转储，再等备库赶上主库，然后将数据导入到备库中。(需要等待备库赶上主库，这样就不至于为其他表引入新的不一致，例如那些可能通过和失去同步的表做join后进行数据更新的表)。
虽然这种方法再许多场景下是可行的。但在一个繁忙的服务器上有可能行不通。另外一个缺点是在备库上通过非复制的方式改变数据。通过复制改变备库数据(通过在主库上执行更新)通常是一种安全的技术，因为它避免了竞争条件和其他意料外的事情。如果表很大或者网络带宽首先，转储和重载数据的代价依然很高。当在一个有一百万行的表上只有一千行不同的数据呢？转储和重载表的数据是非常浪费资源的。
pt-table-sync是Percona Toolkit中的另外一个工具，可以解决该问题。该工具能够高效地查找并解决表之间的不同。它同样通过复制工作，在主库上执行查询，在备库上重新同步，这样就没有竞争条件。它是结合pt-table-checksum生成的checksum表来工作的。所以只能操作那些已知不同步的表的数据块。但该工具不是在所有场景下都有效。为了正确地同步主库和备库，该工具要求复制是正常地，否则就无法工作。pt-table-sync设计得很搞笑，但当数据量非常大时效率还是会很低。比较主库和备库上1TB的数据不可避免地会带来额外的工作。尽管如此，在那些合适的场景中，该工具依然能节约大量的时间和工作

改变主库。
迟早会有把备库指向一个新的主库的需求。也许是为了更迭升级服务器，或者是主库出现问题时需要把一台备库转换成主库，或者只是希望重新分配容量。不管处于什么原因，都需要告诉其他的备库新主库的信息。如果这是计划内的操作，会比较容易(至少比紧急情况下要容易)。只需在备库简单地使用CHNAGE MASTER TO命令，并指定合适的值。大多数值都是可选的。只需要指定需要改变的项即可。备库将抛弃之前的配置和中继日志并从新的主库开始复制。同样新的参数会被更新到master.info文件中，这样就算重启，备库配置信息也不会丢失。
整个过程中最难的是获取新主库上合适的二进制日志文职，这样备库才可以从和老主库相同的逻辑位置开始复制。把备库提升为主库要更困难一点。有两种场景需要将备库替换为主库，一种是计划内的提升，一种是计划外的提升。

数据损坏或丢失的错误。
由于各种各样的原因,MySQL的复制并不能很好地从服务器崩溃、掉电、磁盘损坏、内存或网络错误中恢复。遇到这些问题时几乎可以肯定都需要从某个点开始重启复制。大部分由于非正常关机后导致的复制问题都是由于没有把数据及时地刷到磁盘。下面是意外关闭服务器时可能会碰到的情况.
1.主库意外关闭
如果没有设置主库的sync_binlog选项，就可能在崩溃前没有将最后的几个二进制日志事件刷新到磁盘中。备库IO线程因此也可能一直处于读不到尚未写入磁盘的事件的状态中。当主库重新启动时，备库将重连到主库并在此尝试去读该事件，但主库会告诉备库没有这个二进制日志偏移量。二进制日志转储线程通常很快，因此这种情况步经常发生。解决这个问题的方法是指定备库从下一个二进制日志的开头读日志。但是一些日志事件将永久地丢失，建议使用Percona Toolkit中的pt-table-checksum工具来检查主备一致性，以便于修复。可以通过在主库开启sync_binlog来避免事件丢失。即使开启了sync_binlog.MyISAM表的数据仍然可能在崩溃的时候损坏，对于InnoDB事务，如果innodb_flush_log_at_trx_commit没有设为1，也可能丢失数据(但数据不会损坏)
2.备库意外关闭
当备库在一次非计划中的关闭后重启时，会去读master.info文件以找到上次停止复制的位置。不幸的是，该文件并没有同步写到磁盘，文件中存储的信息可能是错误的。备库可能会尝试重新执行一些二进制日志事件，这可能会导致唯一索引错误。除非能确定备库在哪里停止(通常不太可能)，否则唯一的办法就是忽略那些错误。Percona Toolkit中的pt-slave-restart工具可以帮助完成这一点。如果使用的都是InnoDB表，可以在重启观察MySQl错误日志。InnoDB在恢复过程中会打印出它的恢复点的二进制日志坐标。可以使用这个只来决定备库指向主库的偏移量。Percona Server提供了一个新的特性，可以在恢复的过程中自动将这些信息提取出来，并更新master.info文件，从根本上使得复制能够协调好备库上的事务。MySQL5.5也提供了一些选项来控制i如何将master.info和其他文件刷新到磁盘，这有助于减少这些问题。

除了由于MySQL非正常关闭导致的数据丢失外，磁盘上的二进制日志或终极日志文件损坏并不罕见，下面是一些更普遍的场景:
1.主库上的二进制日志损坏。
如果主库上的二进制日志损坏，除了忽略损坏的位置外你别无选择。可以在主库上执行FLUSH LOGS命令，这样主库会开始一个新的日志文件，然后将备库指向该文件的开始位置。也可以试着去发现损坏区域的结束位置。某些情况下可以通过SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1来忽略一个损坏的事件。如果有多个损坏的事件，就需要重复该步骤，直到跳过所有损坏的事件。但如果有太多的损坏事件，这么做可能就没有意义了。损坏的事件会阻止服务器找到下一个事件。这种情况下，可能不得不手动地去找到下一个完好地事件。
2.备库上的中继日志损坏
如果主库上的日志是完好的，就可以通过CHNAGE MASTER TO命令丢弃并重新获取损坏的事件。只需要将备库指向它当前正在复制的位置(Relay_Master_Log_File/Exec_Master_Log_Pos)这会导致备库丢弃所有在磁盘上的中继日志。就这一点而言，MySQL5.5做了一些改进，它能够在崩溃后自动重新获取中继日志。
3.二进制日志与InnoDB事务日志不同步
当主库崩溃时，InnoDB可能将一个事务标记为已提交，此时盖世五可能还没有记录到二进制日志中，除非是某个备库的中继日志已经保存，否则没有任何办法恢复丢弃的事务。在MySQL5.0版本可以设置sync_binlog选项来防止该问题，对于更早的MySQL4.1可以设置sync_binlog和safe_binlog选项

使用非事务型表。
如果一切正常，基于语句的复制通常能够很好地处理非事务型表。但是当对非事务型表的更新发生错误时，例如查询在完成前被kill，就可能导致主库和备库的数据不一致。例如，假设更新一个MyISAM表的100行数据，若查询更新到了其中50条时有人kill该查询，会发生什么呢？一半的数据改变了，而另一半则没有，结果是复制必然不同步，因为该查询会在备库重放并更新完100行数据(MySQL随后会在主库上发现查询引起的错误，而备库上则没有报错，此后复制将会发生错误并中断)。
如果使用的是MyISAM表，在关闭MySQL之前需要确保已经运行了STOP SLAVE，否则服务器在关闭时会kill所有正在运行的查询(包括没有完成的更新)。事务型存储引擎则没有这个问题。如果使用的是事务型表，失败的更新会在主库上回滚并且不会记录到二进制日志中

混合事务型和非事务型表。
如果使用的是事务型存储引擎，只有在事务提交后才会将查询记录到二进制日志中。因此如果事务回滚，MySQL就不会记录这条查询，也就不会在备库上重放。但是如果混合使用事务型和非事务型表，并且发生了一次回滚，MySQL能够回滚事务型表的更新，但非事务型表则被永久地更新了。只要不发生类似查询中途被kill这样的错误，这就不是问题:MySQL此时会记录该查询并记录一条ROLLBACK语句到日志中，结果是同样的语句也在备库中执行，所有的都很正常。这样效率会第一点，因为备库需要做一些工作并且最后再把它们丢弃掉。但理论上能够保证主备的数据一致。
目前看来一切很正常。但是如果备库发生死锁而主库没有也可能会导致问题。事务型表的更新会被回滚，而非事务型表则无法回滚，此时备库和主库的数据是不一致的。
防止该问题的唯一办法是避免混合使用事务型和非事务型表.如果遇到这个问题，唯一的解决办法是忽略错误，并重新同步相关的表。基于行的复制不会受到这个问题的影响。因为它记录的是数据的更改。而不是SQL语句。如果一条语句改变了一个MyISAM表和一个InnoDB表的某些行，然后主库发生了一次死锁，InnoDB表的更新会被回滚，而MyISAM表的更新仍会被记录到日志中并在备库重放。

不确定语句。
当使用基于语句的复制模式时，如果通过不确定的方式更改数据可能会导致主备不一致。例如，一条带LIMIT的UPDATE语句更改的数据取决于查找行的顺序，除非能保证主库和备库上的顺序相同。例如，若行更具主键排序,一条查询可能在主库和备库上更新不同的行，这些问题非常微妙并且很难注意到。所以一些人进制对那些更新数据的语句使用LIMIT.另外一种不确定的行为是在一个拥有多个唯一索引的表上使用REPLACE或者INSERT IGNORE语句——MySQL在主库和备库上可能会选择不同的索引。
另外还要注意那些设计INFORMATION_SCHEMA表的语句。它们很容易在主库和备库上产生不一致，其结果也会不同。最后需要注意许多系统变量，例如@@server_id和@@hostname，在MySQL5.1之前无法正确地复制，基于行地复制则没有上述限制

主库和备库使用不同的存储引擎。
在悲苦上使用不同的存储引擎，有时候可以带来好处。但是在一些场景下，当使用基于语句的复制方式时，如果备库使用了不同的存储引擎，则可能造成一条查询在主库和备库上的执行结果不同，例如不确定语句在主库使用不同的存储引擎更容易导致问题。如果发现主库和备库的某些表已经不同步，除了检查更新这些表的查询外，还需要检查两台服务器上使用的存储引擎是否相同。

备库发生数据改变。
基于语句的复制方式前提时确保备库和主库相同的数据，因此不应该允许对备库数据的任何更改(比较好的办法是设置read only选项)。假设有如下语句:
```sql
mysql>INSERT INTO table1 SELECT * FROM table2;
```
如果备库上table2的数据和主库上不同，该语句会导致table1的数据也会不一致。换句话说，数据不一致可能会在表之间传播。不仅仅是INSERT....SELECT查询，所有类型的查询都可能发生。有两种可能的结果:备库上发生重复索引键冲突错误或者根本不提示任何错误。如果能报告错误还好，起码能够提示你主备数据已经不一致。无法察觉的不一致可能会悄无声息地导致各种严重的问题。唯一解决的办法就是重新从主库同步数据

不唯一的服务器ID。
这种问题更加难以捉摸。如果不小心为两台备库设置了相同的服务器ID，看起来似乎没有什么问题，但如果查看错误日志，或者使用innotop查看主库，可能会看到一些古怪的信息。在主库上，会发现两台备库中只有一台连接到主库(通常情况下所有的备库都会建立连接以等待随时进行复制)。在备库的错误日志中，则会发现反复的重连和连接断开信息，但不会提及被错误配置的服务器ID。
MySQL可能会缓慢地进行正确的复制，也可能无法进行正确复制，这取决于MySQL的版本，给定的备库可能会丢失二进制日志事件，或者重复执行事件，导致重复键错误(或者不可见的数据损坏)。也可能因为备库的互相竞争造成主库的负载升高。如果备库竞争非常激烈，回导致错误日志在很短的时间内急剧增大。唯一的解决办法是小心设置备库的服务器ID。一个比较号的办法是创建一个主库到备库的服务器ID映射表，这样就可以跟踪到备库的ID信息（也许你想把它保存在服务器中，这 不完全是玩笑，可以给ID添加一个唯一索引）。如果备库全在一个自网络内，可以将每台机器IP的后八位作为唯一ID

未定义的服务器ID。
如果没有在my.cnf里面定义服务器ID,可以通过CHANGE MASTER TO 来设置备库，但却无法启动复制。
```c
mysql>START SLAVE;
ERROR 1200(HY000):The server is not configured as slave;fix in config file or with CHANGE MASTER TO
```
这个报错可能会让人困惑，因为刚刚执行CHNAGE MASTER TO 设置了备库，并且通过SHOW MASTER STATUS也确认了。执行SELECT @@server_id也可以获得一个值，但这只是默认值，必须为备库显式地设置服务器ID.

对未复制数据的依赖性。
如果在主库上有备库不存在的数据库或表，复制会很容易意外中断，反之亦然。假设主库上有一个备库不存在的数据库，命令为scratch。如果在主库上发生对该数据库中表的更新，备库会在尝试重放这些更新时中断。同样的，如果在主库上创建一个备库上已存在的表，复制也可能中断。
没有什么好的解决办法，唯一的办法就是避免在主库上创建备库上没有的表。这样的表是如何创建的呢？有很多可能的方式，其中一些可能更难防范。例如，假设先在备库上创建一个数据库scratch，该数据库在主库上不存在，然后因为某些原因切换了主备。当完成这些后，可能忘记了移除scratch数据库以及它的权限。这时候一些人就可以连接到该数据库并执行一些查询，或者一些定期的任务会发现这些表，并在每个表上执行OPTIMIZE TABLE命令。当提升备库未主库时，或者决定如何配置备库时，需要注意这一点。任何导致主备不同的行为都会产生潜在的问题。

丢失的临时表。
临时表在某些时候比较有用，但不幸的是，它与基于语句的复制是不相容的。如果备库崩溃或者正常关闭，任何复制线程拥有的临时表都会丢失。重启备库后，所有依赖于该临时表的语句都会失败。当基于语句进行复制时，在主库上并没有安全使用临时表的方法。许多人确实很喜欢临时表，所以很难说服他们，但这是不可否认的。(已经有人尝试各种方法来解决这个问题，但对于基于语句的复制并没有安全的临时表创建方法，起码一段时期时这样，不管你如何认为，起码已经证明了这是不可行的)。不管它们的存在多么短暂，都会使得备库的启动和停止以及崩溃恢复变得困难，即使是在一个事务内使用也一样。(如果在备库使用临时表可能问题会少些，但如果备库本身也是一个主库，问题依然存在)。
如果备库重启后复制因找不到临时表而停止，可能需要做以下一些事情:可以直接跳过错误，或者手动地创建一个名字和结构相同的表来代替消失的临时表。不管用什么办法，如果写入查询依赖于临时表，都可能造成数据不一致。避免使用临时表没有看起来那么难，临时表主要有两个比较有用的特性:
1.只对创建临时表的连接可见。所以不会和其他拥有相同名字临时表的链接起冲突
2.随者连接关闭而消失，所以无须显式地移除它们。
可以保留一个专用的数据库，在其中创建持久表，把它们作为伪临时表，以模拟这些特性。只需要为它们选择一个唯一的名字，还好这容易做到:简单将连接ID拼接到表名之后，例如，之前创建临时表的语句为:CREATE TEMPORARY TABLE top_user(...),现在则可以执行CREATE TABLE temp.top_users_1234(...),其中1234是函数CONECTION_ID()返回值。当应用不再使用伪临时表后，可以将其删除或使用一个清理线程来将其移除。表名中使用连接ID可以用于确定哪些表不再被使用——可以通过SHOW PROCESSLIST命令来获得活跃连接列表，并将其与表名中的连接ID相比较。使用实体表而非临时表还有别的好处。例如，能够帮助你更容易调试应用程序，因为可能通过别的连接来查看应用正在维护的数据。如果使用的是临时表，可能就没这么容易做到。到那时实体表可能会比临时表多一些开销，例如创建会更慢，因为这些表分配的.frm文件需要刷新到磁盘。可以通过进制sync_frm选项来加速，但这可能会导致潜在的风险。
如果确实需要使用临时表，也应该在关闭备库前确保Slave_open_temp_tables状态变量的值为0.如果不是0，在重启备库后就可能会出现问题。合适的流程是执行STOP SLAVE,检查变量，然后再关闭备库。如果在停止复制前检查变量，可能会发生竞争条件的风险

不复制所有的更新。
如果错误地使用SET SQL_LOG_BIN=0或者没有理解过滤规则，备库可能会丢失主库上已经发生的更新。有时候希望利用此特性来做归档，但常常会导致意外并出现不好的结果。例如假设设置了replicate_do_db规则，把sakila数据库的数据复制到某一台备库上，如果在主库上执行如下语句，会导致主备数据不一致:
```sql
mysql>USE test;
mysql>UPDATE sakila.actor ....
```
其他类型的语句甚至会因为没有复制依赖导致备库复制抛出错误而失败。

InnoDB加锁引起的锁争用。
正常情况下，InnoDB的读操作是非阻塞的，但在某些情况下需要加锁。特别是在使用基于语句的复制方式时，执行INSERT...SELECT操作会锁定源表上的所有行。MySQL需要加锁以确保该语句的执行结果在主库和备库上是一致的。实际上，加锁导致主库上的语句串行化，以确保和备库上执行的方式相符。
这种设计可能导致锁竞争、阻塞，以及锁等待超时等情况。一种缓解的办法就是避免让事务开启太久以减少阻塞。可以在主库上尽快地提交事务以释放锁。把大命令拆分成小命令，使其尽可能简短。这也是一种减少锁竞争的有效方法。即使有时很难做到，但也是值得的。
另一种办法是替换掉INSERT ... SELECT语句，在主库上先执行SELECT INTO OUTFILE,再执行LOAD DATA INFILE。这种方法根块，并且不需要加锁。这种方法很特殊，但有时还是有用的。最大的问题是为输出文件选择一个唯一的名字，并在完成后清理掉文件。可以通过之前讨论过的CONNECTION_ID()来保证文件名的唯一性，并且可以使用定时任务(UNIX的crontab, Windows平台的计划任务)在连接不再使用这些文件后进行自动清理。也可以尝试关闭上面的这种锁机制，而不是使用上面的变通方法。有一种方法可以做到，但在大多数场景下并不是好办法，备库可能会在不知不觉间就失去和主库的数据同步。这也会导致在做恢复时二进制日志变得毫无用处。但如果确实觉得这么做的利大于弊，可以使用下面的办法来关闭这种锁机制:
```c
# THIS IS NOT SAFE!
innodb_locks_unsafe_for_binlog =1
```
这使得查询的结果所依赖的数据不再加锁。如果第二条查询修改了数据并在第一条查询之前先提交。在主库和备库上执行这两条语句的结果可能不同。对于复制和基于时间点的恢复都是如此。为了了解锁定读取是如何防止混乱的，假设有两张表:一个没有数据，另一个只有一行数据，值为99.有两个事务更新数据。事务1将第二张表的数据插入到第一张表，事务2更新第二张表(源表)，如图所示:
第二步非常重要，事务2尝试去更新源表，这需要在更新的行上加排他锁(写锁)。排他锁与其他锁是不相容的，包括事务1在行记录上加的共享锁。因此事务2需要等待直到事务1完成。事务按照其提交的顺序在二进制日志中记录，所以在备库重放这些事务时产生相同的结果。但从另一方面来说，如果事务1没有在读取的行上加共享锁，就无法保证了，如图显示了在没有锁的情况下的可能的事件序列。
如果没有加锁，记录在日志中的事务顺序在主备上可能会产生不同的结果。MySQL会先记录事务2，这会影响到事务1在备库上的结果，而主库上则不会发生，从而导致了主备的数据不一致。强烈建议在大多数情况下将innodb_locks_unsafe_for_binlog的值设置为0。基于行的复制由于记录了数据的变化而非语句，因此不会存在这个问题。

在主-主复制结构总写入两台主库。
试图向两台主库写入并不是一个好主意，如果同时还希望安全地写入两台主库，会碰到很多问题，有些问题可以解决，有些则很难。一个专业人员可能需要经历大量的教训才能明白其中的不同。在MySQL5.0中，有两个变量可以用于帮助解决AUTO_INCREMENT自增主键冲突的问题:auto_increment_increment和auto_increment_offset。可以通过设置这两个变量来错开主库和备库生成的数字，这样可以避免自增列的冲突。但是这并不能解决所有由于同时写入两太主库所带来的问题;自增问题只是其中的一小部分。而且这种做法也带来了一些新的问题:
1.很难在复制拓扑间作故障转移
2.由于在数字之间出现间隙，会引起键空间的浪费
3.只有在使用了AUTO_INCREMENT主键的时候才有用。有时候使用AUTO_INCREMENT列作为主键并不总是好主意

你也可以自己来生成不冲突的主键值。一种办法时创建一个多个列的主键，第一列使用服务器ID值。这种办法很好，但却使得主键的值变得更大，会对InnoDB二级索引键值产生多重影响。也可以使用只有一列的主键，在主键的高字节位存储服务器ID。简单地左移法(除法)和加法就可以实现。例如，使用的是无符号BIGINT(64位)的高8位来保存服务器ID，可以按照如下方法在服务器15上插入值11:
```sql
mysql>INSERT INTO test(pk_col, ...) VALUE ((15 << 56) + 11, ....)
```
如果想把结果转换为二进制，并将其填充64位，其效果显而易见:
```sql
mysql>SELECT LPAD(CONV(pk_col, 10,2), 64 , '0') FROM test;
```
该方法的缺点是需要额外的方式来产生键值，因为AUTO_INCREMENT无法做到这一点。不要在INSERT语句中将常量15替换为@@server_id，因为这可能在备库产生不同的结果。还可以使用MD5()或者UUID()等函数来获取伪随机数，但这样做性能可能会很差，因为它们产生的值较大，并且本质上是随机的，这尤其会影响到InnoDB(除非是在应用中产生之，否则不要使用UUID(),因为基于语句的复制模式下UUID()不能正确复制)。
这个问题很难解决，通常推荐重构应用程序，以保证只有一个主库是可写的。谁能想得到呢？

过大的复制延迟。
复制延迟是一个很普遍的问题。不管怎么样，最好在设计应用程序时能够让其容忍备库出现延迟，如果系统在备库出现延迟时就无法很好地工作，那么应用程序也许就不应该用到复制。但是也有一些办法可以让备库跟上主库。MySQL单线程复制的设计导致备库的效率相当低下。即使备库有很多磁盘、CPU或者内存，也会很容易落后于主库。因为备库的单线程通常只会有效地使用一个CPU和磁盘。而事实上，备库通常哦都会和主库使用相同配置的机器。
备库上的锁同样也是问题。其他在备库运行的查询可能会阻塞主复制线程，因为复制时单线程的，复制线程在等待时将无法做别的事情。复制一般有两种产生延迟的方式:突然产生延迟然后再跟上，或者稳定的延迟增大。前一种通常是由于一条运行很长的查询导致的，而后者即使在没有长时间运行的查询时也会出现。不幸的是，目前我们还没那么容易确定备库是否接近其容量上限。正如之前提到的。如果负载总是保持均匀的，备库在负载达到99%时和其负载10%的时候表现的性能相同，但一旦达到100%时就会突然产生延迟。但实际上负载不太可能很稳定，所以当备库接近写容量时，就可能在尖峰负载时看到复制延迟的增加。当备库无法跟上时，可以记录备库上的查询并使用一个日志分析工具找出哪里满了。不要依赖于自己的直觉，也不要基于查询在主库上的查询性能进行判断，因为主库和备库性能特征很不相同。最好的分析办法是暂时在备库上打开慢查询日志记录，然后使用pt-query-digest工具来分析。如果打开了log_slow_slave_statements选项，在标准的MySQL慢查询日志能够记录MySQL5.1及更新的版本中复制线程执行的语句，这样就可以找到在复制时哪些语句执行慢了。Percona Server和MariaDB允许开启或进制该选项而无须重启服务器。
除了购买更快的磁盘和CPU(固态硬盘能够提供极大的帮助)，备库没有太多的调优空间。大部分选项都是禁止某些额外的工作以减少备库的负载。一个简单的办法是配置InnoDB，使其不要那么频繁地刷新磁盘，这样事务会提交得更快些。可以通过设置innodb_flush_log_at_trx_commit得值为2来上限。还可以在备库上禁止二进制日志记录，把innodb_locks_unsafe_for_binlog设置为1，并把MyISAM得delay_key_write设置为ALL.但是这些设置以牺牲安全换取速度。如果需要将备库提升为主库，记得把这些选项设置回安全的值

来自主库的过大的包。
另一个难以追踪的问题是主库的max_allowed_packet值和备库的不匹配。在这种情况下，主库可能会记录一个备库认为过大的包。当备库获取到该二进制日志事件时，可能会碰到各种各样的问题，包括无限报错和充实，或者中继日志损坏

受限制的复制带宽。
如果使用受限的带宽进行复制，可以开启备库上的slave_compressed_protocol选项。当备库连接主库时，会请求一个被压缩的连接——和MySQL客户端使用的压缩连接一样。使用的压缩引擎是zlib,测试表明它能将文本类型的数据压缩到大约其原始大小的三分之一。其代价是需要额外的CPU时间，包括在主库上压缩数据和在备库上解压数据。
如果主库和备库间的连接是慢速连接，可能需要将分发主库和备库分布在同一地点。这样就只有一台服务器通过慢速连接和主库相连，可以减少链路上的带宽负载以及主库的CPU负载

磁盘空间不足。
复制有可能因为二进制日志、中继日志或临时文件将磁盘撑满，特别是在主库上执行了LOAD DATA INFILE查询并在备库开启了log_slave_updates选项。延迟越严重，接收到但尚未执行的中继日志会占用越多的磁盘空间。可以通过监控磁盘并设置relay_log_space选项来避免这个问题

复制的局限性。
MySQL复制可能失败或者不同步，不管有没有报错，这是因为其内部的限制导致的。大量的SQL函数和编程实践不能被可靠地复制。很难确保应用代码里不会出现这样或那样的问题，特别是应用或者团队非常庞大的时候。另外一个问题是服务器的bug,虽然听起来很消极，但大多数MySQL的主版本都存在着历史遗留的复制Bug。特别是每个主版本的第一个版本。诸如存储过程这样的新特性常常会导致更多的问题。
MySQL复制非常复杂，应用程序越复杂，你就需要越小心。但是如果学会了如何使用，复制会工作得很好。

正式的可扩展性定义。
有必要探讨以下可扩展性在数学上的定义了，这有助于在更高层次的概念上清晰地理解可扩展性。如果没有这样的基础，就可能无法理解或精确地表达可扩展性。不过不用担心，这里不会涉及高等数学，即使不是数学天才，也能够很直观地理解它。关键是前面使用的短语："划算的等同提升(equal bang for the buck)".另一种说法是，可扩展性是当增加资源以处理负载和增加容量时系统能够获得的投资产出率(ROI).假设有一个只有一台服务器的系统，并且能够测量它的最大容量，如图所示。下面用s表示服务器，c表示容量，假设我们现在增加一台服务器，系统的能力加倍，如图所示。这就是线性扩展。我们增加了一倍的服务器，结果增加了一倍的容量。大部分系统并不是线性扩展的，而是如图所示的扩展方式。大部分系统都只能以比线性扩展略低的扩展系数进行扩展，越高的扩展系数会导致越大的线性偏差。事实上，多数系统最终会达到一个最大吞吐量临界点，超过这个点后增加头伏反而会带来负回报——继续增加更多工作负载，实际上会降低系统的吞吐量(事实上，"投资产出率"也可以从金融投资的角度来考虑，将一个组件的容量升级到两倍所需要符出的常常不止是最初开销的两倍。虽然在现实世界里我们常常这么考虑，但在讨论中会将其忽略掉，因为它会使一个已经复杂的主题变得更加复杂)。这怎么可能呢？这些年产生了许多可扩展性模型，它们有着不同程度的良好表现和实用性。我们这里所讲的可扩展性模型是基于某些能够影响系统扩展的内在机制。这就是Neil J.Gunther博士提出的通用可扩展性定律(Universal Scalability Law, USL).Gunther博士将这些详尽地写到了他的书中，包括Guerrilla Capacity Planning(Springer).这里不会深入到背后的数学理论中。
简而言之，USL说的是线性扩展的偏差可通过两个因素来建立模型:无法并发执行的一部分工作，以及需要交互的另外一部分工作。为第一个因素建模就有了著名的Amdahl定律，它会导致吞吐量趋于平缓。如果部分任务无法并行，那么不管你如何分而治之，该任务至少需要串行部分的时间。
增加第二个因素——内部节点间或者进程间的通信——到Amdahl定律就得出了USL.这种通信的代价取决于通信信道的数量，而信道的数量将按照系统内工作者数量的二次方增长。因此最终开销比带来的收益增长得更快，这是产生扩展性倒退得原因。如图所示，阐明了目前讨论到的三个概念:线性扩展、Amdahl扩展以及USL扩展。大多数真实系统看起来更像USL取线。
USL可以应用于硬件和软件领域。对于硬件，横轴表示硬件的数量，例如服务器数量或CPU数量。每个硬件的工作量、数据大小以及查询的复杂度必须保持为常量(现实中很难精确定义硬件的可扩展性，因为当你改变你的系统中的服务器数量时很难保证哪些变量不变)。对于软件，横轴表示并发度，例如用户数或者线程数。每个并发的工作量必须保持为常量。有一点很重要，USL并不能完美地描述真实系统，它只是一个简化哦行。但这是一个很好的框架，可用于理解为什么系统增长无法带来等同的收益。它也揭示了一个构建高可扩展性系统的重要原则:在系统内尽量避免串行化和交互。
可以衡量一个系统并使用回归来确定串行和交互的量。你可以将它作为容量规划和性能预测评估的最优上限值。也可以检查系统是怎么偏离USL模型的，将其作为最差下限值以之处系统的哪一部分没有表现出它应有的性能。这两种情况下，USL给出了一个讨论可扩展性的参考。如果没有USL，那即使盯着系统看也无法直到期望的结果是什么。
另外一个理解可扩展性的框架是约束理论，它解释了如何通过减少依赖时间和统计变化(statistical variation)来改进系统的吞吐量和性能。这在Eliyahu M.Goldratt所撰写的The Goal(North River)一书中有描述，其中有一个关于管理制造业设备的眼神的比喻。尽管这看起来和数据库服务器没有什么关联，但其中包含的法则和排队理论以及其他运筹学方面是一样的

扩展模型不是最终定论。
虽然有许多理论，但在现实中能做到何种程度呢？正如牛顿定律被证明只有远低于光速时才合理，哪些"扩展性定律"也只是在某些场景下才能很好地工作的简化模型。有一种说法认为所有的模型都是错误的，但有一些模型还是有用的，特别是USL能够帮助理解一些导致扩展性差的因素。
当工作负载和其所运行的系统存在微妙的关系时，USL理论可能失效。例如，一个USL无法很好建模的常见情况是:当集群的总内存由于数据集大小而发生改变时，也会导致系统的行为发生变化。USL不允许比线性更好的可扩展性，但现实中可能会发生这样的事情:增加系统的资源后，原来一部分IO密集型的工作变成了纯内存工作，因此获得了超过线性的性能扩展。
还有一些情况，USL无法很好地描述系统行为。当系统或数据集大小改变时算法的复杂度可能改变，类似这样的情况可能就无法建立模型(USL由O(1)复杂度和O(N^2)复杂度两部分构成，那么对于诸如O(logN)或者O(NlogN)这样复杂度的部分呢？)根据一些思考和实际经验，我们可以将USL扩展以覆盖这些比较普遍的场景中的一部分。但这会将一个简单并且有用的模型变得复杂并难以使用。事实上，它在很多情况下都是很好地，足以为你所能想象到的系统行为建立模型，这也是为什么我们发现它是在正确性和有效性之间的一个很好的妥协。
简单地说:有保留地使用模型，并且在使用中验证你的发现

规划可扩展性。
人们通常只有在无法满足增加的负载时才会考虑到可扩展性，具体表现为工作负载从CPU密集型变成IO密集型，并发查询的竞争，以及不断增大的延迟。主要原因是查询的复杂度增加或者内存中驻留着一部分不再使用的数据或者索引。你可能看到一部分类型的查询发生改变，例如大的查询或者复杂查询常常比哪些小的查询更影响系统。如果是可扩展的应用，则可以简单地增加更多的服务器来分担负载，这样就没有性能问题了。但如果不是可扩展的，你会发现自己将遭遇到无穷无尽的问题。可以通过规划可扩展性来避免这个问题。
规划可扩展性最困难的部分是估算需要承担的负载到底有多少。这个值不一定非常精确，但必须在一定的数量级范围内。如果估计过高，会浪费开发资源。但如果低估了，则难以应付可能的负载。
另外还需要大致正确地估计日程表——也就是说，需要知道底线在哪里。对于一些应用，一个简单的原型可以很好地工作几个月，从而有事件去筹资建立一个更加扩展的架构。对于其他的一些应用，你可能需要当前的架构能够为未来两年提供足够的容量。
以下的问题可以帮助规划可扩展性:
1.应用的功能完成了多少?许多建议的可扩展性解决方案可能会导致实现某些功能变得更加困难。如果应用的某些核心功能还没有开始实现，就很难看出如何在一个可扩展的应用中实现它们。同样地，在知道这些特性如何真正地工作之前也很难决定，使用哪一种可扩展性解决方案
2.预期的最大负载是多少?应用应当在最大负载下也可以正常工作。如果你的网络和Yahoo!News或者Slashdot的首页一样，会发生什么呢？即使不是很热门的网站，也同样有最高负载。例如，对于一个在线零售商，假日期间——尤其是在圣诞前的几个星期——通常是负载达到巅峰的时候。在美国，情人节和母亲节前的周末对于在线花店来说也是负载高峰期
3.如果依赖系统的每个部分来分担负载，在某个部分失效时会发生什么呢？例如，如果依赖备库来分担读负载，当其中一个失效时，是否还能正常处理请求？是否需要禁用一些功能？可以预先准备一些空闲容量来防范这种问题

为扩展赢得时间。
在理想情况下，应该时计划先行，拥有足够的开发者、有花不完的预算，等等，但现实中这些情况会很复杂，在扩展应用时常常需要做一些妥协，特别是需要把对系统的改动推迟一段时间再执行。在深入MySQL扩展的细节前，以下是一些可以做的准备工作:
1.优化性能
很多时候可以通过一个简单的改动来获得明显的性能提升，例如为表建立正确的索引或从MyISAM切换到InnoDB存储引擎。如果遇到了性能限制，可以打开查询日志进行分析。在修复了大多数主要的问题后，会到达一个收益递减点，这时候提升性能会变得越来越困难。每个新的优化都可能耗费更多的经历但只有很小的提升，并会使应用更加复杂
2.购买性能更强的硬件
升级或增加服务器在某些场景下行之有效，特别使对于处于软件生命周期早期的应用，购买更多的服务器或者增加内存通常是个好办法。另一个选择是尽量在一台服务器上运行应用程序。比起修改应用的涉及，购买更多的硬件可能是更实际办法，特别是时间紧急并且缺乏开发者的时候。

如果应用很小或者被涉及为便于利用更多的硬件，那么购买更多的硬件应该是行之有效的办法。对于新应用这是很普遍的，因为它们通常很小或者涉及合理。但对于大型的旧应用，购买更多硬件可能没什么效果，或者代价太高。服务器从1台增加到3台或许算不了什么，但从100台增加到300台就是另外一回事儿了——代价非常昂贵。如果是这样，花一些时间和经历来尽可能地提升现有系统的性能就很划算

向上扩展。
向上扩展(有时也称为垂直扩展)意味着购买更多性能强悍的硬件，对很多应用来说这是唯一需要做的事情。这种策略有很多好处。例如，单台服务器比多台服务器更加容易维护和开发，能显著节约开销。在单台服务器上备份和恢复应用很简单，因为无须关注以执行或者哪个数据集是权威的。当然还有一些别的原因。从复杂性的成本来说，向上扩展比向外扩展更简单。
向上扩展的空间起始也很大。拥有0.5TB内存、32核(或者更多)CPU以及更强悍IO性能的(例如PCIe卡的flash存储)商用服务器现在很容易获得。优秀的应用核数据库涉及，以及很好的性能优化技能，可以帮助你在这样的服务器上建立一个MySQL大型应用。
在现代硬件上MySQL能扩展到多大的规模呢？尽管可以在非常强大的服务器上运行，但和大多数数据库服务器一样，在增加硬件资源的情况下MySQL也无法很好地扩展(非常奇怪!)。为了更好地在大型服务器上运行MySQL,一定要尽量选择最新的版本，由于内部可扩展性问题，MySQL5.0和5.1在大型硬件里的表现并不理想。建议使用5.5或者更新的版本，或者Percona Server5.1及后续版本。即便如此，当前合理的"收益递减点"的机器配置大约是256GB RAM，32核CPU以及一个PCIe flash驱动器，如果继续提升硬件的配置，MySQL的性能虽然还能有所提升，但性价比就会降低，实际上，在更强大的系统上，也可以通过运行多个小的MySQL实例来替代单个大实例，这样可以获得更好的性能。当然，机器配置的变化速度非常快，这个建议也许很快就会过时了。
向上扩展的策略能够顶一段时间，实际很多应用是不会达到天花板的。但是如果应用变得非常大，向上扩展可能就没有办法了。第一个原因是前，无论服务器上运行什么样的软件，从某种程度来看，向上扩展都是个糟糕的财务决策，当超过硬件能够提供的最优性价比时，就会需要非同寻常的特殊配置的硬件，这样的硬件往往非常昂贵。这意味着能向上扩展到什么地步是有实际的限制的。如果使用了复制，那么当主库升级到高端硬件后，一般是不太可能配置出一台能够跟上主库的强大备库的。一个高负载的主库通常可以承担比拥有同样配置的备库更多的工作因为备库的复制线程无法高效地利用多核CPU和磁盘资源.
最后，向上扩展不是无限制的，即使最强大的计算机也有限制。单服务器应用通常会首先达到读限制，特别是执行复杂的读查询时。类似这样的查询在MySQL内部是单线程的新，如图所示，因此只能使用一个CPU,这种情况下花钱也无法提升性能。即使购买最快地CPU也仅仅会是商用CPU的几倍速度。增加更多的CPU或CPU和数并不能使得慢查询执行得更快。当数据变得庞大以至于无法有效缓存时，内存也会称为瓶颈，这通常表现为很高的磁盘使用率，而磁盘是现在计算机中最慢的部分。
无法使用向上扩展最明显的场景是云计算。在大多数公有云中都无法获得性能非常强的服务器，如果应用肯定会变得非常庞大，就不能选择向上扩展的方式。
因此，建议，如果系统确实有可能碰到可扩展性的天花板，并且会导致严重的业务问题，那就不要无限制地做向上扩展的规划。如果你知道应用会变得很庞大，在实现另外一种解决方案前，短期内购买更优的服务器是可以的。但是最终还是需要向外扩展。

向外扩展。
可以把向外扩展(有时也称为横向扩展或水平扩展)策略划分为三个部分:复制、拆分以及数据分片(sharding).最简单也最常见的向外扩展的方法是通过复制将数据分发到多个服务器上，然后将备库用于读查询。这种技术对于以读为主的应用很有效。它也有一些缺点，例如重复缓存，但如果数据规模有限这就不是问题。另外一个比较常见的向外扩展是工作负载分布到多个"节点"。具体如何分布工作负载是一个复杂的话题。许多大型的MySQL应用不能自动分布负载，就算有也没有做到完全的自动化。后面会讨论一些可能的分布负载的方案，并探讨它们的优点和缺点。
在MySQL架构中，一个节点(node)就是一个功能部件。如果没有规划冗余和高可用性。那么一个节点可能就是一台服务器。如果设计的是能够故障转移的冗余系统，那么一个节点通常可能是下面的某一种:
1.一个主——主复制双机结构，拥有一个主动服务器和被动服务器
2.一个主库和多个备库
3.一个主动服务器，并使用分布式复制块设备(DRBD)作为备用服务器
4.一个基于存储区域网络(SAN)的"集群"
大多数情况下，一个节点内的所有服务器应该拥有相同的数据。我们倾向把主——主复制架构作为两台服务器的主动——被动节点

通过多实例扩展。
一个分片较多的架构可能会更有效地利用硬件。研究和经验表名MySQL并不能完全发挥现代硬件的性能。当扩展到超过24个CPU核心时，MySQL的性能开始趋于平缓，不再上升。当内存超过128GB时也同样如此，MySQL甚至不能完全发挥诸如Virident或Fusion-io卡这样的高端PCIe flash设备的IO性能。
不要在一台性能强悍的机器上只运行一个服务器实例，我们还有别的选择。你可以让数据分片足够小，以使每台机器上都能放置多个分片(这也是一直提倡的)，每台服务器上运行多个实例，然后划分服务器的硬件资源，将其分配给每个实例。这样做尽管比较繁琐，但确实有效。这是一种向上扩展和向外扩展的组合方案。也可以用其他方法来实现——不一定需要分派你——但分片对于在大型服务器上的联合扩展具有天然的适应性。
一些人倾向于通过虚拟化技术来实现合并扩展，这有它的好处。但虚拟化技术本身有很大的性能损耗。具体损耗多少取决于具体的技术，但通常都比较明显，尤其是IO非常快的时候损坏会非常惊人。另一种选择是运行多个MySQL实例，每个实例监听不同的网络端口，或绑定到不同的IP地址。
我们已经在一台性能强悍的硬件上获得了10倍或15倍的合并系数。你需要平衡管理复杂度代价和更优性能的收益，以决定哪种方法是最优的。这时候网络可能会成为瓶颈——这个问题大多数MySQL用户都不会遇到。可以通过使用多块网卡并进行绑定来解决这个问题。但Linux内核可能会不理想，这取决于内核版本，因为老的内核对每个绑定设备的网络中断只能使用一个CPU。因此不要把太多的连接绑定到很少的虚拟设备上，否则会遇到内核层的网络瓶颈。新的内核在这一方面会有所改善，所以需要检查你的系统版本，以确定该怎么做。
另一个方法是将每个MySQL实例绑定到待定的CPU核心上。这有两点好处:第一，由于MySQL内部的可扩展性限制，当核心数较少时，能够在每个核心上获得更好的性能;第二，当实例在多个核心上运行线程时，由于需要在多核心上同步共享数据，因为会有一些额外的开销。这可以避免硬件本身的可扩展性限制。限制MySQL到少数几个核心能够帮助减少CPU核心之间的交互。注意到反复出现的问题了没？将进程绑定到具有相同物理套接字的和欣赏可以获得最优的效果.

通过集群扩展。
理想的扩展方案时单一逻辑数据库能够存储尽可能多的数据，处理尽可能多的查询，并如期望的那样增长。许多人的第一想法就是建立一个"集群"或者"网格"来无缝处理这些事情，这样应用就无须去做太多工作，也不需要知道数据到底存在哪台服务器上。随者云计算的流行，自动扩展——根据负载或数据大小变化动态地在集群中增加/移除服务器——变得越来越有趣。网上出现了许多被称为NoSQL的技术。许多NoSQL的支持者发表了一些奇怪且未经证实的观点，例如"关系型模型无法进行扩展"，或者"SQL无法扩展"。随者新概念的出现，也出现了一些新的术语。最近谁没有听说过最终一致性、BASE、矢量时钟，或者CAP理论呢？
但随者时间推移，理性开始主键回归。经验表名许多NoSQL数据库太过于简单，并且无法完成很多工作。同时一些基于SQL的技术开始出现——例如451集团(451 Group)的Matt Aslett所提到的NewSQL数据库。SQL和NewSQL到底有什么区别呢？NewSQL数据库中的SQL及相关技术都不应该成为问题。而可扩展性问题在关系型数据库中是一个是线上的难题，但新的实现正表现出越来越好的结果。所有的旧事物都变成新的了嘛？是，但也不是。许多关系型数据库集群的高性能涉及正在倍构建到系统的更底层，在NoSQL数据库中，特别是使用键——值存储时，这一点很明显。例如NDB Cluster并不是一个SQL数据库;它是一个可扩展的数据库，使用其原生API来控制，通常是使用NoSQL，但也可以通过在前端使用MySQL存储引擎来支持SQL。它是一个完全分布式、非共享高性能、自动分片并且不存在单点故障的事务型数据库服务器。最近几年正变得更强大、更复杂，用途也更广泛。同时，NoSQL数据库也逐渐看起来越来越像关系型数据库。有些甚至还开发了类SQL查询语言。未来典型的集群数据库可能更像是SQL和NoSQL的混合体，有多种存取机制来满足不同的使用需求。所以，我们可以从NoSQL中汲取优点，但SQL仍然会保留在集群数据库中。
和MySQL结合在一起的集群或分布式数据库技术大致包括:NDB Cluster、Clustrix、Percona XtraDB Cluster、Galera、Schooner Active Cluster、Continuent Tungsten、ScaleBase、ScaleArc、dbShards、Xeround、Akiban、VoltDB,以及GenieDB。这或多或少以MySQL为基础，或通过MySQL进行控制，或是和MySQL相关。
在开始前，需要指出，可扩展性、高可用性、事务性等是数据库系统的不同特性。许多人会感到困惑并将这些当作是相同的东西，但事实上不是。可扩展的数据库并不一定非常优秀，除非它能保证高性能，谁愿意牺牲高可用性来进行扩展呢？这些特性的组合堪称数据库的必杀技，但这很难实现。最后，除NDB Cluster外，大多数NewSQL集群产品都是比较新的事物。其他产品还没有看到足够多的生产环境部署以完全获知其优点和限制。尽管它们提到了MySQL协议或其他与MySQL相关的地方，但它们毕竟不是MySQL,所以这里仅仅稍微提一下，然后需要自己来判断它们是否适用。

向内扩展.
处理不断增长的数据和负载最简单的办法是对不再需要的数据进行归档和清理，这种操作可能会带来显著的成效，具体取决于工作负载和数据特性。这种做法并不用来代替其他策略，但可以作为争取时间的短期策略，也可以作为处理大数据量的长期计划之一。在设计归档和清理策略时需要考虑到如下几点:
1.对应用的影响
一个设计良好的归档系统能够在不影响事务处理的情况下，从一个高负载的OLTP服务器上移除数据。这里的关键是能高效地找到要删除的行，然后一小块一小块地移除。通常需要平衡一次归档的行数和事务的大小，以找到一个锁竞争和事务负载量的平衡。还需要设计归档任务在必要的时候让步于事务处理
2.要归档的行
当知道某些数据不再使用后，就可以立刻清理或归档它们。也可以设计应用去归档那些几乎不怎么使用的数据。可以把归档的数据置于核心表父进附近通过视图来访问，或完全转移到别的服务器上
3.维护数据一致性
当数据间存在联系时，会导致归档和清理工作更加复杂。一个设计良好的归档任务能够保证数据的逻辑一致性.或至少在应用需要时能够保证一致，而无须在大量事务中包含多个表。当表之间存在关系时，哪个表首先归档是个问题。在归档时需要考虑孤立行的影响。可以选择违背外键约束(可以通过执行SET FOREIGN_KEY_CHECKS=0禁止InnoDB的外键约束)或暂时把"悬空指针"(dangling pointer)记录放到一边。如果应用层认为这些相关联的表具有层次关系，那么归档的顺序也应该和它一样。例如，如果应用总是先检查订单再检查发货单，就先归档订单。应用应该看不到孤立的发货单，因此接下来就可以将返货但归档。
4.避免数据丢失
如果是再服务器间归档，归档期间可能就无法做分布式事务，也有可能将数据归档到MyISAM或其他非事务型的存储引擎中。因此，为了避免数据丢失，再从源表中删除时，要保证已经在目标机器上保存。将归档数据单独写到一个文件里也是个好主意。可以将归档任务设计为能够随时关闭或重启，并且不会引起不一致或索引冲突之类的错误。
5.解除归档(unarchiving)
可以通过一些解除归档策略来减少归档的数据量。它可以帮助你归档那些不确定是否需要的数据，并在以后可以通过选项进行回退。如果可以设置一些检查点让系统来检查是否有需要归档的数据，那么这应该时一个很容易实现的策略。例如，要对不活跃的用户进行归档，检查点就可以设置在登录验证时。如果因为用户不存在导致登录失败，可以去检查归档数据中是否存在该用户，如果有，则从中取出来并完成登录。
Percona Toolkit包含的工具pt-archiver能够帮助你有效地归档和清理MySQL表，但不提供解除归档功能

直接连接。
有些人认为负载均衡就是配置在应用和MySQL服务器之间的东西。但这并不是唯一的负载均衡方法。你可以在保持应用和MySQL连接的情况下使用负载均衡。事实上，集中化的负载均衡系统只有在存在一个对等置换的服务器池时才能很好工作。如果应用需要做一些决策，例如在悲苦上执行读操作是否安全，就需要直接连接到服务器。除了可能出现的一些特定逻辑，应用为负载均衡做决策是非常高效的。例如，如果有两个完全相同的备库，你可以使用其中的一个来处理特定分片的数据查询，另一个处理其他的查询。这样能够有效利用备库的内存，因为每个备库只会缓存一部分数据。如果其中一个备库失效，另外一个备库拥有所有的数据，仍然能提供服务。

引入中间件。
迄今为止，我们所讨论的方案都嘉定应用跟MySQL服务器使直接相连的。但是许多负载均衡解决方案都会引入一个中间件，作为网络通信的代理。它以便接受所有的通信请求，另一边将这些请求派发到指定的服务器上，然后把执行结果发送回请求的机器上。中间件可以实硬件设备或时软件(你可以把诸如LVS这样的解决方案配置成只有一个用需要创建一个新连接时才参与进来，此后不再作为中间价)。如图描述了这种架构，这种解决方案通常能工作得很好，当然除非为负载均衡器本身增加冗余，这样才能避免单点故障引起的整个系统瘫痪。从开源软件，如HAProxy，到许多广为人知的商业系统，有许多负载均衡器得到了成功的应用

一主多备间的负载均衡。
最常见的复制拓扑结构就是一个主库加多个备库。我们很难绕开这个架构，许多应用都假设只有一个目标机器用于所有的写操作，或者所有的数据都可以从单个服务器上获得。尽管这个架构不太具有很好的可扩展性，但可以通过一些办法结合负载均衡来获得很好的效果。
1.功能分区
对于特定的目的可以通过配置备库或一组备库来极大地阔扎脑容量。一些比较常见的功能包括报表、分析、数据仓库，以及全文检索
2.过滤和数据分区
可以适用适用复制过滤技术在相似的备库上对数据进行分区。只要数据在主库上已经被隔离到不同的数据库或表中，这种方法就可以奏效。不幸的是，没有内建的八幡在行级别上进行复制过滤。你需要适用一些独创性的技术来实现这一点，例如适用触发器和一组不同的表。即使不把数据分区到各个备库上，也可以通过对读进行分区而不是随机分配来提高缓存效率。例如，可以把对以字母A-M开头的用户的读操作分配给一个给定的备库，把N-Z开头的分配给另外一个。这能够更好地利用每台机器的缓存，因为分离读更可能在缓存中找到相关的数据。最好的情况下，当没有写操作时，这样适用的缓存相当于两台服务器缓存的综合。相比之下，如果随机地在备库上分配读操作，每个机器的缓存本质上还是重复的数据，而总的有效缓存效率和一个备库缓存一样，不管你有多少台备库。
3.将部分写操作转移到备库
主库并不总是需要处理写操作中的所有工作。你可以分解写擦汗寻，并在备库上执行其中的一部分，从而显著减少主库的工作量
4.保证备库跟上主库
如果要在备库执行某种操作，他需要即使知道数据处于哪个时间点——哪怕需要等待一会儿才能到达这个点——可以适用函数MASTER_POS_WAIT()阻塞直到备库赶上了设置的主库同步点。另一种替代方案是复制复制心跳来检查延迟情况
5.同步写操作
也可以使用MASTER_POS_WAIT()函数来确保写操作已经被同步到一个或多个备库上。如果应用需要模拟同步复制来确保数据安全性，就可以在多个备库上轮流执行MASTER_POS_WAIT()函数。这就类似创建了一个"同步屏障"，但任意一个备库出现复制延迟时，都可能花费很长时间完成，所以最好在确实需要的时候才适用这种方法(如果你的目的只是确保某些备库拥有时间，可以只等待一台备库接收到时间，MySQL5.5增加了半同步复制，能够支持这项技术)

提升平均失效时间(MTBF).
其实只要尽职尽责地做好一些应做的事情，就可以避免很多宕机。在分类整理宕机事件并追查导致宕机的根源时，还发现，很多宕机本来是有一些方法可以避免的。我们发现大部分宕机事件都可以通过全面的常识性系统管理办法来避免。以下是做一些指导性的建议:
1.测试恢复工具和流程，包括从备份中恢复数据
2.遵从最小权限原则
3.保持系统干净、整洁
4.使用好的命名和组织约定来避免产生混乱，例如服务器是用于开发还是用于生产环境
5.谨慎安排升级数据库服务器
6.在升级前，使用诸如Percona Toolkit中的pt-upgrade之类的工具仔细检查系统
7.使用InnoDB并进行适当的配置，确保InnoDB是默认存储引擎。如果存储引擎被禁止，服务器就无法启动
8.确认基本的服务器配置是正确的
9.通过skip_name_resolve禁止DNS
10.除非能证明有效，否则禁用查询缓存
11.避免使用复杂的特性，例如复制过滤和触发器，除非确实需要
12.监控重要的组建和功能，特别是像磁盘空间和RAID卷状态这样的关键享目，但也要避免误报，只有当确实发生问题时才发送告警
13.定期检查复制完整性
14.讲备库设置为只读，不要让复制自动启动
15.定期进行查询语句审查
16.归档并清理不需要的数据
17.为文件系统保留一些空间。在GNU/Linux中，可以使用-m选项来为文件系统本身保留空间。还可以在LVM卷组中留下一些空闲空间。或者，更简单的方法，仅仅创建一个巨大的空文件，在文件系统快满时，直接将其删除(这是100%跨平台兼容的)
18.养成习惯，评估和管理系统的改变、状态以及性能信息

我们发现对系统变更管理的缺失时所有导致宕机的实践中最扑鼻那的原因。典型的错误包括粗心的升级导致升级失败并遭遇一些Bug，或是尚未测试就将Schema或查询语句的更改直接运行到线上，或者没有为一些失败的情况制定计划，例如达到了磁盘容量限制。另外一个导致问题的主要原因是缺少严格的评估，例如因为疏忽没有确认备份是否是可以恢复的。最后，可能没有正确地监控MySQL的相关信息。例如缓存命中率报警并不能说明问题，并且可能产生大量的误报，这会使监控系统被认为不太有用，于是一些人就会忽略报警。有时候监控系统失效了，甚至没人会注意到，直至你的老板质问你，"为什么Nagios没有告诉我们磁盘已经满了?"

降低平均恢复时间(MTTR).
之前提到，可以通过减少恢复时间来获得高可用性。事实上，一些人走的更远，只专注于减少恢复时间的某个方面:通过在系统中建立冗余来避免系统完全失效，并避免单点失效问题。在降低恢复时间上进行投资非常虫咬，一个能够提供冗余和故障转移能力的系统架构则是降低恢复时间的关键环节。但实现高可用性不单单是技术问题，还有许多个人和组织的因素。组织和个人在避免宕机和从宕机事件中恢复的成熟度和能力层次各不相同。
团队成员是最重要的高可用性资产，所以为恢复制定一个好的流程非常重要。拥有熟练技能、应变能力、训练有素的雇员，以及处理紧急事件的详细文档和经过仔细测试的流程，对从宕机中恢复有巨大的作用。但也不能完全依赖工具和系统，因为它们并不能理解实际情况的细微差别，有时候它们的行为在一般情况下是正确的，但在某些场景下却会是个灾难
对宕机事件进行评估有助于提升组织学习能力，可以帮助避免未来发生相似的错误，但是不要对"事后反思"或"事后的调查分析"期待太高。后见之明被严重曲解，并且一味想找到导致问题的唯一根源，这可能会影响你的判断力。许多流行的方法，例如"五个为什么"，可能会被过度使用，导致一些人将他们的经历集中在找到唯一的替罪羊。很难去回顾我们解决的问题当时所处的状况，也很难理解真正的原因，因为原因通常是多方面的。因此，尽管事后反思可能是有用的，但也应该对结论有所保留。即使是这里给出的建议，也是基于长期研究导致宕机事件的原因以及如何预防它们所得，并且只是这里的观点而已。
这里要反复提醒:所有的宕机事件都是由多方面的失效联合在一起导致的。因此可以通过利用合适的方法确保单点的安全来避免。整个链条必须要打断，而不仅仅是单个环节。例如，那些问我们求助恢复数据的人不仅遭受数据丢失(存储失效，DBA误操作等)。同时还缺少一个可用的备份。
这样说来，当开始调查并尝试阻止失效或加速恢复时，大多数人和组织不应太过于内疚，而是要专注于技术上的一些措施——特别是那些很酷的方法，例如集群系统和冗余架构。这些是有用的，但要记住这些系统依然会失效。事实上，前面提到的MMM复制管理，已经对它失去了型取，因为它被证明可能导致更多的宕机事件。你应该不会奇怪一组Perl脚本会陷入混乱，但即使是特别昂贵并精密设计的系统也会出现灾难性的失效——是的，即使是花费了大量金钱的SAN也是如此。已经见过太多的SAN失效

共享存储或磁盘复制。
共享存储能够为数据库服务器和存储解耦合，通常使用的是SAN.使用共享存储时，服务器能够正常挂载文件系统并进行操作。如果服务器挂了，备用服务器可以挂载相同的文件系统，执行需要的恢复操作，并在失效服务器的数据上启动MySQL.这个过程在逻辑上跟修复那台故障的服务器没什么两样，不过更快速，因为备用服务器已经启动，随时可以运行。当开始故障转移时，检查文件系统、恢复InnoDB以及预热(Percona Server提供了一个新特性，能够把buffer pool保存下来并在重启后还原，在使用共享存储时能够很好地工作。这可以减少几个小时甚至好几天的预热时间。MySQL5.6也有相似的特性。)是最有可能遇到延迟的地方，但检测失效本身在许多设置中也会花费很长时间。
共享存储有两个优点:可以避免除存储外的其他任何组件失效所引起的数据丢失，并为非存储组件建立冗余提供可能。因此它有助于减少系统一些部分的可用性需求，这样就可以集中精力关注一小部分组件来获得高可用性。不过，共享存储本身仍然是可能失效的单点。如果共享存储失效了，那整个系统也失效了，尽管SAN通常设计良好，但也可能失效，有时候需要特别关注，就算SAN本身拥有冗余也会失效。
共享存储本身也有风险，如果MySQL崩溃等故障导致数据文件损坏，可能会导致备用服务器无法恢复。我们强烈建议在使用共享存储策略时选择InnoDB存储引擎或其他稳定的ACID存储引擎。一次崩溃几乎肯定会损坏MyISAM表，需要花费很长时间来修复，并且会丢失数据。我们也强烈建议使用日志型文件系统。我们见过比较严重的情况是，使用非日志型文件系统和SAN(这是文件系统的问题，跟SAN无关)导致数据损坏无法恢复。
磁盘复制技术是另外一个获得跟SAN类似效果的方法。MySQL中最普遍使用的磁盘复制技术是DRBP,并结合Linux-HA享目中的工具使用。DRBD是一个以Linux内核模块方式实现的块级别同步复制技术。它通过网卡将主服务器的每个块复制到另外一个服务器上的块设备上(备用设备)，并在主设备提交块之前记录下来(事实上可以调整DRBD的同步级别，将其设置成异步等待远程设备接收数据，或者在远程设备将数据写入磁盘前一直阻塞住。同样，强烈建议为DRBD专门使用一块网卡)。由于在备用DRBD设备上的写入必须要在主设备上的写入完成之前，因此备用设备的性能至少要和主设备一样，否则就会限制主设备的写入性能。同样，如果正在使用DRBD磁盘复制技术以保证在主设备失效时有一个可随时替换的备用设备，备用服务器的硬件应该跟主服务器的相匹配。带电池写缓存的RAID控制器对DRBD而言几乎是必需的，因为在没有这样的控制器时性能可能会很差。
如果主服务器失效，可以备用设备提升为主设备。因为DRBD是在磁盘块层进行复制，而文件系统也可能会不一致。这意味着最好是使用日志型文件系统来做快速恢复。一旦设备恢复完成，MySQL还需要运行自身的恢复。原故障服务器恢复后，会与新的主设备进行同步，并假定自身角色为备用设备。
从如何实际地实现故障转移的角度来看，DRBD和SAN很相似:有一个热备机器，开始提供服务时会使用和故障机器相同的数据，最大的不同时，DRBD是复制存储——不是共享存储——所以当使用DRBD时，获得的是一份复制的数据，而SAN则是使用与故障机器同一物理设备上的相同数副本。换句话说，磁盘复制技术的数据是冗余的，所以存储的数据本身都不会存在单点失效问题。这两种情况下，当启动备用机器时，MySQL服务器的缓存都是空的。相比之下，备库的缓存至少是部分预热的。

DRBD有一些很好的特性和功能，可以防止集群软件普遍会遇到的一些问题。一个典型的例子是"脑裂综合征"，在两个节点同时提升自己为主服务器时会发生这种问题。可以通过配置DRBD来防止这种事情发生。但是DRBD也不是一个能满足所有需求的完美解决方案。我们来看看它有哪些缺点:
1.DRBD的故障转移无法做到秒级别以内。它通常需要至少几秒钟时间来将设备提升成主设备，这还不包括任何必要的文件系统恢复和MySQL恢复
2.它很昂贵，因为必需在主动——被动模式下运行。热备服务器的复制设备因为处于被动模式，无法用于其他任务。当然这不是缺点取决于看问题的角度。如果你希望获得真正的高可用性并且在发生故障时不能容忍服务降级，就不应该在一台机器上运行两台服务器的负载量，因为如果这么做了，当其中一台发生故障时，就无法处理这些负载了。可以用这些备用服务器做一些其他用途，例如用作备库，但还是会有一些资源浪费。
3.对于MyISAM表实际上用处不打，因为MyISAM表崩溃后需要花费很长时间来检查和修复。对任何期望获得高可用性的系统而言，MyISAM都不是一个好选择;请使用InnoDB或其他支持快速、安全恢复的存储引擎来代替MyISAM
4.DRBD无法代替备份。如果磁盘由于蓄意的破坏、误操作、Bug或者其他硬件故障导致数据损坏，DRBD将无济于事。此时复制的数据只是被损坏数据的完美副本。你需要使用备份(或MySQL延时复制)来避免这些问题。
5.对写操作而言增加了负担。具体会增加多少负担呢？通常可以使用百分比来表示，但这并不是一个好的度量方法。你需要理解写入时增加的延迟主要由网络往返开销和远程服务器存储导致，特别时对于小的写入而言延迟会更大。尽管增加的延迟可能也就0.3ms,这看起来比在本地磁盘上IO的4~10ms的延迟要小很多，但却是正常的带有写缓存的RAID控制器的延迟的3~4倍。使用DRBD导致服务器变慢最常见的原因时MySQL使用InnoDB并采取了完全持久化模式(这里的意思时Innodb_flush_log_at_trx_commit=1的情况)。这会导致许多小的写入和fsync()调用，通过DRBD同步时会非常慢

MySQL同步复制。
当使用同步复制时，主库上的事务只有在至少一个备库上提交后才能认为其执行完成。这实现了两个目标:当服务器崩溃时没有提交的事务会丢失，并且至少有一个备库拥有实时的数据副本。大多数同步复制架构运行在主动——主动模式。这意味着每个服务器在任何时候都是故障转移的候选者，这使得通过冗余关于获得高可用性更加容易，早期版本的MySQL不支持同步复制(MySQL5.5支持半同步复制)，还有两个基于MySQL的集群解决方案支持同步复制。

基于复制的冗余。
复制管理器是使用标准MySQL复制来创建冗余的工具(冗余并不等同于高可用性)。尽管可以通过复制来改善可用性，但也有一些"玻璃天花板"会阻止MySQL当前版本的异步复制和半同步复制获得和真正的同步复制相同的结果。复制无法保证实时的故障转移和数据零丢失，也无法将所有节点等同对待。
复制管理器通常监控和管理三件事:应用和MySQL间的通信、MySQL服务器的健康度，以及MySQL服务器间的复制关系。它们既可以修改负载均衡的配置，也可以在必要的时候转移虚拟IP地址以使应用连接到合适的服务器上，还能够在一个伪集群中操作复制以选择一个服务器作为写入节点。大体上操作并不复杂:只需要确定写入不会发送到一个还没有准备好提供写服务的服务器上，并保证当需要提升一台备库为主库时记录下正确的复制坐标。
这听起来在理论上是可行的，但经验表明实际上并不总是能有效工作。事实上这非常糟糕，有些时候最好有一些轻量级的工具集来帮助从常见的故障中恢复并以很少的开销获得较高的可用性。不幸的是，还没有听说过任何一个好的工具及可以可靠地完成这一点。后面会介绍两个复制管理器，其中一个很新，而另外一个则有很多问题。
我们发现很多人试图去写自己的复制管理器。它们常常会陷入很多人已经遭遇过的陷阱，自己去写一个复制管理器并不是好主意。异步组件有大量的故障形式，很多你从未亲身经历过，其中一些甚至无法理解，并且程序也无法适当处理。因此从这些异步组件中得到正确的行为相当困难，并且可能遭遇数据丢失的危险。事实上，机器刚开始出现问题时，由一个经验丰富的人来解决时很快的。但如果其他人做了一些错误的修复操作则可能导致问题更严重
我们要提到的第一个复制管理器时MMM.有些人认为它在一些人工——故障转移模式下的场景下比较有用，而有些人甚至从不使用这个工具。许多人在自动——故障转移模式下使用该工具时确实遇到了许多严重的问题。它会导致健康的服务器离线，也可能将写入发送到错误的地点，并将备库移动到错误的坐标。有时混乱就接踵而至.
另外一个比较新一点的工具时Yoshinori Matsunobu 的MHA工具集，它和MMM一样时一组脚本，使用相同的通用技术来建立一个伪集群，但它不是一个完全的替换这；它不会去做太多的事情，并且依赖于Pecemaker来转移虚拟IP地址。一个主要的不同是，MHA有一个很好的测试集，可以防止一些MMM遇到过的问题。除此之外对该工具集还没有更多的认识。
基于复制的冗余最终来说好坏参半。只有在可用性的重要性远比一致性或数据零丢失保证更重要时才推荐使用。例如，一些人并不会真的从它们的网站功能重获利，而是从它的可用性重赚钱。谁会在乎是否出现了故障导致一张照片丢失了几条评论或者其他什么东西呢？只要广告收益继续滚滚而来，可能并不值得花更多成本去实现真正的高可用性。但还是可以通过复制来建立"尽可能的"高可用性，当遇到一些很难处理的严重宕机时，可能会有所帮助。这是一个大赌注，并且可能对大多数人而言太过于冒险，除非是哪些老成(或者专业)的用户。
问题时许多用户不知道如何去证明自己有资格并评估复制"轮盘赌"是否适合它们。这有两个方面的原因。第一，它们并没有看到"玻璃天花板"，错误地认为一组虚拟IP地址、复制以及管理脚本能够实现真正的高可用性。第二，它们低估了技术的复杂度，因此也低估了严重故障发生后从中恢复的难度。一些人认为它们能够使用基于复制的冗余技术，但随后它们可能会更希望选择一个有更强保障的简单系统。
其他一些类型的复制，例如DRBD或者SAN，也有他们的缺点——但也不要认为将这些技术说的无所不能而把MySQL自身的复制贬得一团糟，那不是本意。你可以为DRBD写出低质量的故障转移脚本，这很简单，就像为MySQL复制编写脚本一样。主要的区别时MySQL复制非常复杂，有很多非常细小的差别，并且不会阻止你干坏事

提升备库或切换角色。
提升一台备库为主库，或者在一个主——主复制结构中调换主动和被动角色，这些都是许多MySQL故障转移策略很重要的一部分。我们不能认定自动化工具总能在所有的情况下做正确地事情。你不应该假定在发生故障时能够立刻切换到被动备库，这要看具体的工作负载。备库会重放主库的写入，但如果不用来提供读操作，就无法进行预热来为生产环境负载提供服务。如果希望有一个随时能承担读负载的备库，就要不断地"训练"它，既可以将其用于分担工作负载，也可以将生产环境地读查询镜像到备库上。我们有时候通过监听TCP流量，截取除其中地SELECT查询，然后在备库上重放来实现这个目的。Percona Toolkit中有一些工具可以做到这一点。

虚拟IP地址或IP接管。
可以为需要提供特定服务的MySQL实例指定一个逻辑IP地址。当MySQL实例失效时，可以将IP地址转移到另一台MySQL服务器上。这和前面提到的思想本质是相同的，唯一的不同是现在是用于故障转移，而不是负载均衡。
这种方法的好处是对应用透明。它会中断已有的连接，但不要求修改配置。有时候还可以原子地转移IP地址，保证所有的应用在同一时间看到这一变更。当服务器在可用和不可用状态间"摇摆"时，这一点尤其重要。以下是它的一些不足之处:
1.需要把所有的IP地址定义在同一网段，或者使用网络桥接
2.改变IP地址需要系统root权限
3.有时候还需要更新ARP缓存。有些网络设备可能会把ARP信息保存太久，以致无法即时将一个IP地址切换到另一个MAC地址上。我们看到过很多网络设备或其他组件不配合切换的例子，结果系统的许多部分可能无法确定IP地址到底在哪里
4.需要确定网络硬件支持快速IP接管。有些硬件需要克隆MAC地址后才能工作
5.有些服务器即使完全丧失功能也会保持持有IP地址，所以可能需要从物理上关闭或断开网络连接。这就是为人所熟知的"击中其他节点的头部"(shoot the other node in the head 简称STONITH).他还有一个更加微妙并且比较官方的名字:击剑(fencing)

浮动IP地址和IP接管能够很好地应付彼此临近(也就是同一子网内)的机器之间的故障转移。但是最后需要提醒的是，这种策略并不总是万无一失，还取决于网络硬件等因素

中间件解决方案。
可以使用代理、端口转发、网络地址转换(NAT)或者硬件负载均衡来实现故障转移和故障恢复。这些都是很好的解决方法，不像其他方法可能会引入一些不确定性(所有系统组件认同哪一个是主库码？它能够即使并原子地更改吗？)它们是控制应用和服务器连接的中枢。但是，它们自身也引入了单点失效，需要准备冗余来避免这个问题。
使用这样的解决方案，你可以将一个远程数据中心设置成看起来好像和应用在同一个网络里。这样就可以使用诸如浮动IP地址这样的技术让应用和一个完全不同的数据中心开始通信。你可以配置每个数据中心的每台应用服务器，通过它自己的中间件连接，将流量路由到活跃数据中心的机器上，如图所示。
如果活跃数据中心安装的MySQL彻底崩溃了，中间件可以路由流量到另外一个数据中心的服务器池中，应用无须知道这个变化。
这种配置方法的主要缺点是在一个数据中心的Apache服务器和另外一个数据中心的MySQL服务器之间的延迟比较大。为了缓和这个问题，可以把Web服务器设置重定向模式。这样通信都会被重定向到放置活跃MySQL服务器的数据中心。还可以使用HTTP代理来实现这一目标。如图显示了如何使用代理来连接MySQL服务器，也可以将这个方法和许多别的中间件架构结合在一起，例如LVS和硬件负载均衡器

在应用中处理故障转移。
有时候让应用来处理故障转移会更加简单或者更加灵活。例如，如果应用遇到一个错误，这个错误外部观察者正常情况下是无法察觉的，例如关于数据库损坏的错误日志信息，那么应用可以自己来处理故障转移过程。
虽然把故障转移处理过程整合到应用中看起来比较吸引人，但可能没有想象中那么有效。大多数应用有许多组件，例如cron任务、配置文件，以及用不同语言编写的脚本。将故障转移整合到应用中可能导致应用变得太过笨拙，尤其是当应用增大并变得更加复杂时。但是将监控构建到应用中是一个好主意，当需要时，能够立刻开始故障转移过程。应用应该也能够管理用户体验，例如提供降级功能，并显示给用户合适的信息.

寻找最优并发度。
每个Web服务器都有一个最佳并发度——就是说，让进程处理请求尽可能快，并且不超过系统负载的最优的并发连接数。这就是前面说的最大系统容量。进行一个简单的测量和建模，或者只是反复试验，就可以找到这个"神奇的数"，为此花一些时间是值得的。
对于大流量的网站，Web服务器同一时刻处理上千个连接是很常见的。然而，只有一小部分连接需要进程实时处理。其他的可能是读请求，处理文件上传，填鸭式服务内容，或者只是等待客户端的下一步请求。随者并发的增加，服务器会逐渐到达它的最大吞吐量。在这之后，吞吐量通常开始降低，更重要的是，响应时间(延迟)也会i那位排队而开始增加。为什么会这样呢？试想，如果服务器只有一个CPU,同时接受到100个请求，，会发生什么事情呢？j假设CPU每秒能够处理一个请求。即便理想情况下操作系统没有调度的开销，也没有上下文切换的成本，那100个请求也需要CPU花费整整100s才能完成。
处理请求i的最好办法是什么？可以将其一个个地排到队列中，也可以并行地执行在不同请求之间切换，每次切换都给每个请求相同的服务时间。在这两种情况下，吞吐量都是每秒处理一个请求。然而，如果使用队列(并发=1)，平均延时是50s，如果是并发执行(并发=100)则是100s。在实践中，并发执行会使平均延时更高，主要是因为上下文切换的代价。
对于CPU密集型工作负载，最佳并发度等于CPU数量(或者CPU核数)。然而，进程并不总是处于可运行状态的，因为会有一些阻塞式请求，例如IO、数据库查询，以及网络请求。因此，最佳并发度通常会比CPU数量高一些。
可以预测最优并发度，但是这需要精确的分析。尝试不同的并发值，看看在不增加响应时间的情况下的最大吞吐量是多少，或者测量真正的工作负载进行分析，这通常更容易。Percona Toolkit的pt-tcp-model工具可以帮助从TCP转储中测量和建模分析系统的可扩展性和性能特性。

应用层以下的缓存。
MySQL服务器有自己的内部缓存，但也可以构建你自己的缓存和汇总表。可以对缓存表量身定制，使他们最有效地过滤、排序、与其它表关联、计数，或者用于其他用途。缓存表也比许多应用层缓存更持久，因为在服务器重启后它们还存在。

缓存并不总是有用。
必需确认缓存真的可以提升性能，因为有时候缓存可能没有任何帮助。例如，在实践中发现从Nginx的内存中获取内容比从缓存中代理中获取要快，如果代理的缓存在磁盘上则尤其如此.
原因很简单:缓存自身也有一些开销。比如检查缓存是否存在，如果命中则直接从缓存中返回数据。另外将缓存对象失效或者写入新的缓存对象都会有开销。缓存只在这些开销比没有缓存的情况下生成和提供数据的开销少时才有用。如果直到所有这些操作的开销，就可以计算出缓存能提供多少帮助。没有缓存时的开销就是每个请求生成数据的开销。有缓存的开销是检查缓存的开销加上缓存不命中的概率乘以生成数据的开销，再加上缓存命中的概率乘以缓存提供数据的开销。如果有缓存时的开销比没有时要低，则说明缓存可能有用，但依然不能保证。还要记住，就像从Nginx的内存中获取数据比从代理在磁盘中的缓存获取要好一样，有些缓存的开销比另外一些要低

应用层缓存。
应用层缓存通常在同一台机器的内存中存储数据，或者通过网络存在另一台机器的内存中。因为应用可以缓存部分计算结果，所以应用缓存可能比更低层次的缓存更有效。因此应用层缓存可以节省两方面的工作:获取数据以及基于这些数据进行计算。一个很好的例子是HTML文本块。应用程序可以生成例如头条新闻的标题这样的HTML片段，并且做好缓存。后续的页面试图就可以简单地插入这个缓存过的文本。一般来说，在缓存数据前对数据做的处理越多，缓存命中节省的工作越多。
但应用层缓存也有缺点，那就是缓存命中率可能更低，并且可能使用较多的内存。假设需要50个不同版本的头条新闻标题，以使不同地区生活的用户看到不同的内容，那就需要足够的内存去存储全部50个版本，任何给定版本的标题命中次数都会更少，并且失效策略也会更加复杂。
应用缓存有许多种，下面是其中的一小部分:

缓存控制策略。
缓存也有像反范式化数据库设计一样的问题:重复数据，也就是说有多个地方需要更新数据，所以需要想办法避免读到脏数据。下面是一些最常见的缓存控制策略:
1.TTL(time to live,存活时间)
缓存对象存储时设置一个过期时间;可以通过清理进程在达到过期时间后删掉最想，或者先留着直到下次访问时再清理(清理后需要使用新的版本替换)。对于数据很少变更或者没有新数据的情况，这是最好的失效策略
2.显式失效
如果不能接受脏数据，那么进程在更新原始数据时需要同时使缓存失效。这种策略有两个写——失效和写——更新。写——失效策略很简单:只需要标记缓存数据已经过期(是否清理缓存数据是可选的)。写——更新策略需要多做一些工作，因为在更新数据时就需要替换掉缓存项。无论如何，这都是非常有益的，特别是当生成缓存数据代价很昂贵时(写线程也许已经做了)。如果更新缓存数据，后续的请求将不在需要等待应用来生成。如果在后台做失效处理，例如基于TTL的失效，就可以在一个从用户请求完全分离出来的进程中生成失效数据的新版本
3.读时失效
在更改旧数据时，为了避免要同时失效派生出来的脏数据，可以在缓存中保存一些信息，当从缓存读数据时可以利用这些信息判断数据是否已经失效。和显式失效策略相比，这样做有很大的优势:成本固定且可以分散在不同时间内。假设要失效一个有一百万缓存对象依赖的对象，如果采用写时失效，需要一次在缓存中失效一百万个对象，即使有高效的方法来找到这些对象，也可能需要很长的时间才能完成。如果采用读时失效，写操作可以立即完成，但后续这一百万对象的读操作可能会有略微的延迟。这样就把失效一百万对象的开销分散了，并且可以帮助避免出现负载冲高和延迟增大的峰值。

一种最简单的读时失效的办法时采用对象版本控制。使用这种方法，在缓存中存储一个对象时，也可以存储对象所依赖的数据的当前版本号或者时间戳。例如，假设要缓存用户博客日志的统计信息，包括用户所发表的博客数。当缓存blog_stats对象时，也可以同一时间存储用户的当前版本号，因为该统计信息是依赖于用户的。
不管什么时候更新依赖于用户的数据，都需要更新用户的版本号，假设用户的版本号初始为0，并且由你来生成和缓存统计信息。当用户发表了一篇博客，就增加用户的版本好到1(当然也要同时存储这篇博客，尽管在这个例子并没有用到博客数据)。然后当需要显示统计数据的时候，可以对缓存中blog_stats对象的版本与缓存的用户版本进行比较。因为用户的版本比对象的版本高，所以可以直到缓存的统计信息已经过期了，需要重新计算。
这是一个非常粗糙的内容失效方式，因为它假设依赖于用户的每一个比特的数据与所有其他数据都有交互。但这个假设并不总是成立的。举个例子，如果一个用户对一篇博客做了编辑，你也需要增加用户的版本号，着就会导致存储的统计信息失效，而实际上统计信息(发表的博客数)并没真的改变。这个取舍是很简单的。一个简单的缓存失效策略不只是更容易创建，也可能更加高效。
对象版本控制是一种简单的标记缓存方法，它可以处理更复杂的依赖关系。一个标记的缓存可以识别不同类型的依赖，并且分别跟踪每个依赖的版本。在前面的图书俱乐部的例子中，你可以通过下面的版本好标记评论，使缓存的评论依赖于用户的版本和书的版本:user_ver=1234和book_ver=5678.任一版本号变了，都应该刷新缓存的评论

缓存对象分层。
分层缓存对象对检索、失效和内存利用都有帮助。相对于只缓存对象，也可以缓存对象的ID、对象的ID组等通常需要一起检索的数据。电子商务网站的搜索结果是这种技术很好的例子。一次搜索可能返回一个匹配产品的列表，包括名称、描述、缩略图，以及价格。缓存整个列表的效率很低:其他的搜索也可能会包含一些相同的产品，这就会导致数据重复，并且浪费内存。这种策略也使得当一个产品价格变动时，找出并失效搜索结果变得很困难，因为你必须查看每个列表，找到哪些列表包含了更新过的产品。
可以缓存关于搜索的最小信息，而不必缓存整个列表，例如返回结果的数量以及列表中的产品ID。然后可以再单独缓存每个产品。这样做可以解决 两个问题:不会重复存放任何结果数据，也更容易在失效产品的粒度上去失效缓存。缺点则是，相对于一次性获得整个搜索结果，必须在缓存中检索多个对象。然而不管怎么说，为搜索结果缓存产品ID的列表都是更有效的做法。先在一个缓存命中返回ID的列表，再使用这些ID去请求缓存获得产品信息。如果缓存允许在一次调用里返回多个结果，第二次请求就可以返回多个产品(memcached通过mget()调用来支持)
如果使用不当，这种方法可能会导致奇怪的结果。假设使用TTL策略来失效搜索结果，并且当产品变更时显式地区失效单个产品。现在想象以下，一个产品地描述发生了变化，不再包含搜索中匹配地关键字，但是搜索结果地缓存还没有过期失效，此时用户就会看到错误地搜索结果，因为缓存的搜索结果将会引用这个变化了的产品，即使它不再包含匹配搜索的关键字。
对于大多数应用程序来说，这不是问题。如果应用程序不能容忍这种情况，可以使用基于版本的缓存，并在执行搜索时在结果中存储产品的版本好。当发现搜索结果在缓存中时，可以将当前搜索结果的版本号和搜索结果中的每个产品的版本号做比较。如果发现任何一个产品的版本数据不一致，可以重新搜索并且重新缓存结果。这对理解远程缓存访问的花销是多么昂贵非常重要。虽然缓存很快，也可以避免很多工作，但在LAN环境下网络往返缓存服务器通常也需要0.3ms左右。我们见过很多案例，复杂的网页需要一千次左右的缓存访问来组合页面结果，这将会耗费3s左右的网络延时，意味着你的页面可能慢得不可接受，即使它甚至不需要访问数据库！因此，在这种情况下对缓存使用批量获取调用是非常重要的。对缓存分层，采用小一些的本地缓存，也可能获得很大的收益

预生成内容。
除了在应用程序几倍缓存位数据，也可以在后台预先请求一些页面，并且将结果存为静态页面。如果页面是动态的，也可以预先生成页面的部分内容，然后使用像服务端包含(SSI)这样的技术创建最终页面。这有助于减小生成预生成内容的大小和开销，否则可能在将不同部分拼装到最终页面的时候，由于微小的变化产生大量的重复内容。几乎可以对任何类型的缓存使用预生成策略,包括memcached.预生成内容有几个重要的好处。
1.应用代码没有复杂的命中和未命中处理路径
2.当未命中的处理路径慢得不可接受时，这种方案可以很好地工作，因为它保证了未命中的情况永远不会发生。实际上，在任何时候设计任何类型的缓存系统，总是应该考虑未命中的路径有多曼。如果平均性能提升很大，但是因为要预生成缓存内容，偶尔有一些请求变得非常缓慢，这时可能比不用缓存还糟糕。性能的持续稳定通常跟高性能一样重要
3.预生成可以避免在缓存未命中时异常的雪崩效应
缓存预生成号的内容可能占用大量空间，并且并不总能预生成所有东西。无论是哪种形式的缓存，需要预生成的内容中最重要的部分是哪些最经常被请求，或者生成的成本最高的，所以可以通过404错误处理机制来按需生成。预生成的内容有时候也可以从内存文件系统中获益，因为可以避免磁盘IO

作为基础组件的缓存。
缓存有可能成为基础设施的重要组成部分。也很容易陷入一个陷阱，认为缓存虽然很好用，但并不是重要到非有不可得东西。你也许会辩驳，如果缓存服务器宕机或者缓存被清空，请求也可以直接落在数据库上，系统依然可以正常运行。如果是刚刚将缓存加入应用系统，这也许是对的，但缓存的加入可以使得在应用压力显著增长时不需要对系统的某些部分同比增加资源投入——通常是数据部分。因此，系统可能慢慢地变得对缓存非常依赖，却没有被发觉。
例如，如果高速缓存命中率是90%，当由于某种原因失去缓存，数据库上的负载将增加到原来的10倍。这很可能导致压力超过数据库服务器的性能极限。为了避免像这样的意外，应该设计一些高可用性缓存(包括数据和服务)的解决方案，或者至少是评估好禁用缓存或丢失缓存时的性能影响。比如说可以设计应用在遇到这样的情况时能够进行降级处理。

使用HandlerSocket和memcached。
相对于数据存储在MySQL中而缓存在MySQL外部的缓存方案，另外有一种替代方法是为MySQL创建一个更快的访问路径，直接绕过使用缓存。对于小儿简单的查询语句，很大一部分开销来自解析SQL,检查权限，生成执行计划，等等。如果这种开销可以避免，MySQL在处理简单查询时将非常快。目前有两个解决方案可以用所谓的NoSQL方式访问MySQL。第一种时一个后台进程插件，成为HandlerSocket，由DeNA开发，这是日本最大的社交网站。HandlerSocket允许通过一个简单的协议访问InnoDB Handler对象。实际上，也就是绕过了上层的服务器层，通过网络直接连接到了InnoDB引擎层。有报告称HandlerSocket每秒可以执行超过750 000条查询。Percona Server分支中自带了HandlerSocket插件引擎层。第二个方案时通过memcached协议访问InnoDB。MySQL5.6的实验室版本有一个插件提供了这个接口。两种方法都有一些限制——特别是memcached的方法，这种方法对很多访问数据的方法都不支持。为什么会希望采用SQL以外的办法访问数据呢？除了速度之外，最大的可能是简单。这样做最大的好处是可以摆脱缓存，以及所有的失效逻辑，还有为它们服务的额外的基础设施

拓展MySQL。
如果MySQL不能做你需要的事，一种可能是拓展其功能。在这里不会展示如何去做到这一点，但会提供一些可能的方向。如果你对进一步探索有兴趣，那么有很多很好的在线资源。当我们说"MySQL不能做你需要的事"，我们指的是两件事情:MySQL根本做不到这一点或者MySQL可以做到，但是只能通过缓慢或笨拙的方法，总之做得不够好。无论哪个都是需要对MySQL拓展的原因。好消息事，MySQL已经越来越模块化和通用。存储引擎是拓展MySQL的一个很好的方式。Brian Aker已经写了一个存储引擎的框架，还有一系列介绍有关如何开始编写自己的存储引擎的文章。这是目前几个主要的第三方存储引擎的基础。许多公司都编写了它们自己的内部存储引擎。例如，一些社交网站公司使用了特殊的为社交图形操作设计的存储引擎，我们还知道有个公司定制了一个用于模糊搜索的引擎。写一个简单的自定义存储引擎并不难。还可以使用存储引擎作为另一个软件的接口。Sphinx引擎就是一个很好的例子，该引擎是Spinx全文检索软件的接口

MySQL的替代品。
MySQL并不是适合每一个场景的解决方案。有些工作通常在MySQL以外来做会更好，即使MySQL理论上也可以做到。最明显的一个例子是在传统的文件系统中存储文件，而不是在表中。图像文件是静丹案例:虽然可以把它们放到一个BLOB列，但这通常不是个好办法(使用MySQL的复制来快速分布镜像到其他机器更有优势，我们知道一些程序使用这种技术)。一般的做法是，在文件系统中存储图片或其他大型二进制文件，而在MySQL中只存储文件名；然后应用程序在MySQL之外存取文件。对于Web应用程序，可以把文件名放在<img>元素的src属性中，这样就可以实现对文件的存取。
全文检索是另一个最好放在MySQL之外处理额例子——MySQL在全文搜索方面明显不如Lucene和Sphinx。 NDB API也可能对某些任务有用。例如，尽管MySQL的NDB集群存储引擎(目前还)不适合存储一个高性能Web应用程序的全部数据，但用NDB API直接存储网站会话数据或用户注册信息还是可能的。在如下网站可以了解到更多NDB API的内容.还有供Apache使用的NDB模块，mod_ndb.
最后，对于某些操作——如图形关系和树遍历——关系型数据并不总是正确的典范,MySQL并不擅长分布式数据处理，因为它缺乏并行执行查询的能力。处于这些目的情况还是建议使用其他工具(可能与MySQL结合).现在想到的例子包括:
1.对于简单的键——值存储，在复制严重落后的非常高速的访问场景中，我们建议用Redis替换MySQL.即使MySQL主库可以承担这样的压力，备库的延迟也是非常让人头疼的。Redis也常用来做队列，因为它对队列操作支持得很好
2.Hadoop是房间中得大象，一语双关。混合MySQL/Hadoop得部署在处理大型或半结构化数据时非常常见

备份误区1:"复制就是备份"
这是我们经常碰到地一个误区。复制不是备份，当然使用RAID阵列也不是备份。为什么这么说？可以考虑以下，如果意外地在生产库上执行了DROP DATABASE，它们是否可以帮你恢复所有的数据？RAID和复制连这个简单的测试都没法通过。它们不是备份，也不是备份的替代品。只有备份才能满足备份的要求

在线备份还是离线备份。
如果可能，关闭MySQL做备份是最简单最安全的，也是所有获取一致性副本的方法中最好的。而且损坏或不一致的风险最小。如果关闭了MySQL，就根本不用关心InnoDB缓冲池中的脏页或其他缓存。也不需要担心数据在尝试备份的过程被修改，并且因为服务器不对应用提供访问，所以可以更快地完成备份。
尽管如此，让服务器停机的代价可能比看起来要更昂贵。即使能最小化停机时间，在高负载和高数据量下关闭和重启MySQL也可能要花很长一段时间，尽管有一些能使这个影响最小化的技术，但并不能将其减少为零。因此，必需要设计不需要生产服务器停机的备份。即便如此，由于一致性的需要，对服务器进行在线备份仍然会有明显的服务中断。
在众多的备份方法中，一个最大问题就是它们会使用FLUSH TABLES WITH READ LOCK操作，这会导致MySQL关闭并锁住所有的表，将MyISAM的数据文件刷新到磁盘上(但InnoDB不是这样的！)，并且刷新查询缓存。该操作需要非常常的时间来完成。具体需要多长时间是不可预估的；如果全局读锁要等待一个长时间运行的语句完成，或有许多表，那么时间会更长。除非锁被释放，否则就不能在服务器上更改任何数据，一切都会被阻塞和积压(是的，即使SELECT查询也会被阻塞，因为如果有一个查询需要修改某些数据，只要它开始等待表上的写锁，所有尝试获取读锁的查询也必需等待)。FLUSH TABLES WITH READ LOCK不像关闭服务器的代价那么高，因为大部分缓存仍然在内存中，并且服务器一直是"预热"的，但是它也有非常大的破坏性。如果有人说这样做很快，可能是准备向你推销某种从来没有在真正的线上服务器上运行过的东西。避免使用FLUSH TABLES WITH READ LOCK的最好的方法是只使用InnoDB表。在权限和其他系统信息表中使用MyISAM表是不可避免地，但是如果数据改变量很少(正常情况下)，你可以只刷新和锁住这些表，这不会有什么问题。
在规划备份时，有一些与性能相关地因素需要考虑.
1.锁时间
需要持有锁多长时间，例如在备份期间持有地全局FLUSH TABLES WITH READ LOCK?
2.备份时间
复制备份到目的地需要多久?
3.备份负载
在复制备份到目的地时对服务器性能的影响有多少?
4.恢复时间
把备份镜像从存储位置复制到MySQL服务器，重放二进制日志等，需要多久?
最大的权衡是备份时间与备份负载。可以牺牲其一以增强另外一个。例如可以提高备份的优先级，代价是降低服务器性能。同样，也可以利用负载的特性来设计备份。例如，如果服务器在完上的8小时内仅仅有50%的负载，那么可以尝试规划备份，使得服务器的负载低于50%且仍能在8小时内完成。可以采用许多方法来完成这个目标，例如，可以用ioice和nice来提高复制或压缩操作的优先级，使用不同的压缩等级，或在备份服务器上压缩而不是在MySQL服务器上。甚至可以使用lzo或pigz以获取更快的压缩。也可以使用0_DIRECT或fadvise()在复制操作时绕开操作系统的缓存，以避免污染服务器的缓存。像Percona XtraBackup和MySQL Enterprise Backup这样的工具都有下六选项，可以使用pv时加上--rate-limit选项来限制备份脚本的吞吐量

逻辑备份还是物理备份。
有两种主要的方法来备份MySQL数据:逻辑备份(也叫"导出")和直接复制原始文件的物理备份。逻辑备份将数据包含在一种MySQL能够解析的格式中，要么时SQL，要么时以某个符号分割的文本。(由mysqldump生成的逻辑备份并不一定是文本文件。SQL导出会包含许多不同的字符集，同样也会包含二进制数据，这些数据并不是有效的字符。对于许多编辑器来说，文件行也可能会太长。但是，大多数这样的文件还是可以被编辑器打开和读取，特别是mysqldump使用了--hex-blob选项时)。原始文件是指存在硬盘上的文件。任何一种备份都有其优点和缺点.

备份什么？
恢复的需求决定需要备份什么。最简单的策略是只备份数据和表定义，但这是一个最低的要求。在生产环境中恢复数据库一般需要更多的工作。下面是MySQL备份需要考虑的几点:
1.非显著数据
不要忘记哪些容易被忽略的数据:例如m二进制日志和InnoDB事务日志。
2.代码
现在的MySQL服务器可以存储许多代码，例如触发器和存储过程。如果备份了mysql数据库，那么大部分这类代码也备份了，但入股哦需要还原单个业务数据库会比较麻烦，因为这个数据库中的部分"数据"，例如存储过程，实际是存放在mysql数据库中的
3.复制配置
如果恢复一个涉及复制关系的服务器，应该备份所有与复制相关的文件，例如二进制日志、中继日志、日志索引文件和.info文件。至少应该包含SHOW MASTER STATUS和/或SHOW SLAVE STATUS的输出。执行FLUSH LOGS也非常有好处，可以让MySQL从一个新的二进制日志开始。从日志文件的开头做基于故障时间点的恢复要比从中间更容易
4.服务器配置
假设要从一个实际的灾难中恢复，比如说，地震过后在一个新数据中心构建服务器，如果备份中包含服务器配置，你一定会喜出望外
5.选定的操作系统文件
对于服务器配置来说，备份中对生产服务器至关重要的任何外部配置，都十分重要。在UNIX服务器上，这可能包括cron任务、用户和组的配置、管理脚本，以及sudo规则
这些建议在许多场景下会被当作"备份一切"。然而，如果有大量的数据，这样做的开销将非常高，如何做备份，需要更加明智的考虑。特别是，可能需要在不同备份中备份不同的数据。例如，可以单独地备份数据、二进制日志和操作系统及系统配置

存储引擎和一致性。
MySQL对存储引擎的选择会导致备份明显更复杂。问题是，对于给定的存储引擎，如何得到一致的备份。实际上有两类一致性需要考虑:数据一致性和文件一致性。
1.数据一致性
当备份时，应该考虑是否需要数据在指定时间点一致。例如，在一个电子商务数据库中，可能需要确保发货单和付款之间一致。恢复付款时如果不考虑相应的发货单，或反过来，都会导致麻烦。如果做在线备份(从一个运行的服务器做备份)，可能需要所有相关表的一致性备份。这意味着不能一次锁住一张表然后做备份——因而意味着备份可能比预想的要更有侵入性。如果使用的不是事务型存储引擎，则只能在备份时用LOCK TABLES来锁住所有要一起备份的表，备份完成后再释放锁。
InnoDB的多版本控制功能可以帮到我们。开始一个事务，转储一组相关的表，然后提交事务。(如果使用了事务获取一致性备份，则不能用LOCK TABLES，因为它会隐式地提交事务——详情参见MySQL手册)。只要在服务器上使用REPEATABLE READ事务隔离级别，并且没有任何DDL,就一定会有完美的一致性，以及基于时间点的数据快照，且在备份过程中不会阻塞任何后续的工作。尽管如此，这种方法并不能保护逻辑设计很差的应用。假如在电子商务库中插入一条付款记录，提交事务，然后在另外一个事务中插入一条发货单记录。备份过程可能在这两个操作之间开始，备份了付款记录却不包括发货单记录。这就是必需仔细设计事务以确保相关的操作放在一个组内的原因。也可以用mysqldump来获得InnoDB表的一致性逻辑备份，采用--single-transaction选项可以按照我们所描述的那样工作。但是，这可能会导致一个非常长的事务，在某些负载下会导致开销大到不可接受
2.文件一致性
每个文件内部的一致性也非常重要——例如，一条大的UPDATE语句执行时备份反映不出文件的状态——并且所有要备份的文件相互间也应一致。如果没有内部一致的文件，还原时可能会感到惊讶(它们可能已经损坏)。如果是在不同的时间复制相关的文件，它们彼此可能也不一致。MyISAM的.MYD和.MYI文件就是个例子。InnoDB如果检测到不一致或损坏，会记录错误日志乃至让服务器崩溃。对于非事务型存储引擎，例如MyISAM，可能的选项是锁住并刷新表。这意味着要么用LOCK TABLES和FLUSH TABLES结合的方法以使服务器将内存中的变更刷到磁盘上，要么用FLUSH TABLES WITH READ LOCK.一旦刷新完成，就可以安全地复制MyISAM的原始文件。对于InnoDB，确保文件在磁盘上一致更困难，即使使用FLUSH TABLES WITH READ LOCK，InnoDB依旧在后台运行:插入缓存、日志和写线程继续将变更合并到日志和表空间文件中。这些线程设计上是异步的——在后台执行这些工作可以帮助InnoDB取得更高的并发性——正因为如此它们与LOCK TABLES无关。因此，不仅需要确保每个文件内部是一致的，还需要同时复制同一个时间点的日志和表空间文件。如果在备份时有其他线程在修改文件，或在与表空间文件不同的时间点备份日志文件，会在恢复后再次因系统损坏而告终。可以通过下面几个方法规避这个问题。
1.等待直到InnoDB的清除线程和插入缓冲合并线程完成。可以观察SHOW INNODB STATUS的输出，当没有脏缓存或挂起的写时，就可以复制文件。尽管如此，这种方法可能需要很长一段时间;因为InnoDB的后台线程涉及太多的干扰而不太安全。所以我们不推荐这种方法
2.在一个类似LVM的系统中获取数据和日志文件一致的快照，必须让数据和日志文件一致的快照，必须让数据和日志文件在快照时相互一致;单独取它们的快照是没有意义的，
3.发送一个STOP信号给MySQL，做备份，然后再发送一个CONT信号来再次唤醒MySQL。看起来像是一个很少推荐的方法，但如果另外一种方法是在备份过程中需要关闭服务器，则这种方法值得考虑。至少这种技术不需要在重启服务器后预热。
在复制数据文件到其他地方后，就可以释放锁以使MySQL服务器再次正常运行

二进制日志格式。
二进制日志包含一系列的事件。每个事件有一个固定长度的头，其中有各种信息，例如当前时间戳和默认的数据库。可以使用mysqlbinlog工具来查看二进制日志的内容，打印一些头信息。下面是一个输出的例子。
```bash
mysqlbinlog mysql-bin.000002
```
第一行包含日志文件内的偏移字节值
第二行宝行以下几项:
1.事件的日期和事件，MySQL会使用它们来产生SET TIMESTAMP语句。
2.原服务器的服务器ID,对于防止复制之间无限循环和其他问题是非常有必要的。
3.end_log_pos，下一个事件的偏移字节值。该值对一个多语句事务中的大部分事件是不正确的。在此类事务过程中，MySQL的主库会复制事件到一个缓冲区，但这样做的时候它并不知道下个日志事件的位置
4.事件类型。本例中的类型是Query,但还有许多不同的类型
5.原服务器上执行事件的线程ID，对于审计和执行CONNECTION_ID()函数很重要。
6.exec_time，这是语句的时间戳和写入二进制日志的时间之差。不要依赖这个值，因为它可能在复制落后的备库上会有很大的偏差
7.在原服务器上事件产生的错误代码。如果事件在一个备库上重放时导致不同的错误，那么复制将因安全预警而失败。
后续的行包含重放变更时所需的数据。用户自定义的变更和任何其他特定设置，例如当语句执行时有效的时间戳，也将会出现在这里。如果使用的是MySQL5.1中基于行的日志，事件将不再是SQL.而是可读性较差的由语句对表所做变更的"镜像"

安全地清除老的二进制日志。
需要决定日志的过期策略以防止磁盘被二进制日志写满。日志增长多大取决于负载和日志格式(基于行的日志回导致更大的日志记录)。我们建议，如果可能，只要日志有用就尽可能保留。保留日志对于设置复制、分析服务器负载、审计和从上次全备按时间点进行恢复，都很有帮助。当决定想要保留日志多久时，应该考虑这些需求。
一个常见的设置是使用expire_log_days变量来告诉MySQL定期清理日志。这个变量直到MySQL4.1才引入;在此之前的版本，必须手动清理二进制日志。因此，你可能看到一些用类似下面的cron项来删除老的二进制日志的建议。
```sh
0 0 * * * /usr/bin/ find /var/log/mysql -mtime +N -name "mysql-bin.[0-9]*" | xargs rm
```
尽管这是在MySQL 4.1之前清除日志的唯一办法，但在新版本中不要这么做！用rm删除日志会导致mysql-bin.index状态文件与磁盘上的文件不一致，有些语句，例如SHOW MASTER LOGS可能会受到影响而悄然失败。手动修改mysql-bin.index文件也不会修复这个问题。应该用类似下面的cron命令
```sh
0 0 * * * /usr/bin/mysql -e "PURGE MASTER LOGS BEFORE CURRENT_DATE - INTERVAL N DAY"
```
expire_logs_days设置在服务器启动或MySQL切换二进制日志时生效，因此，如果二进制日志从没有增长和切换，服务器不会清除老条目。此设置时通过查看日志的修改事件而不是内容来决定哪个文件需要被清除。

生成逻辑备份。
对于逻辑备份，首先要意识到的是它们并不是以同样方式创建的。实际上有两种类型的逻辑备份:SQL导出和符号分割文件。
1.SQL导出
SQL导出是很多人所熟悉的，因为它们是mysqldump默认的方式。例如，用默认选项导出一个小表将产生如下输出:
可以是如下命令:
```bash
mysqldump -u root -p sakila actor > myactor.sql
```
导出文件包含表结构和数据，均以有效的SQL命令形式写出。文件以设置MySQL各种选项的注释开始。这些要么是为了使恢复工作更高效，要么使因为兼容性和正确性。接下来可以看到表结构，然后是数据，最后，脚本重置在导出开始时变更的选项。导出的输出对于还原操作来说是可执行的。这很方便。但mysqldump默认选项读与生成一个巨大的备份却不是太适合。mysqldump不是生成SQL逻辑备份的唯一工具。例如，也可以用mydumper或phpMyAdmin工具来创建。想指出的是，不是某一个特定的工具有多大的问题，而是做SQL逻辑备份本身就有一些缺点。下面是主要问题点:
1.Schema和数据存储在一起
如果想从单个文件恢复这样做会非常方便，但如果只想恢复一个表或指向恢复数据就很困难了。可以通过导出两次的方法来环节这个问题——一次只导出数据，另外一次只导出Schema——但还会有下一个麻烦
2.巨大的SQL语句
服务器分析和执行SQL语句的工作量非常大，所以加载数据时会非常慢
3.单个巨大的文件
大部分文本编辑器不能编辑巨大的或者包含非常长的行的文件。尽管有时候可以用命令行的流编辑器——例如sed或grep——来抽出需要的数据，但保持文件小型化仍然是更合适的
4.逻辑备份的成本很高
比起逻辑备份这种从存储引擎中读取数据然后通过客户端/服务器协议发送结果集的方式，还有其他更高效的方式
这些限制意味着SQL导出在表变大时可能变得不可用。不过，还有另外一个选择;导出数据到符号分割的文件中

符号分隔文件备份
可以使用SQL命令SELECT INTO OUTFILE以符号分隔文件格式创建数据的逻辑备份。(可以用mysqldump的 --tab选项导出到符号分隔文件中)。符号分隔文件包含以ASCII展示的原始数据，没有SQL、注释和列名。下面是一个导出为逗号分隔值(CVS)格式的例子。对于表个形式的数据来说这是一个很好的通用格式。
```sql
mysql> SHOW VARIABLES LIKE '%secure%';
mysql> SELECT * INTO OUTFILE '/var/lib/mysql-files//actor.txt' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM sakila.actor;
```
导出时你可能会遇到报错，按照图中所示导入到mysql认为安全的目录下就行。比起SQL导出文件，符号分隔文件要更紧凑且更易于用命令行工具操作，这种方法最大的优点时备份和还原速度更快。可以和导出时使用一样的选项，用LOAD DATA INFILE方法加载数据到表中。
```sql
mysql> LOAD DATA INFILE '/var/lib/mysql-files/actor.txt' INTO TABLE sakila.actor FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n';
ERROR 1062 (23000): Duplicate entry '1' for key 'PRIMARY'
```
图中也可以看到，由于主键发生了冲突所以没有导入成功，但最起码说明这个导入数据的动作是有的。
下面这个非正式的测试演示了SQL文件和符号分隔文件在备份和还原上的速度差异。在测试中，我们对生产数据做了修改。导出的表看起来像下面这样:
```sql
CREATE TABLE load_test(
col1 date NOT NULL,
col2 int NOT NULL,
col3 smallint unsigned NOT NULL,
col4 mediumint NOT NULL,
col5 mediumint NOT NULL,
col6 mediumint NOT NULL,
col7 decimal(3,1) default NULL,
col8 varchar(10) NOT NULL default '',
col9 int NOT NULL,
PRIMARY KEY (col1, col2)
) ENGINE =InnoDB;
```
这张表有1500万行，占用近700MB的磁盘空格键。对比了两种备份和还原方法的性能。可以看到测试中还原时间有较大的差异。但是SELECT INTO OUTFILE方法也有一些限制。
1.只能备份到运行MySQL服务器的机器上的文件中(可以写一个自定义SELECT INTO OUTFILE程序，在读取SELECT结果的同时写到磁盘文件中，我们已经看到有些人采用这种方法)
2.运行MySQL的系统用户必须有文件目录的写权限，因为是由MySQL服务器来执行文件的写入，而不是运行SQL命令的用户
3.出于安全原因，不能覆盖已经存在的文件，不管文件权限如何
4.不能直接导出到压缩文件中
5.某些情况下很难进行正确的导出或导入，例如非标准的字符集

文件系统快照。
文件系统快照是一种非常好的在线备份方法。支持快照的文件系统能够瞬间创建用来备份的内容一致的镜像。支持快照的文件系统和设备包括FreeBSD的文件系统、ZFS文件系统、GNU/Linux的逻辑卷管理(LVM)、以及许多的SAN系统和文件存储解决方案，例如NetApp存储。不要把快照和备份相混淆。创建快照是减少必须持有锁的时间的一个简单方法:释放锁后，必须复制文件到备份中。事实上，有些时候甚至可以创建InnoDB快照而不需要锁定。我们将要展示两种使用LVM来对InnoDB文件系统做备份的方法，可以选择最小化锁或零锁的方案。快照对于特别用途的备份是一个非常好的方法。一个例子是在升级过程中遇到有问题而回退的情况。可以在升级前创建一个镜像，这样如果升级有问题，只需要回滚到该镜像。可以对任何不确定和有风险的操作都这么做，例如对一个巨大的表做变更(需要多少时间是未知的)

恢复物理备份。
恢复物理备份往往非常直接——换言之，没有太多的选项。这可能是好事，也可能是坏事，具体取决于恢复的需求。一般过程是简单地复制文件到正确位置。是否需要关闭MySQL取决于存储引擎。MyISAM的文件一般相互独立，即使服务器正在运行，简单地复制每个表的.frm .MYI和.MYD文件也可以正常操作。一旦有任何对此表的查询，或者其他会导致服务器访问此表的操作(例如,执行SHOW TABLES)，MySQL都会立刻找到这些表。如果在复制这些文件时表是打开的，可能会有麻烦，因为此操作要么删除或重命名该表，要么使用LOCK TABLES和FLUSH TABLES来关闭它。InnoDB的情况有所不同。如果用传统的InnoDB的步骤来还原，即所有表都存储在单个表空间，就必须关闭MySQL，复制或移动文件到正确位置上，然后重启。同样也需要InnoDB的事务日志文件与表空间文件匹配。如果文件不匹配——例如，替换了表空间文件但没有替换事务日志文件——InnoDB将会拒绝启动。这也是将日志和数据文件一起备份非常关键的一个原因。入股哦使用InnoDB file-per-table特性(innodb_file_per_table),InnoDB会将每隔表的数据和索引存储于一个.ibd文件中，这就像MyISAM的.MYI和.MYD文件合在一起。可以在服务器运行时通过复制这些文件来备份和还原单个表，但这并不像MyISAM中那样简单。这些文件并不完全独立于InnoDB。每个.ibd文件都有一些内部的信息，保存着它与主(共享)表空间之前的关系。在还原这样的文件时，需要让InnoDB先"导入"这个文件。这个过程有许多的西安至，如果有需要可以阅读MySQL手册 中关于每个表使用独立表空间中的部分。最大的限制是只能在当初备份的服务器上还原单个表。用这种配置来备份和还原多个表不是不可能，但可能比想象得要更棘手。
所有这些复杂度意味着还原物理备份会非常乏味，并且容易出错。一个好的值得倡导的规则是，恢复过程越难越复杂，也就需要逻辑备份的保护。为了防止一些无法意料的情况或者某些无法使用物理备份的场景，准备好逻辑备份总是值得推荐的。

还原逻辑备份。
如果还原的是逻辑备份而不是物理备份，则与使用操作系统简单地复制文件到适当位置的方式不同，需要使用MySQL服务器本身来加载数据到表中。在加载导出文件之前，应该先花一点时间考虑文件有多大，需要多久加载完，以及在启动之前还需要做什么事情，例如通知用户或禁用掉部分应用。禁掉二进制日志也是个好主意，除非需要将还原操作复制到备库:服务器加载一个巨大的导出文件的代价很高，并且写二进制日志会增加更多的(可能没有必要的)开销。加载巨大的文件对于一些存储引擎也有影响。例如，在单个事务中加载100GB数据到InnoDB就不是个好想法，因为巨大的回滚段将会导致问题。应该以可控大小的块来加载，并且逐个提交事务。有两种类型的逻辑备份，所以相应地有两种类型的还原操作。

基于时间点的恢复。
对MySQL做基于时间点的恢复常见的方法是还原最近一次全备份，然后从那个时间点开始重放二进制日志(有时较"前滚恢复")。只要有二进制日志，就可以恢复到任何希望的时间点。甚至可以不太费力地恢复单个数据库。主要的缺点是二进制日志重放可能会是一个很慢的过程。它大体上等同于复制。如果有一个备库，并且已经测量到SQL线程的利用率有多高，那么对重放二进制日志会有多快就会心里有数了。例如，，如果SQL线程约有50%被利用，则恢复一周二进制日志的工作可能在三到四天内完成。一个典型场景是对有害的语句的结果做回滚操作，例如DROP TABLE。让我们看一个简化的例子，看只有MyISAM表的情况下该如何做。假如是在半夜，备份任务在运行与下面所列相当的语句，复制数据库到同一服务器上的其他地方。
```sql
mysql> FLUSH TABLES WITH READ LOCK;
         > server1# cp -a /var/lib/mysql/sakila /backup/sakila;
mysql> FLUSH LOGS;
         > server1# mysql -e "SHOW MASTER STATUS" --vertical > /backup/master.info
mysql> UNLOCK TABLES;
```
然后，假设有人在晚些时间运行下列语句.
```sql
mysql>USE sakila;
mysql>DROP TABLE sakila.payment;
```
为了便于说明，我们先假设可以单独地恢复这个数据库(即此库中地表不涉及跨库查询)。再假设是直到后来出问题才意识到这个有问题地语句。目标是恢复数据库中除了有问题地语句之外所有发生地事务。也就是说，其他表已经做的所有修改都必须保持，包括有问题的语句运行之后的修改。这并不是很难做到。首先，停掉MySQL以阻止更多的修改，然后从备份中仅恢复sakila数据库。
```bash
server1# /etc/init.d/mysql stop
server1# mv /var/lib/mysql/sakila /var lib/mysql/sakila.tmp
server1# cp -a /backup/sakila /var/lib/mysql
```
再到运行的服务器的my.cnf中添加如下配置以禁止正常的连接
```c
skip-networking
socket=/tmp/mysql_recover.sock
```
现在可以安全地启动服务器了。
```bash
server1# /etc/init.d/mysql start
```
下一个任务是从二进制日志中分出需要重放和忽略的语句。事发时，自半夜的备份依赖服务器只创建了一个二进制日志。我们可以用grep来检查二进制日志文件以找到问题语句
```bash
server1# mysqlbinlog --database=sakila /var/log/mysql/mysql-bin.000215 | grep -B3 -i 'drop table sakila.payment'
```
我们可以看到，想忽略的语句在日志文件中的某个位置，下一个语句的位置是多少。可以用下面的命令重放二进制日志直到某个位置，然后从某个位置继续
```bash
server1# mysqlbinlog --database=sakila /var/log/mysql/mysql-bin.000215 --stop-position=352 | mysql -uroot -p
server1# mysqlbinlog --database=sakila /var/log/mysql/mysql-bin.000215 --start-position=429 | mysql -uroot -p
```
接下来要做的是检测数据以确保没问题，然后关闭服务器并撤销对my.cnf的改变，最后重启服务器

更高级的恢复技术。
复制和基于时间点的恢复使用的是相同的技术:服务器的二进制日志。这意味着复制在恢复时会是个非常有帮助的工具，哪怕方式不是很明显。下面将演示一些可以用到的方法。这里列出来的不是一个完整的列表，但应该可以为你根据需求设计恢复方案带来一些想法。记得编写脚本，并且对恢复过程中需要用到的所有技术进行预演。shijian
1.用于快速恢复的延时复制
在前面已经提到，如果有一个延时的备库，并且在备库执行问题语句之前就发现了问题，那么基于时间点的恢复就更快更容易了。恢复的过程与前面说的有点不一样，但思路是相同的。停止备库，用START SLAVE UNTIL来重放事件直到要执行问题语句。接着，执行SET GLOBAL SQL _SLAVE_SKIP_COUNTER=1来跳过问题语句。如果想跳过多个事件，可以设置一个大于1的值(或简单地使用CHANGE MASTER TO 来前移备库在日志中的位置)。然后要做的就是执行START SLAVE,让备库执行完所有的中继日志。这样就利用贝克u完成了基于时间点的恢复中所有冗余的工作。现在可以将备库提升为主库，整个恢复过程基本上没有中断服务。即使没有延时的备库来加速恢复，普通的备库也有好处，至少会把主库的二进制日志复制到另外的及其上。如果主库的磁盘坏了。备库上的中继日志可能就是唯一能够获取到的最接近主库二进制的东西了
2.使用日志服务器进行恢复
还有另外一种使用复制来做恢复的方法:设置日志服务器。我们感觉复制比mysqlbinlog更可靠，mysqlbinlog可能会有一些导致异常行为的奇怪的Bug和不常见的情况。使用日志服务器进行恢复比mysqlbinlog更灵活更简单，不仅因为START SLAVE UNTIL选项，还因为那些可以采用的复制规则(replicate-do-table)。使用日志服务器，相对其他的方式来说，可以做到更复杂的过滤。例如，使用日志服务器可以轻松地恢复单个表。而用mysqlbinlog和命令行工具则要困难得多——事实上，这样做太复杂了，所以我们一般不建议进行尝试。假设粗心的开发人员像前面地例子一样删除了同样地表，现在想恢复此误操作，但又不想让整个服务器退到昨晚地备份。下面是利用日志服务器进行恢复地步骤:
2.1 将需要恢复的服务器叫作server1
2.2 在另外一台叫作server2的服务器上恢复做完的备份。在这台服务器上运行恢复进程，以免在恢复时犯错而导致事情更糟
2.3 按照前面的做法设置日志服务器来接收server1的二进制日志(复制日志到另外一个服务器并设置日志服务器是个好象发，但是要格外注意)
2.4 改变server2的配置文件，增加如下内容:
```c
replicate-do-table=sakila.payment
```
2.5 重启server2,然后用CHANGE MASTER TO来让它成为日志服务器的备库。配置它从昨晚备份的二进制日志坐标读取。这时候切记不要运行START SLAVE
2.6 检测server2上的SHOW SLAVE STATUS的输出，验证一切正常。要三思而行！
2.7 找到二进制日志中问题语句的位置，在server2上执行START SLAVE UNTIL来重放事件直到该位置。
2.8 在server2上用STOP SLAVE停掉复制进程。现在应该有被删除表，因为现在从库停止在被删除之前的时间点
2.9 将所需表从server2复制到server1.
只有没有任何多表的UPDATE、DELETE或INSERT语句操作这个表时，上述流程才是可行的。任何这样的多表操作语句在被记录的时候，可能时基于多个数据库的状态，而不仅仅时当前要恢复的这个数据库，所以这样恢复出来的数据可能和原始的有所不同。(只有在使用基于语句的二进制日志时才会有这个问题;如果使用的是基于行的日志，重放过程不会碰到这个问题)

InnoDB崩溃恢复。
InnoDB在每次启动时都会检测数据和日志文件，以确认是否需要执行恢复过程。而且InnoDB的恢复过程与前面的讨论不是一回事。它并不是恢复备份的数据;而是根据日志文件将事务应用到数据文件，将未提交的变更从数据文件中回滚。精确地描述InnoDB如何进行恢复工作，这有点太过复杂。我们要关注的焦点是当InnoDB有严重问题时如何实际执行恢复。大部分情况下InnoDB可以很好地解决问题。除非MySQL有Bug或硬件问题，否则不需要做任何非常规的事情，哪怕时服务器意外地断电。InnoDB会在启动时执行正常的恢复，然后一切就正常了，在日志文件中，可以看到如下信息。
```sql
InnoDB Doing recovery :scanned up to log sequence number 0 40817239
InnoDB: Starting an apply batch of log records to the database...
```
InnoDB会在日志文件中输出恢复进度的百分比信息。有些人说直到整个过程完成才能看到这些信息。耐心点，这个恢复过程是急不来的。如果心急而杀掉进程并重启，只会导致需要更长的恢复事件。如果服务器硬件有严重问题，例如内存或磁盘损坏，或遇到了MySQL或InnoDB的Bug，可能就不得不介入，这是要么进行强制恢复，要么阻止正常恢复发生。

MySQL Enterprise Backup
这个工具之前叫作InnoDB Hot Backup或ibbackup，是从Oracle购买的MySQL Enterprise中的一部分。使用此工具备份不需要停止MySQL，也不需要设置锁或中断正常的数据库活动(但是会对服务器造成一些额外的负载)。它支持类似压缩备份、增量备份和到其他服务器的流备份的特性。这是MySQL"官方"的备份工具。

Percona XtraBackup
Percona XtraBackup与MySQL Enterprise Backup在很多方面都非常类似，但它是开源并且免费的。除了核心备份工具外，还有一个用Perl写的封装脚本，可以提供更多高级功能。它支持类似流、增量、压缩和多线程(并行)备份操作。也有许多特别的功能，用以降低在高负载的系统上备份的影响。Percona XtraBackup的工作方式是在后台线程不断追踪InnoDB日志文件尾部，然后复制InnoDB数据文件。这是个轻量级侵入过程，依靠特别的检测机制确保复制的数据是一致的。当所有的数据文件被复制完，日志复制线程就结束了。结果是在不同的时间点的所有数据的副本。然后可以使用InnoDB崩溃恢复代码应用事务日志，已达到所有数据文件一致的状态。这一步叫作准备过程。一旦准备好，备份就会完全一致，并且包含文件复制过程最后时间点已经提交的事务。一切都在MySQL外部完成，因此不需要以任何方式连接或访问MySQL.包装脚本包含通过复制备份到原位置的方式进行恢复的能力。还有Lachalan Mulcahy的XtraBack Manager项目

mylvmbackup
Lenz Grimmer的mylvmbackup是一个Perl脚本，它通过LVM快照帮助MySQL自动备份。此工具首先获取全局读锁，创建快照，释放锁。然后通过tar压缩数据并移除快照。它通过备份时的时间戳命名压缩包。它还有几个高级选项，但总的来说，这是一个执行LVM备份的非常简单明了的工具

Zmanda Recovery Manager
适用于MySQL的Zmanda Recover Manger 或ZRM，有免费(GPL)和商业两种版本。企业版提供基于网页图形接口的控制台，用来配置、备份、验证、恢复、报告和调度。开源的版本包含了所有核心功能，但缺少一些额外的特性，例如基于网页的控制台。正如其名，ZRM实际上是一个备份和恢复管理器，而并非单一工具。它封装了自由的基于标准工具和技术，例如mysqldump、LVM快照和Percona XtraBackup等之上的功能。它将许多冗长的备份和恢复工作进行自动化。

mydumper
几名MySQL现在和之前的工程师利用他们多年的经验创建了mydumper，用来替代mysqldump。这是一个多线程(并发)的备份和还原MySQL和Drizzle的工具集，有许多很好的特性。大概有许多人会发现多线程备份和还原的速度是这个工具最吸引人的特色。尽管我们知道有些人在生产环境中使用，但我们还没有在任何产品中使用的经验

mysqldump
大部分在使用这个与MySQL一起发行的程序，因此，尽管它有缺点，但创建数据和Schema的逻辑备份最常见的选择还是mysqldump。这是一个通用工具，可以用于许多的任务，例如在服务器间复制表
```bash
mysqldump --host=server1 test t1 | mysql --host=server2 test
```
在前面展示几个用mysqldump创建逻辑备份的例子。该工具默认会输出包含创建表和填充数据的所有需要的命令；也有选项可以控制输出视图、存储代码和触发器。下面有一些典型的例子。
1.对服务器上所有的内容创建逻辑备份到单个文件中，每个库中所有的表在相同逻辑时间点备份:
```bash
mysqldump --all-databases > dump.sql
```
2.创建只包含Sakila示例数据库的逻辑备份:
```bash
mysqldump --databases sakila > dump.sql
```
3.创建只包含sakila.actor表的逻辑备份
```bash
mysqldump sakila actor > dump.sql 
```
可以使用 --result-file选项来指定输出文件，这可以帮助防止在Windows上发生换行符转换:
```bash
mysqldump sakila actor
```
mysqldump的默认选项对于大多数备份目的来说并不够好。多半要显示地指定某些选项以改变输出。下面是一些我们经常使用地选项，可以让mysqldump更加高效，输出更容易使用。
--opt
启用一组优化选项，包括关闭缓冲区(它会使服务器耗尽内存)，导出数据时把更多地数据写在更少的SQL语句里，以便在加载的时候更有效率，以及做其他一些有用的事情。更多细节可以阅读帮助文件。如果关闭了这组选项，mysqldump会把表写到磁盘之前，把他们都导出到内存里，这对于大型的表而言是不切实际的。
--allow-keywords, -quote-names
使用户在导出和恢复表时，可以使用保留字作为表的名字
--complete-insert
使用户能在不完全相同列的表之间移动数据
--tz-utc
使用户能在具有不同时区的服务器之间移动数据
--lock-all-tables
使用FLUSH TABLE WITH READ LOCK来获取全局一致的备份。
--tab
用SELECT INTO OUTFILE导出文件
--skip-extended-insert
使每一行数据都有自己的INSERT语句。必要时这可以用于有选择地还原某些行。它的代价是文件更大，导入到MySQL时开销会更大。因此，要确保只有在需要时才启用它。
如果在mysqldump上使用--databases或--all-databases选项，那么最终导出的数据在每隔数据库中都一直，因为mysqldump会在同一时间锁定并导出一个数据库里的所有表。然而，来自不同数据库的各个表就微比是相互一致的。使用--lock-all-tables选项可以解决这个问题。对于InnoDB备份，应该增加--single-transaction选项，这会使用InnoDB的MVCC特性在单个时间点创建一个一致的备份，而不需要使用LOCK  TABLES锁定所有的表。如果增加--master-data选项，备份还会包括在备份时服务器的二进制日志文件位置，这对基于时间点的恢复和设置复制非常有帮助，然而也要知道，获得日志位置时需要使用FLUSH TABLES WITH READ LOCK冻结服务器

5.获取数据库和表的列表。
每个备份脚本都会查询MySQL以获取数据库和表的列表。要注意那些是实际上并不是数据库的条目，例如一些日志系统中的lost+found文件夹和INFORMATION_SCHEMA。也要确保脚本已经准备好应付视图，同时也要知道SHOW TABLE STATUS在InnoDB中有大量数据时可能耗时很长。
```sql
mysql>SHOW DATABASES;
mysql>SHOW /* !50002 FULL */ TABLES FROM <database>;
mysql>SHOW TABLE STATUS FROM <database>;
```
6.对表加锁、刷新并解锁
如果需要对一个或多个表加锁并且/或刷新，要么按名字锁住所需的表，要么使用全局锁锁住所有的表。
```sql
mysql>LOCK TABLES <database.table> READ [, ...];
mysql>FLUSH TABLES;
mysql>FLUSH TABLES <database.table> [, ...];
mysql>FLUSH TABLES WITH READ LOCK;
mysql>UNLOCK TABLES;
```
在获取所有的表并锁住它们时要格外注意竞争条件。期间可能会有新表创建，或有表被删除或重命名。如果一个表一个表地锁住然后备份，将无法得到一致性的备份
7.刷新二进制日志
让服务器开始一个新的二进制日志非常简单(一般在锁住表后但在备份前做这个操作):
```sql
mysql>FLUSH LOGS;
```
这样做使得恢复和增量备份更简单，因为不需要考虑从一个日志文件中间开始操作。此操作会有一些副作用，比如刷新和重新打开错误日志，也可能销毁老的日志条目，因此，注意不要扔掉需要用到的数据。
8.获取二进制日志位置
脚本应该获取并记录主库和备库的状态——即使服务器仅是个主库或备库。
```sql
mysql>SHOW MASTER STATUS
mysql> SHOW SLAVE STATUS\G
```
执行这两条语句并忽略错误，以使脚本可以获取到所有可能的信息
9.导出数据
最好的选择是使用mysqldump、mysqldumper或SELECT INTO OUTFILE

这些都是构造备份脚本的基础。比较困难的部分是将管理和恢复任务脚本话。如果想获得实现的灵感，可以看看ZRM的源码

开源的监控工具。
下面是一些最受欢迎的开源集成监控系统。
1.Nagios
Nagios也许是开源世界中最流行的问题检测和告警系统。它周期性检测监控的服务器并将结果与默认或自定义的阈值相比较。如果结果超出了限制，Nagio会执行某个程序并且(或)把问题的告警发给某些人。Nagios的通信和告警系统可以将其发送到不同的位置，并且对计划内的宕机可以特殊处理。Nagios同样理解服务之间的依赖，因此，如果是因为中间的路由层或者主机本身宕机导致MySQL实例不可用，Nagios不会发送告警来烦你。Nagios能将任何一个可执行文件以插件形式运行，只要给予其正确参数就可得到z正确输出。因此，Nagios插件在多种语言中都存在，例如shell、Perl、Python、Ruby和其他脚本语言。就算找不到一个能真正满足你需求的插件，自己创建一个也很简单。一个插件只需要接收b标准的参数，以一个合适的状态退出，然后选择性地打印Nagios捕获的输出。然而，Nagios也有一些严重的缺点。即使你很了解它，也仍然难以维护。它将所有配置保存在文件而不是数据库中。文件有一个特别容易出错的语法，当系统增长和发展时，修改配置文件就很费事。Nagios可扩展性并不好;你可以很容易地写出监控插件，但这也是你能够做的一切。最后，它的图形化、趋势化和可视化能力都有限。Nagios将一些性能和其他数据存储到MySQL服务器中，一般从中生成图形，但并不像其他一些系统那么灵活。因为不同"政见"的原因，使得上面所有的问题继续变得更糟。因为或真实、或臆测的涉及代码、参与者的问题，Nagios至少分化除了两个分支。两个分支的名字分别是Opsview和Icinga。它们比Nagios更受到人们的青睐。
2.Zabbitx
Zabbix是一个同时支持监控和指标收集的完整系统。例如，它将所有配置和其他数据存储到数据库而不是配置文件中。它存储了比Nagios更多的数据类型，因而可以得到更好的趋势和历史报表。其网络画图和可视能力也比Nagios更强，配置更简单，更灵活，且更具可扩展性
3.Zenoss
Zenoss是用Python写的，拥有一个基于浏览器的用户界面，使用了Ajax，这使它更快和更高效。它可以自动发现网络上的资源，并将监控、告警、趋势、绘图和记录历史数据整合到一个统一的工具中。Zenoss默认使用SNMP来从远程服务器上收集数据，但也可以使用SSH，并且支持Nagios插件
4.Hyperic HQ
Hyperic HQ是一个基于Java的监控系统，比起同级别的其他大部分系统，它更称得上是企业级监控.像Zenoss一样，它可以自动发现网络上的资源和支持Nagios插件，但它的逻辑阻止和架构不同，有点"笨重"
5.OpenNMS
OpenNMS也是用Java开发，有一个活跃的开发社区。它拥有常规的特性，例如监控和告警，但同样也增加了绘图和趋势功能，它的目标是高性能、可扩展、自动化和灵活。像Hyperic一样，它也致力于为大型和关键系统做企业级监控
6.Groundwokr Open Source
Groundwork Open Source用一个可移植的接口把Nagios和其他几个工具整合到了一个系统中，对于这个工具最好的描述是:如果你是Nagios、Cacti和其他几个工具方面的专家，并且花了很多时间将它们整合在一起，那很可能你是在闭门造车.

相比于集所有功能于一身的系统，还有一系列软件专注于收集指标和画图以及可视化，而不是进行性能监控检查。它们中有很多是建立在RRDTool之上，存储时序数据到轮询数据库(RRD)文件中。RRD文件自动聚集输入数据，对没有预期传送的输入值进行插值，并有强大的绘图工具可以生成漂亮有特色的图。有很多基于RRDTool的系统，下面是最受欢迎的几个.
1.MRTG
Multi Router Traffic Grapher或称MRTG,是典型的基于RRDTool的系统。最初是为记录网络流量而设计的，但同样可以扩展到用于对其他指标进行记录和绘图
2.Cacti
Cacti可能是最流行的基于RRDTool的系统。它采用PHP网页来与RRDTool进行交互，并使用MySQL数据库来定义服务器、插件、图像等。因为是模块驱动，故而可以定义模板然后应用到系统上。Baron为MySQL和其他系统写了一组非常流行的模板.这些也已经被移植到Munin、OpenNMS和Zabbix
3.Ganglia
Ganglia与Cacti类似，但是为监控集群和网格系统而涉及，所以可以汇总查看许多服务器的数据，如果需要也可以细分查看单台服务器的详细数据
4.Munin
Munin手机树并存入RRDTool中，然后以几个不同级别的粒度生成数据图。它从配置中生成静态HTML文件，因此可以很容易地浏览和查看趋势。定义一个图形较容易;只需要创建一个插件脚本，其命令行帮助输出有一些Munin可以识别的特别语法的画图指令。

基于RRDTool的系统有些限制，例如不能用标准查询语言来查询存储的数据，不能永久保留数据，存在某些数据不能轻松地使用简单计数器和标准数值表示的问题，需要预先定义指标和图形等。理想情况下，我们需要的监控系统可以接受任何发送给它的指标，而不需要预先进行定义，并且后续可以绘制任意需要的图形，也不需要预先进行定义。可能我们锁看到的最接近的系统是Graphite.
这些系统都可以用来对MySQL收集、记录和绘制数据图表并且生成报表，有着不同程度的灵活性，目标也稍微有些不同，但它们都缺乏真正可以在问题出现时及时告警的灵活性。
我们提到的大多数系统的主要问题是，它们明显是由那些因为现有系统不能满足它们所有需求的人涉及的，因此它们又重复设计了另一个无法完全满足其他人的所有需求的系统。大部分这样的系统都有一些基础的限制，例如使用一个奇怪的数据模型存储内部数据，而导致在很多场合都无法很好地工作。在很多时候，这都令人沮丧，使用这些系统都像是把一个圆形的钉子钉到了一个方形的洞里面。