【索引】理解MySQL——索引与优化

MySQL 索引

MySQL索引的创建对于MySQL的高效运行是很重要的，索引能够大大提升MySQL的检索速度。

打个比方，若是合理的设计且使用索引的MySQL是一辆兰博基尼的话，那么没有设计和使用索引的MySQL就是一我的力三轮车。

索引分单列索引和组合索引。单列索引，即一个索引只包含单个列，一个表能够有多个单列索引，但这不是组合索引。组合索引，即一个索引包含多个列。

建立索引时，你须要确保该索引是应用在 SQL 查询语句的条件(通常做为 WHERE 子句的条件)。

实际上，索引也是一张表，该表保存了主键与索引字段，并指向实体表的记录。

上面都在说使用索引的好处，但过多的使用索引将会形成滥用。所以索引也会有它的缺点：虽然索引大大提升了查询速度，同时却会下降更新表的速度，如对表进行INSERT、UPDATE和DELETE。由于更新表时，MySQL不只要保存数据，还要保存一下索引文件。 创建索引会占用磁盘空间的索引文件。
普通索引
建立索引

这是最基本的索引，它没有任何限制。它有如下几种建立方式：

CREATE INDEX indexName ON mytable(username(length)); 

若是是CHAR，VARCHAR类型，length能够小于字段实际长度；若是是BLOB和TEXT类型，必须指定 length。
修改表结构(添加索引)

ALTER table tableName ADD INDEX indexName(columnName)

建立表的时候直接指定

CREATE TABLE mytable(  
 
ID INT NOT NULL,   
 
username VARCHAR(16) NOT NULL,  
 
INDEX [indexName] (username(length))  
 
);  

删除索引的语法

DROP INDEX [indexName] ON mytable; 

惟一索引

它与前面的普通索引相似，不一样的就是：索引列的值必须惟一，但容许有空值。若是是组合索引，则列值的组合必须惟一。它有如下几种建立方式：
建立索引

CREATE UNIQUE INDEX indexName ON mytable(username(length)) 

修改表结构

ALTER table mytable ADD UNIQUE [indexName] (username(length))

建立表的时候直接指定

CREATE TABLE mytable(  
 
ID INT NOT NULL,   
 
username VARCHAR(16) NOT NULL,  
 
UNIQUE [indexName] (username(length))  
 
);  

使用ALTER 命令添加和删除索引

有四种方式来添加数据表的索引：

    ALTER TABLE tbl_name ADD PRIMARY KEY (column_list): 该语句添加一个主键，这意味着索引值必须是惟一的，且不能为NULL。

    ALTER TABLE tbl_name ADD UNIQUE index_name (column_list): 这条语句建立索引的值必须是惟一的（除了NULL外，NULL可能会出现屡次）。
    ALTER TABLE tbl_name ADD INDEX index_name (column_list): 添加普通索引，索引值可出现屡次。
    ALTER TABLE tbl_name ADD FULLTEXT index_name (column_list):该语句指定了索引为 FULLTEXT ，用于全文索引。

如下实例为在表中添加索引。

mysql> ALTER TABLE testalter_tbl ADD INDEX (c);

你还能够在 ALTER 命令中使用 DROP 子句来删除索引。尝试如下实例删除索引:

mysql> ALTER TABLE testalter_tbl DROP INDEX c;

使用 ALTER 命令添加和删除主键

主键只能做用于一个列上，添加主键索引时，你须要确保该主键默认不为空（NOT NULL）。实例以下：

mysql> ALTER TABLE testalter_tbl MODIFY i INT NOT NULL;
mysql> ALTER TABLE testalter_tbl ADD PRIMARY KEY (i);

你也可使用 ALTER 命令删除主键：

mysql> ALTER TABLE testalter_tbl DROP PRIMARY KEY;

删除主键时只需指定PRIMARY KEY，但在删除索引时，你必须知道索引名。
显示索引信息

你可使用 SHOW INDEX 命令来列出表中的相关的索引信息。能够经过添加 \G 来格式化输出信息。

 

 

写在前面：索引对查询的速度有着相当重要的影响，理解索引也是进行数据库性能调优的起点。考虑以下状况，假设数据库中一个表有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查询速度很慢时，应该想一想是否能够建索引。进入正题：

第二章、索引与优化

一、选择索引的数据类型

MySQL支持不少数据类型，选择合适的数据类型存储数据对性能有很大的影响。一般来讲，能够遵循如下一些指导原则：

