写在前面：索引对查询的速度有着至关重要的影响，理解索引也是进行数据库性能调优的起点。

考虑例如以下情况。假设数据库中一个表有10^6条记录，DBMS的页面大小为4K。并存储100条记录。假设没有索引，查询将对整个表进行扫描，最坏的情况下，假设全部数据页都不在内存，须要读取10^4个页面，假设这10^4个页面在磁盘上随机分布。须要进行10^4次I/O，假设磁盘每次I/O时间为10ms(忽略传输数据时间)，则总共须要100s(但实际上要好非常多非常多)。

假设对之建立B-Tree索引，则仅仅须要进行log100(10^6)=3次页面读取。最坏情况下耗时30ms。这就是索引带来的效果。非常多时候，当你的应用程序进行SQL查询速度非常慢时，应该想想能否够建索引。进入正题：

第二章、索引与优化

1、选择索引的数据类型

MySQL支持非常多数据类型，选择合适的数据类型存储数据对性能有非常大的影响。通常来说，能够遵循下面一些指导原则：

(1)越小的数据类型通常更好：越小的数据类型通常在磁盘、内存和CPU缓存中都须要更少的空间，处理起来更快。
(2)简单的数据类型更好：整型数据比起字符，处理开销更小。由于字符串的比較更复杂。

在MySQL中，应该用内置的日期和时间数据类型。而不是用字符串来存储时间；以及用整型数据类型存储IP地址。
(3)尽量避免NULL：应该指定列为NOT NULL，除非你想存储NULL。在MySQL中。含有空值的列非常难进行查询优化。由于它们使得索引、索引的统计信息以及比較运算更加复杂。你应该用0、一个特殊的值或者一个空串取代空值。

1.1、选择标识符
选择合适的标识符是很重要的。选择时不仅应该考虑存储类型，并且应该考虑MySQL是如何进行运算和比較的。

一旦选定数据类型，应该保证全部相关的表都使用同样的数据类型。
(1)    整型：一般是作为标识符的最好选择。由于能够更快的处理。并且能够设置为AUTO_INCREMENT。

(2)    字符串：尽量避免使用字符串作为标识符。它们消耗更好的空间。处理起来也较慢。

并且，通常来说，字符串都是随机的，所以它们在索引中的位置也是随机的，这会导致页面分裂、随机訪问磁盘，聚簇索引分裂（对于使用聚簇索引的存储引擎）。

2、索引入门
对于不论什么DBMS，索引都是进行优化的最基本的因素。

对于少量的数据，没有合适的索引影响不是非常大，可是，当随着数据量的添加，性能会急剧下降。
假设对多列进行索引(组合索引)，列的顺序很重要，MySQL仅能对索引最左边的前缀进行有效的查找。

比如：
如果存在组合索引it1c1c2(c1,c2)。查询语句select * from t1 where c1=1 and c2=2可以使用该索引。查询语句select * from t1 where c1=1也可以使用该索引。可是。查询语句select * from t1 where c2=2不可以使用该索引。由于没有组合索引的引导列，即，要想使用c2列进行查找，必需出现c1等于某值。

2.1、索引的类型
索引是在存储引擎中实现的。而不是在server层中实现的。

所以，每种存储引擎的索引都不一定全然同样，并非全部的存储引擎都支持全部的索引类型。
2.1.1、B-Tree索引
如果有例如以下一个表：

 其索引包括表中每一行的last_name、first_name和dob列。其结构大致例如以下：

 索引存储的值按索引列中的顺序排列。能够利用B-Tree索引进行全keyword、keyword范围和keyword前缀查询，当然，假设想使用索引。你必须保证按索引的最左边前缀(leftmost prefix of the index)来进行查询。
(1)匹配全值(Match the full value)：对索引中的全部列都指定详细的值。

比如，上图中索引能够帮助你查找出生于1960-01-01的Cuba Allen。
(2)匹配最左前缀(Match a leftmost prefix)：你能够利用索引查找last name为Allen的人。只使用索引中的第1列。

(3)匹配列前缀(Match a column prefix)：比如，你能够利用索引查找last name以J開始的人，这只使用索引中的第1列。

