mysql索引类型解释

Posted

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了mysql索引类型解释相关的知识，希望对你有一定的参考价值。

在mysql query browser 里 给表的字段建立索引的时候 会选择索引类型（index type）分别有btree，hash，rtree 这几个分别是什么意思 有什么区别，请高手指教谢谢！

索引分单列索引和组合索引。单列索引，即一个索引只包含单个列，一个表可以有多个单列索引，但这不是组合索引。组合索引，即一个索包含多个列。
MySQL索引类型包括：
(1)普通索引
这是最基本的索引，它没有任何限制。它有以下几种创建方式：
◆创建索引
CREATE INDEX indexName ON mytable(username(length));
如果是 CHAR，VARCHAR类型，length可以小于字段实际长度;如果是BLOB和TEXT类型，必须指定 length，下同。
◆修改表结构
ALTER mytable ADD INDEX [indexName] ON (username(length))
◆ 创建表的时候直接指定
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, INDEX [indexName] (username(length)) );
删除索引的语法：
DROP INDEX [indexName] ON mytable;
(2)唯一索引
它与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。它有以下几种创建方式：
◆创建索引
CREATE UNIQUE INDEX indexName ON mytable(username(length))
◆修改表结构
ALTER mytable ADD UNIQUE [indexName] ON (username(length))
◆创建表的时候直接指定
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, UNIQUE [indexName] (username(length)) );
(3)主键索引
它是一种特殊的唯一索引，不允许有空值。一般是在建表的时候同时创建主键索引：
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, PRIMARY KEY(ID) );
当然也可以用 ALTER 命令。记住：一个表只能有一个主键。
(4)组合索引
为了形象地对比单列索引和组合索引，为表添加多个字段：
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, city VARCHAR(50) NOT NULL, age INT NOT NULL );
为了进一步榨取MySQL的效率，就要考虑建立组合索引。就是将 name, city, age建到一个索引里：
ALTER TABLE mytable ADD INDEX name_city_age (name(10),city,age);
建表时，usernname长度为 16，这里用 10。这是因为一般情况下名字的长度不会超过10，这样会加速索引查询速度，还会减少索引文件的大小，提高INSERT的更新速度。
如果分别在 usernname，city，age上建立单列索引，让该表有3个单列索引，查询时和上述的组合索引效率也会大不一样，远远低于我们的组合索引。虽然此时有了三个索引，但MySQL只能用到其中的那个它认为似乎是最有效率的单列索引。
建立这样的组合索引，其实是相当于分别建立了下面三组组合索引：
usernname,city,age usernname,city usernname
为什么没有 city，age这样的组合索引呢?这是因为MySQL组合索引“最左前缀”的结果。简单的理解就是只从最左面的开始组合。并不是只要包含这三列的查询都会用到该组合索引，下面的几个SQL就会用到这个组合索引：
SELECT * FROM mytable WHREE username="admin" AND city="郑州" SELECT * FROM mytable WHREE username="admin"
而下面几个则不会用到：
SELECT * FROM mytable WHREE age=20 AND city="郑州" SELECT * FROM mytable WHREE city="郑州"
(5)建立索引的时机
到这里我们已经学会了建立索引，那么我们需要在什么情况下建立索引呢?一般来说，在WHERE和JOIN中出现的列需要建立索引，但也不完全如此，因为MySQL只对<，<=，=，>，>=，BETWEEN，IN，以及某些时候的LIKE才会使用索引。例如：
SELECT t.Name FROM mytable t LEFT JOIN mytable m ON t.Name=m.username WHERE m.age=20 AND m.city='郑州'
此时就需要对city和age建立索引，由于mytable表的 userame也出现在了JOIN子句中，也有对它建立索引的必要。
刚才提到只有某些时候的LIKE才需建立索引。因为在以通配符%和_开头作查询时，MySQL不会使用索引。例如下句会使用索引：
SELECT * FROM mytable WHERE username like'admin%'
而下句就不会使用：
SELECT * FROM mytable WHEREt Name like'%admin'
因此，在使用LIKE时应注意以上的区别。
(6)索引的不足之处
上面都在说使用索引的好处，但过多的使用索引将会造成滥用。因此索引也会有它的缺点：
◆虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行 INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件。
◆建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会膨胀很快。
索引只是提高效率的一个因素，如果你的 MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句。
(7)使用索引的注意事项
使用索引时，有以下一些技巧和注意事项：
◆索引不会包含有NULL值的列
只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有 NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。
◆使用短索引
对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个CHAR(255)的列，如果在前10个或20个字符内，多数值是惟一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。
◆索引列排序
MySQL查询只使用一个索引，因此如果 where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作;尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。
◆like语句操作
一般情况下不鼓励使用like操作，如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。
◆不要在列上进行运算
select * from users where YEAR(adddate)<2007;
将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成
select * from users where adddate<‘2007-01-01’;
◆不使用NOT IN和<>操作
以上，就对其中MySQL索引类型进行了介绍。
转自：http://www.zbitedu.com/?action-viewthread-tid-33491 参考技术A

