MySQL学习之索引（一）

索引的类型

索引是由存储引擎来实现的，而不是在服务层，所以不同的引擎的索引的工作方案可能会有不同，支持的索引种类也不尽相同等等。

B-Tree Indexes

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)
);

以下查询会使用到B-Tree索引

全值匹配(Match the full value)：如查找一个出生于1960-01-01名叫Cuba Allen的人

左前缀匹配(Match a leftmost prefix)：如查找一个叫Allen的人，只对第一列有效

列前缀匹配(Match a column prefix): 如查找所有姓以J开头的人，只对第一列有效

范围匹配(Match  a range of values): 如查找Allen到Barrymore之间的人，只对第一列有效

Match one part ane match a range of another part：如查找姓为Allen，名字以K打头的人

B-Tree的局限

• 如果查询不是从最左边起则无效，比如你要查询所有名字是Bill的人
• 不能跳列，比如你要查询姓是Smith出生在1960-01-01的人
• 不能优化左侧为范围查询的语句，如last_name="Smith" AND first_name LIKE 'J%' AND dob = '1960-01-01', 只有前两列被被索引使用。

所有有时为了优化查询，会创建好几种不同顺序的B-Tree索引，来克服这些缺点。

----------------------------------------------分割线-------------------------------------------------------

Hash Indexes

hash索引只能用于精确查找。Memory默认是hash索引的。

如

CREATE TABLE testhash (
    fname VARCHAR(50) NOT NULL,
    lname VARCHAR(50) NOT NULL,
    key USING HASH(fname)
) ENGINE=MEMORY

里面有如下数据

现在假设一个函数叫f()，用来计算hash值，那么

f('Arjen') = 2323

f('Baron') = 2458

....

那么我们可以得到这样的索引结构

当你执行如下语句:

mysql> SELECT * FROM testhash WHERE fname='Peter'

MySQL会去计算Peter的hash值，再找到指向这条记录的指针。

hash索引的速度非常的快，但它也有局限：

1. 由于索引里只有指向行的指针，所以MySQL无法通过读取索引里的值来避免读取数据行。

2. 不能排序

3. 不能支持部分查询

4. 只支持等式查询如=, IN(), <=>，范围查询无效

5. 如果hash值的冲突量(很多行指向同一个hash值)很大，查询会变慢

6. 如果hash值冲突量很大，索引的维护操作也会变慢

InnoDB有个机制叫做Adaptive Hash Indexes.当它发现一些索引被经常使用时，会在内存中为这个索引上面创建一个hash索引来加快查询速度