(4)匹配值的范围查询(Match a range of values)：能够利用索引查找last name在Allen和Barrymore之间的人。只使用索引中第1列。
(5)匹配部分精确而其他部分进行范围匹配(Match one part exactly and match a range on another part)：能够利用索引查找last name为Allen，而first name以字母K開始的人。
(6)仅对索引进行查询(Index-only queries)：假设查询的列都位于索引中。则不须要读取元组的值。

因为B-树中的节点都是顺序存储的，所以能够利用索引进行查找(找某些值)，也能够对查询结果进行ORDER BY。当然，使用B-tree索引有下面一些限制：
(1) 查询必须从索引的最左边的列開始。

关于这点已经提了非常多遍了。比如你不能利用索引查找在某一天出生的人。
(2) 不能跳过某一索引列。比如，你不能利用索引查找last name为Smith且出生于某一天的人。
(3) 存储引擎不能使用索引中范围条件右边的列。比如，假设你的查询语句为WHERE last_name="Smith" AND first_name LIKE ‘J%‘ AND dob=‘1976-12-23‘。则该查询仅仅会使用索引中的前两列。由于LIKE是范围查询。

2.1.2、Hash索引
MySQL中，仅仅有Memory存储引擎显示支持hash索引，是Memory表的默认索引类型。虽然Memory表也能够使用B-Tree索引。Memory存储引擎支持非唯一hash索引，这在数据库领域是罕见的。假设多个值有同样的hash code。索引把它们的行指针用链表保存到同一个hash表项中。
如果创建例如以下一个表：
CREATE TABLE testhash (
   fname VARCHAR(50) NOT NULL,
   lname VARCHAR(50) NOT NULL,
   KEY USING HASH(fname)
) ENGINE=MEMORY;
包括的数据例如以下：

如果索引使用hash函数f( )。例如以下：

此时，索引的结构大概例如以下：

 Slots是有序的，可是记录不是有序的。当你运行
mysql> SELECT lname FROM testhash WHERE fname=‘Peter‘;
MySQL会计算’Peter’的hash值。然后通过它来查询索引的行指针。由于f(‘Peter‘) = 8784，MySQL会在索引中查找8784。得到指向记录3的指针。

由于索引自己只存储非常短的值，所以。索引非常紧凑。Hash值不取决于列的数据类型，一个TINYINT列的索引与一个长字符串列的索引一样大。
 
Hash索引有下面一些限制：
(1)因为索引仅包括hash code和记录指针，所以，MySQL不能通过使用索引避免读取记录。

可是訪问内存中的记录是很迅速的。不会对性造成太大的影响。

(2)不能使用hash索引排序。
(3)Hash索引不支持键的部分匹配，由于是通过整个索引值来计算hash值的。
(4)Hash索引仅仅支持等值比較，比如使用=，IN( )和<=>。

对于WHERE price>100并不能加速查询。

2.1.3、空间(R-Tree)索引
MyISAM支持空间索引，主要用于地理空间数据类型，比如GEOMETRY。
2.1.4、全文(Full-text)索引
全文索引是MyISAM的一个特殊索引类型，主要用于全文检索。

3、高性能的索引策略
3.1、聚簇索引(Clustered Indexes)
聚簇索引保证keyword的值相近的元组存储的物理位置也同样（所以字符串类型不宜建立聚簇索引，特别是随机字符串，会使得系统进行大量的移动操作），且一个表仅仅能有一个聚簇索引。由于由存储引擎实现索引，所以，并非全部的引擎都支持聚簇索引。

眼下，仅仅有solidDB和InnoDB支持。

聚簇索引的结构大致例如以下：

 

 注：叶子页面包括完整的元组，而内节点页面仅包括索引的列(索引的列为整型)。一些DBMS同意用户指定聚簇索引，可是MySQL的存储引擎到眼下为止都不支持。InnoDB对主键建立聚簇索引。

假设你不指定主键。InnoDB会用一个具有唯一且非空值的索引来取代。假设不存在这种索引。InnoDB会定义一个隐藏的主键，然后对其建立聚簇索引。一般来说。DBMS都会以聚簇索引的形式来存储实际的数据，它是其他二级索引的基础。

