MySQL使用索引与不使用索引比较

首先，我们通过下面的方式生成1百万条数据。
http://blog.csdn.net/u011983531/article/details/67639678

一、普通索引

在不建立索引情况下，通过下面的语句查询age=20的人数

SELECT count(1) FROM `t_user` WHERE age=20;

耗时：1.2s

通过下面的语句查看执行计划

EXPLAIN SELECT count(1) FROM `t_user` WHERE age=20;

结果如下，总共查询了1000359条:

下面，我们为age字段建立普通索引。
ALTER TABLE t_user ADD INDEX index_age(age);

再次执行查询语句和查看执行计划，完成查询只需要50ms，执行计划如下：

二、唯一索引

我们通过名称来查询用户

SELECT * FROM t_user WHERE name='187874707@qq.com';

耗时：1.8s

通过下面的语句查看执行计划，如下：

下面我们为name字段建立唯一索引：

ALTER TABLE t_user ADD UNIQUE index_name(`name`);

建立索引后，再次查询，发现只需要1ms，再次查看执行计划，如下：

三、组合索引

我们通过名称和年龄来模糊匹配用户

SELECT * FROM `t_user` WHERE `name` LIKE '187%' AND age=20;

耗时：200ms
查看执行计划：

虽然我们为name和age建立了两个索引，但MySQL只能用到其中的那个它认为似乎是最有效率的索引。

下面，我们为name、age两个字段建立组合索引：
再次查询，发现耗时还是：200ms，查看执行计划，发现跟上面一样。

这说明MySQL在index_name,index_age,index_name_age3个索引中，认为index_age的效率最高。

下面，我们将index_age索引删除。

DROP INDEX index_age ON t_user;

再次执行，查看执行计划：

发现压根没有命中索引。

思考许久，觉得可能是like造成的呢，于是乎，改变策略，删除以前的组合索引，建立index_age_name组合索引。

ALTER TABLE t_user ADD INDEX index_age_name(age,name);

查看执行计划，确实命中了index_age_name索引。