在满足语句需求的情况下，尽量少的访问资源是数据库设计的重要原则，这和执行的 SQL 有直接的关系，索引问题又是 SQL 问题中出现频率最高的，常见的索引问题包括：无索引（失效）、隐式转换。
1. SQL 执行流程看一个问题，在下面这个表 T 中，如果我要执行 select * from T where k between 3 and 5; 需要执行几次树的搜索操作，会扫描多少行？mysql> create table T (    -> ID int primary key,    -> k int NOT NULL DEFAULT 0,    -> s varchar(16) NOT NULL DEFAULT '',    -> index k(k))    -> engine=InnoDB;mysql> insert into T values(100,1, 'aa'),(200,2,'bb'),\\      (300,3,'cc'),(500,5,'ee'),(600,6,'ff'),(700,7,'gg');
这分别是 ID 字段索引树、k 字段索引树。 

这条 SQL 语句的执行流程：

1. 在 k 索引树上找到 k=3，获得 ID=3002. 回表到 ID 索引树查找 ID=300 的记录，对应 R33. 在 k 索引树找到下一个值 k=5，ID=5004. 再回到 ID 索引树找到对应 ID=500 的 R4

5. 在 k 索引树去下一个值 k=6，不符合条件，循环结束

这个过程读取了 k 索引树的三条记录，回表了两次。因为查询结果所需要的数据只在主键索引上有，所以必须得回表。所以，我们该如何通过优化索引，来避免回表呢？
2. 常见索引优化2.1 覆盖索引覆盖索引，换言之就是索引要覆盖我们的查询请求，无需回表。

如果执行的语句是 select ID from T wherek between 3 and 5;，这样的话因为 ID 的值在 k 索引树上，就不需要回表了。

覆盖索引可以减少树的搜索次数，显著提升查询性能，是常用的性能优化手段。

但是，维护索引是有代价的，所以在建立冗余索引来支持覆盖索引时要权衡利弊。

2.2 最左前缀原则