3.1.1、InnoDB和MyISAM的数据布局的比較
为了更加理解聚簇索引和非聚簇索引，或者primary索引和second索引(MyISAM不支持聚簇索引)，来比較一下InnoDB和MyISAM的数据布局。对于例如以下表：

 如果主键的值位于1---10,000之间。且按随机顺序插入。然后用OPTIMIZE TABLE进行优化。col2随机赋予1---100之间的值，所以会存在很多反复的值。
(1)    MyISAM的数据布局
其布局十分简单，MyISAM依照插入的顺序在磁盘上存储数据。例如以下：

 注：左边为行号(row number)，从0開始。由于元组的大小固定。所以MyISAM能够非常easy的从表的開始位置找到某一字节的位置。
据些建立的primary key的索引结构大致例如以下：

 注：MyISAM不支持聚簇索引，索引中每个叶子节点只包括行号(row number)，且叶子节点依照col1的顺序存储。
来看看col2的索引结构：

 实际上。在MyISAM中，primary key和其他索引没有什么差别。Primary key只不过一个叫做PRIMARY的唯一，非空的索引而已。

(2)    InnoDB的数据布局
InnoDB按聚簇索引的形式存储数据，所以它的数据布局有着非常大的不同。它存储表的结构大致例如以下：

 注：聚簇索引中的每一个叶子节点包括primary key的值，事务ID和回滚指针(rollback pointer)——用于事务和MVCC，和余下的列(如col2)。

相对于MyISAM，二级索引与聚簇索引有非常大的不同。InnoDB的二级索引的叶子包括primary key的值，而不是行指针(row pointers)。这减小了移动数据或者数据页面分裂时维护二级索引的开销。由于InnoDB不须要更新索引的行指针。

其结构大致例如以下：

 聚簇索引和非聚簇索引表的对照：

 3.1.2、按primary key的顺序插入行(InnoDB)

假设你用InnoDB，并且不须要特殊的聚簇索引，一个好的做法就是使用代理主键(surrogate key)——独立于你的应用中的数据。最简单的做法就是使用一个AUTO_INCREMENT的列，这会保证记录依照顺序插入。并且能提高使用primary key进行连接的查询的性能。

应该尽量避免随机的聚簇主键。比如，字符串主键就是一个不好的选择，它使得插入操作变得随机。

 3.2、覆盖索引(Covering Indexes)
假设索引包括满足查询的全部数据。就称为覆盖索引。覆盖索引是一种很强大的工具。能大大提高查询性能。仅仅须要读取索引而不用读取数据有下面一些长处：
(1)索引项通常比记录要小，所以MySQL訪问更少的数据；
(2)索引都按值的大小顺序存储，相对于随机訪问记录，须要更少的I/O；
(3)大多数据引擎能更好的缓存索引。比方MyISAM仅仅缓存索引。
(4)覆盖索引对于InnoDB表尤事实上用，由于InnoDB使用聚集索引组织数据，假设二级索引中包括查询所需的数据，就不再须要在聚集索引中查找了。
覆盖索引不能是不论什么索引。仅仅有B-TREE索引存储对应的值。并且不同的存储引擎实现覆盖索引的方式都不同。并非全部存储引擎都支持覆盖索引(Memory和Falcon就不支持)。
对于索引覆盖查询(index-covered query)，使用EXPLAIN时，能够在Extra一列中看到“Using index”。比如。在sakila的inventory表中。有一个组合索引(store_id,film_id)，对于仅仅须要訪问这两列的查询。MySQL就能够使用索引，例如以下：

在大多数引擎中，仅仅有当查询语句所訪问的列是索引的一部分时，索引才会覆盖。

可是，InnoDB不限于此，InnoDB的二级索引在叶子节点中存储了primary key的值。因此，sakila.actor表使用InnoDB，并且对于是last_name上有索引。所以，索引能覆盖那些訪问actor_id的查询，如：

3.3、利用索引进行排序
MySQL中，有两种方式生成有序结果集：一是使用filesort。二是按索引顺序扫描。