(1)越小的数据类型一般更好：越小的数据类型一般在磁盘、内存和CPU缓存中都须要更少的空间，处理起来更快。
(2)简单的数据类型更好：整型数据比起字符，处理开销更小，由于字符串的比较更复杂。在MySQL中，应该用内置的日期和时间数据类型，而不是用字符串来存储时间；以及用整型数据类型存储IP地址。
(3)尽可能避免NULL：应该指定列为NOT NULL，除非你想存储NULL。在MySQL中，含有空值的列很难进行查询优化，由于它们使得索引、索引的统计信息以及比较运算更加复杂。你应该用0、一个特殊的值或者一个空串代替空值。

1.一、选择标识符
选择合适的标识符是很是重要的。选择时不只应该考虑存储类型，并且应该考虑MySQL是怎样进行运算和比较的。一旦选定数据类型，应该保证全部相关的表都使用相同的数据类型。
(1)    整型：一般是做为标识符的最好选择，由于能够更快的处理，并且能够设置为AUTO_INCREMENT。

(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.一、索引的类型
索引是在存储引擎中实现的，而不是在服务器层中实现的。因此，每种存储引擎的索引都不必定彻底相同，并非全部的存储引擎都支持全部的索引类型。
2.1.一、B-Tree索引
假设有以下一个表：

CREATE TABLE People (    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列。其结构大体以下：

 

 索引存储的值按索引列中的顺序排列。能够利用B-Tree索引进行全关键字、关键字范围和关键字前缀查询，固然，若是想使用索引，你必须保证按索引的最左边前缀(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.二、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( )，以下：

f('Arjen') = 2323 f('Baron') = 7437 f('Peter') = 8784 f('Vadim') = 2458

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

 

 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.三、空间(R-Tree)索引
MyISAM支持空间索引，主要用于地理空间数据类型，例如GEOMETRY。
2.1.四、全文(Full-text)索引
全文索引是MyISAM的一个特殊索引类型，主要用于全文检索。

三、高性能的索引策略
3.一、聚簇索引(Clustered Indexes)
聚 簇索引保证关键字的值相近的元组存储的物理位置也相同（因此字符串类型不宜创建聚簇索引，特别是随机字符串，会使得系统进行大量的移动操做），且一个表只 能有一个聚簇索引。由于由存储引擎实现索引，因此，并非全部的引擎都支持聚簇索引。目前，只有solidDB和InnoDB支持。
聚簇索引的结构大体以下：

 

 注： 叶子页面包含完整的元组，而内节点页面仅包含索引的列(索引的列为整型)。一些DBMS容许用户指定聚簇索引，可是MySQL的存储引擎到目前为止都不支 持。InnoDB对主键创建聚簇索引。若是你不指定主键，InnoDB会用一个具备惟一且非空值的索引来代替。若是不存在这样的索引，InnoDB会定义 一个隐藏的主键，而后对其创建聚簇索引。通常来讲，DBMS都会以聚簇索引的形式来存储实际的数据，它是其它二级索引的基础。

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

 

CREATE TABLE layout_test (    col1 int NOT NULL,    col2 int NOT NULL,    PRIMARY KEY(col1),    KEY(col2) );

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

 注：左边为行号(row number)，从0开始。由于元组的大小固定，因此MyISAM能够很容易的从表的开始位置找到某一字节的位置。
据些创建的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.二、按primary key的顺序插入行(InnoDB)

如 果你用InnoDB，并且不须要特殊的聚簇索引，一个好的作法就是使用代理主键(surrogate key)——独立于你的应用中的数据。最简单的作法就是使用一个AUTO_INCREMENT的列，这会保证记录按照顺序插入，并且能提升使用 primary key进行链接的查询的性能。应该尽可能避免随机的聚簇主键，例如，字符串主键就是一个很差的选择，它使得插入操做变得随机。

 

 3.二、覆盖索引(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就可使用索引，以下：

mysql> EXPLAIN SELECT store_id, film_id FROM sakila.inventory\G *************************** 1. row ***************************            id: 1  select_type: SIMPLE         table: inventory          type: index possible_keys: NULL           key: idx_store_id_film_id       key_len: 3           ref: NULL          rows: 5007         Extra: Using index 1 row in set (0.17 sec)

在 大多数引擎中，只有当查询语句所访问的列是索引的一部分时，索引才会覆盖。可是，InnoDB不限于此，InnoDB的二级索引在叶子节点中存储了 primary key的值。所以，sakila.actor表使用InnoDB，并且对因而last_name上有索引，因此，索引能覆盖那些访问actor_id的查 询，如：

 

mysql> EXPLAIN SELECT actor_id, last_name     -> FROM sakila.actor WHERE last_name = 'HOPPER'\G *************************** 1. row ***************************            id: 1  select_type: SIMPLE         table: actor          type: ref possible_keys: idx_actor_last_name           key: idx_actor_last_name       key_len: 137           ref: const          rows: 2         Extra: Using where; Using index

 

3.三、利用索引进行排序
MySQL 中，有两种方式生成有序结果集：一是使用filesort，二是按索引顺序扫描。利用索引进行排序操做是很是快的，并且能够利用同一索引同时进行查找和排 序操做。当索引的顺序与ORDER BY中的列顺序相同且全部的列是同一方向(所有升序或者所有降序)时，可使用索引来排序。若是查询是链接多个表，仅当ORDER BY中的全部列都是第一个表的列时才会使用索引。其它状况都会使用filesort。

create table actor( actor_id int unsigned NOT NULL AUTO_INCREMENT, name      varchar(16) NOT NULL DEFAULT '', password        varchar(16) NOT NULL DEFAULT '', PRIMARY KEY(actor_id),  KEY     (name) ) ENGINE=InnoDB insert into actor(name,password) values('cat01','1234567'); insert into actor(name,password) values('cat02','1234567'); insert into actor(name,password) values('ddddd','1234567'); insert into actor(name,password) values('aaaaa','1234567');

 

 

mysql> explain select actor_id from actor order by actor_id \G *************************** 1. row ***************************            id: 1  select_type: SIMPLE         table: actor          type: index possible_keys: NULL           key: PRIMARY       key_len: 4           ref: NULL          rows: 4         Extra: Using index 1 row in set (0.00 sec)   mysql> explain select actor_id from actor order by password \G *************************** 1. row ***************************            id: 1  select_type: SIMPLE         table: actor          type: ALL possible_keys: NULL           key: NULL       key_len: NULL           ref: NULL          rows: 4         Extra: Using filesort 1 row in set (0.00 sec)   mysql> explain select actor_id from actor order by name \G *************************** 1. row ***************************            id: 1  select_type: SIMPLE         table: actor          type: index possible_keys: NULL           key: name       key_len: 18           ref: NULL          rows: 4         Extra: Using index 1 row in set (0.00 sec)

 当 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.四、索引与加锁
索引对于InnoDB非 常重要，由于它可让查询锁更少的元组。这点十分重要，由于MySQL 5.0中，InnoDB直到事务提交时才会解锁。有两个方面的缘由：首先，即便InnoDB行级锁的开销很是高效，内存开销也较小，但无论怎么样，仍是存 在开销。其次，对不须要的元组的加锁，会增长锁的开销，下降并发性。
InnoDB仅对须要访问的元组加锁，而索引可以减小InnoDB访问的元组 数。可是，只有在存储引擎层过滤掉那些不须要的数据才能达到这种目的。一旦索引不容许InnoDB那样作（即达不到过滤的目的），MySQL服务器只能对 InnoDB返回的数据进行WHERE操做，此时，已经没法避免对那些元组加锁了：InnoDB已经锁住那些元组，服务器没法解锁了。
来看个例子：

create table actor( actor_id int unsigned NOT NULL AUTO_INCREMENT, name      varchar(16) NOT NULL DEFAULT '', password        varchar(16) NOT NULL DEFAULT '', PRIMARY KEY(actor_id),  KEY     (name) ) ENGINE=InnoDB insert into actor(name,password) values('cat01','1234567'); insert into actor(name,password) values('cat02','1234567'); insert into actor(name,password) values('ddddd','1234567'); insert into actor(name,password) values('aaaaa','1234567');

SET AUTOCOMMIT=0; BEGIN; SELECT actor_id FROM actor WHERE actor_id < 4 AND actor_id <> 1 FOR UPDATE;

 该查询仅仅返回2---3的数据，实际已经对1---3的数据加上排它锁了。InnoDB锁住元组1是由于MySQL的查询计划仅使用索引进行范围查询（而没有进行过滤操做，WHERE中第二个条件已经没法使用索引了）：

 

mysql> EXPLAIN SELECT actor_id FROM test.actor     -> WHERE actor_id < 4 AND actor_id <> 1 FOR UPDATE \G *************************** 1. row ***************************            id: 1  select_type: SIMPLE         table: actor          type: index possible_keys: PRIMARY           key: PRIMARY       key_len: 4           ref: NULL          rows: 4         Extra: Using where; Using index 1 row in set (0.00 sec)   mysql>

 代表存储引擎从索引的起始处开始，获取全部的行，直到actor_id<4为假，服务器没法告诉InnoDB去掉元组1。
为了证实row 1已经被锁住，咱们另外建一个链接，执行以下操做：

SET AUTOCOMMIT=0; BEGIN; SELECT actor_id FROM actor WHERE actor_id = 1 FOR UPDATE;

 

 该查询会被挂起，直到第一个链接的事务提交释放锁时，才会执行（这种行为对于基于语句的复制(statement-based replication)是必要的）。如上所示，当使用索引时，InnoDB会锁住它不须要的元组。更糟糕的是，若是查询不能使用索引，MySQL会进行全表扫描，并锁住每个元组，无论是否真正须要。