B+ 树的数据项是复合的数据结构，比如 (name,sex，age) 的时候，B+ 树是按照从左到右的顺序来建立搜索树的，当 (张三,F,26) 这样的数据来检索的时候，B+ 树会优先比较 name 来确定下一步的检索方向，如果 name 相同再依次比较 sex 和 age，最后得到检索的数据。

    # 有这样一个表 P

    mysql> create table P (id int primary key, name varchar(10) not null, sex varchar(1), age int, index tl(name,sex,age)) engine=IInnoDB;

    mysql> insert into P values(1,'张三','F',26),(2,'张三','M',27),(3,'李四','F',28),(4,'乌兹','F',22),(5,'张三','M',21),(6,'王五','M',28);

    # 下面的语句结果相同

    mysql> select * from P where name='张三' and sex='F';     ## A1

    mysql> select * from P where sex='F' and age=26;         ## A2

    # explain 看一下

    mysql> explain select * from P where name='张三' and sex='F';

    +----+-------------+-------+------------+------+---------------+------+---------+-------------+------+----------+-------------+

    | id | select_type | table | partitions | type | possible_keys | key  | key_len | ref         | rows | filtered | Extra       |

    +----+-------------+-------+------------+------+---------------+------+---------+-------------+------+----------+-------------+

    |  1 | SIMPLE      | P     | NULL       | ref  | tl            | tl   | 38      | const,const |    1 |   100.00 | Using index |

    +----+-------------+-------+------------+------+---------------+------+---------+-------------+------+----------+-------------+

    mysql> explain select * from P where sex='F' and age=26;

    +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+--------------------------+

    | id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra                    |

    +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+--------------------------+

    |  1 | SIMPLE      | P     | NULL       | index | NULL          | tl   | 43      | NULL |    6 |    16.67 | Using where; Using index |

    +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+--------------------------+

    可以清楚的看到，A1 使用 tl 索引，A2 进行了全表扫描，虽然 A2 的两个条件都在 tl 索引中出现，但是没有使用到 name 列，不符合最左前缀原则，无法使用索引。所以在建立联合索引的时候，如何安排索引内的字段排序是关键。评估标准是索引的复用能力，因为支持最左前缀，所以当建立（a，b）这个联合索引之后，就不需要给 a 单独建立索引。原则上，如果通过调整顺序，可以少维护一个索引，那么这个顺序往往就是需要优先考虑采用的。上面这个例子中，如果查询条件里只有 b，就是没法利用（a，b）这个联合索引的，这时候就不得不维护另一个索引，也就是说要同时维护（a，b）、（b）两个索引。这样的话，就需要考虑空间占用了，比如，name 和 age 的联合索引，name 字段比 age 字段占用空间大，所以创建（name，age）联合索引和（age）索引占用空间是要小于（age，name）、(name）索引的。

    2.3 索引下推

    以人员表的联合索引（name, age）为例。如果现在有一个需求：检索出表中“名字第一个字是张，而且年龄是26岁的所有男性”。那么，SQL 语句是这么写的mysql> select * from tuser where name like '张%' and age=26 and sex=M;
    通过最左前缀索引规则，会找到 ID1，然后需要判断其他条件是否满足在 MySQL 5.6 之前，只能从 ID1 开始一个个回表。到主键索引上找出数据行，再对比字段值。而 MySQL 5.6 引入的索引下推优化(index condition pushdown)，可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数。这样，减少了回表次数和之后再次过滤的工作量，明显提高检索速度。

    2.4 隐式类型转化

    隐式类型转化主要原因是，表结构中指定的数据类型与传入的数据类型不同，导致索引无法使用。所以有两种方案：修改表结构，修改字段数据类型。

    修改应用，将应用中传入的字符类型改为与表结构相同类型。

    3. 为什么会选错索引3.1 优化器选择索引是优化器的工作，其目的是找到一个最优的执行方案，用最小的代价去执行语句。在数据库中，扫描行数是影响执行代价的因素之一。扫描的行数越少，意味着访问磁盘数据的次数越少，消耗的 CPU 资源越少。当然，扫描行数并不是唯一的判断标准，优化器还会结合是否使用临时表、是否排序等因素进行综合判断。

    3.2 扫描行数

    MySQL 在真正开始执行语句之前，并不能精确的知道满足这个条件的记录有多少条，只能通过索引的区分度来判断。显然，一个索引上不同的值越多，索引的区分度就越好，而一个索引上不同值的个数我们称为“基数”，也就是说，这个基数越大，索引的区分度越好。# 通过 show index 方法，查看索引的基数mysql> show index from t;+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+| t     |          0 | PRIMARY  |            1 | id          | A         |       95636 |     NULL | NULL   |      | BTREE      |         |               || t     |          1 | a        |            1 | a           | A         |       96436 |     NULL | NULL   | YES  | BTREE      |         |               || t     |          1 | b        |            1 | b           | A         |       96436 |     NULL | NULL   | YES  | BTREE      |         |               |+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
    MySQL 使用采样统计方法来估算基数：采样统计的时候，InnoDB 默认会选择 N 个数据页，统计这些页面上的不同值，得到一个平均值，然后乘以这个索引的页面数，就得到了这个索引的基数。而数据表是会持续更新的，索引统计信息也不会固定不变。所以，当变更的数据行数超过 1/M 的时候，会自动触发重新做一次索引统计。

    在 MySQL 中，有两种存储索引统计的方式，可以通过设置参数 innodb_stats_persistent 的值来选择：

    on 表示统计信息会持久化存储。默认 N = 20，M = 10。

    off 表示统计信息只存储在内存中。默认 N = 8，M = 16。

    由于是采样统计，所以不管 N 是 20 还是 8，这个基数都很容易不准确。所以，冤有头债有主，MySQL 选错索引，还得归咎到没能准确地判断出扫描行数。

    可以用 analyze table 来重新统计索引信息，进行修正。

    ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...
    3.3 索引选择异常和处理1. 采用 force index 强行选择一个索引。2. 可以考虑修改语句，引导 MySQL 使用我们期望的索引。3. 有些场景下，可以新建一个更合适的索引，来提供给优化器做选择，或删掉误用的索引。

MySQL具体解释----------索引具体解释

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

考虑例如以下情况。假设数据库中一个表有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索引
如果有例如以下一个表：

 

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索引进行全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( )。例如以下：

 

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.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的数据布局。对于例如以下表：

 

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能够非常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就能够使用索引，例如以下：

 

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

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


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

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

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

 

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为假，server无法告诉InnoDB去掉元组1。
为了证明row 1已经被锁住，我们另外建一个连接，运行例如以下操作：

 

SET AUTOCOMMIT=0;

BEGIN;

SELECT actor_id FROM actor WHERE actor_id   = 1 FOR UPDATE;

 

 

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


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

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


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

以上是关于mysql索引类型解释的主要内容，如果未能解决你的问题，请参考以下文章

mysql解释类型索引与所有性能问题

在MYSQL中运用全文索引(FULLTEXT index)

mysql数据库怎么建索引？

为啥mysql解释说'使用索引'而使用的索引不包含必填字段

解释mysql中啥是索引？它的作用是啥？

mysql索引类型和索引方式