利用索引进行排序操作是很快的，并且能够利用同一索引同一时候进行查找和排序操作。当索引的顺序与ORDER BY中的列顺序同样且所有的列是同一方向(所有升序或者所有降序)时，能够使用索引来排序。假设查询是连接多个表，仅当ORDER BY中的所有列都是第一个表的列时才会使用索引。其他情况都会使用filesort。

 当MySQL不能使用索引进行排序时，就会利用自己的排序算法(高速排序算法)在内存(sort buffer)中对数据进行排序，假设内存装载不下。它会将磁盘上的数据进行分块。再对各个数据块进行排序，然后将各个块合并成有序的结果集（实际上就是外排序）。

对于filesort，MySQL有两种排序算法。
(1)两遍扫描算法(Two passes)
实现方式是先将需要排序的字段和能够直接定位到相关行数据的指针信息取出，然后在设定的内存（通过參数sort_buffer_size设定）中进行排序，完毕排序之后再次通过行指针信息取出所需的Columns。
注：该算法是4.1之前採用的算法，它须要两次訪问数据，尤其是第二次读取操作会导致大量的随机I/O操作。

还有一方面，内存开销较小。
(3)    一次扫描算法(single pass)
该算法一次性将所需的Columns所有取出。在内存中排序后直接将结果输出。
注：从 MySQL 4.1 版本号開始使用该算法。

它降低了I/O的次数，效率较高。可是内存开销也较大。

假设我们将并不须要的Columns也取出来。就会极大地浪费排序过程所须要的内存。在 MySQL 4.1 之后的版本号中，能够通过设置 max_length_for_sort_data 參数来控制 MySQL 选择第一种排序算法还是另外一种。

当取出的全部大字段总大小大于 max_length_for_sort_data 的设置时。MySQL 就会选择使用第一种排序算法，反之，则会选择另外一种。为了尽可能地提高排序性能，我们自然更希望使用另外一种排序算法，所以在 Query 中只取出须要的 Columns 是很有必要的。

当对连接操作进行排序时。假设ORDER BY只引用第一个表的列，MySQL对该表进行filesort操作。然后进行连接处理，此时，EXPLAIN输出“Using filesort”。否则，MySQL必须将查询的结果集生成一个暂时表，在连接完毕之后进行filesort操作。此时，EXPLAIN输出“Using temporary;Using filesort”。

3.4、索引与加锁
索引对于InnoDB很重要。由于它能够让查询锁更少的元组。这点十分重要，由于MySQL 5.0中，InnoDB直到事务提交时才会解锁。有两个方面的原因：首先，即使InnoDB行级锁的开销很高效，内存开销也较小，但无论怎么样，还是存在开销。

其次，对不须要的元组的加锁。会添加锁的开销，减少并发性。

InnoDB仅对须要訪问的元组加锁，而索引可以降低InnoDB訪问的元组数。

可是，仅仅有在存储引擎层过滤掉那些不须要的数据才干达到这样的目的。

一旦索引不同意InnoDB那样做（即达不到过滤的目的），MySQLserver仅仅能对InnoDB返回的数据进行WHERE操作，此时，已经无法避免对那些元组加锁了：InnoDB已经锁住那些元组，server无法解锁了。
来看个样例：

 该查询只返回2---3的数据，实际已经对1---3的数据加上排它锁了。

InnoDB锁住元组1是由于MySQL的查询计划仅使用索引进行范围查询（而没有进行过滤操作，WHERE中第二个条件已经无法使用索引了）：

 表明存储引擎从索引的起始处開始。获取全部的行。直到actor_id<4为假，server无法告诉InnoDB去掉元组1。
为了证明row 1已经被锁住，我们另外建一个连接，运行例如以下操作：

 该查询会被挂起，直到第一个连接的事务提交释放锁时。才会运行（这样的行为对于基于语句的复制(statement-based replication)是必要的）。

如上所看到的，当使用索引时，InnoDB会锁住它不须要的元组。

更糟糕的是，假设查询不能使用索引，MySQL会进行全表扫描，并锁住每个元组，无论是否真正须要。

本文借鉴http://www.cnblogs.com/hustcat/archive/2009/10/28/1591648.html