十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
在innoDB中,有两大索引类,分别是
成都网站建设哪家好,找创新互联!专注于网页设计、网站建设、微信开发、小程序制作、集团成都企业网站建设等服务项目。核心团队均拥有互联网行业多年经验,服务众多知名企业客户;涵盖的客户类型包括:房屋鉴定等众多领域,积累了大量丰富的经验,同时也获得了客户的一致赞誉!
执行上述语句,执行过程如下图
从图中,我们可以看出,扫了两个索引树
(1)先从普通索引name找到lisi
(2)再根据主键值9,再在聚集索引中找到行记录。
这就是回表查询,先在普通索引中找到主键值,再在聚集索引中找到行记录。
很显然,在一棵索引树上就能获取SQL所需的所有列数据的,就是索引覆盖。
如下语句
很显然,我们可以直接在name索引上直接找到id,name,不用再去回表。
而且我们通过explain的extra属性也能观察到
像我们开头的SQL语句
我们只需要在name索引中再加个sex,name(name,sex),这样变成了联合索引,也是索引覆盖。
通常大家都会根据查询的WHERE条件来创建合适的索引,不过这只是索引优化的一个方面。设计优秀的索引应该考虑到整个查询,而不单单是WHERE条件部分。索引确实是一种查找数据的高效方式,但是MySQL也可以使用索引来直接获取列的数据,这样就不再需要读取数据行。如果索引的叶子节点中已经包含要查询的数据,那么还有什么必要再回到表中查询呢? 如果一个索引覆盖所有需要查询的字段的值,我们就称之为“覆盖索引”。
覆盖索引是非常有用的工具,能够极大地提高性能:
在所有这些场景中,在索引中满足查询的成本一般比查询行要小得多。
不是所有类型的索引都可以成为覆盖索引。覆盖索引必须要存储索引列的值,而哈希索引、空间索引和全文索引都不存储索引列的值,所以MySQL只能使用B+Tree索引所覆盖索引。另外,不同的存储引擎实现覆盖索引的方式也不同,而且不是所有的引擎都支持覆盖索引。
当发起一个呗索引覆盖的查询是,在EXPLAIN的Extra列可以看到“Using index”的信息。
如: explain select col1 from layout_test where col2=99
索引覆盖查询还有很多陷阱可能会导致无法实现优化。MySQL查询优化器会在执行查询前判断是否有一个索引能进行覆盖。假设索引覆盖了wehre条件中的字段,但不是整个查询涉及的字段。mysql5.5和更早的版本也总是会回表获取数据行,尽管并不需要这一行且最终会被过滤掉。
如: EXPLAIN select * from people where last_name='Allen' and first_name like '%Kim%'
这里索引无法覆盖该查询,有两个原因:
这条语句只检索1行,而之前的 like '%Kim%'要检索3行。
也有办法解决上面所说的两个问题,需要重写查询并巧妙设计索引。
这种方式叫做延迟关联,因为延迟了对列的访问。在查询第一个阶段MySQL可以使用覆盖索引,因为索引包含了主键id的值,不需要做二次查找。
在FROM子句的子查询中找到匹配的id,然后根据这些id值在外层查询匹配获取需要的所有列值。虽然无法使用索引覆盖整个查询,但总算比完全无法利用索引覆盖的好吧。
数据量大了怎么办?
这样优化的效果取决于WHERE条件匹配返回的行数。假设这个people表有100万行,我们看一下上面两个查询在三个不同的数据集上的表现,每个数据集都包含100万行。
实例1中 ,查询返回了一个很大的结果集,因此看不到优化的效果。大部分时间都花在读取和发送数据上了。
实例2中 ,经过索引过滤,尤其是第二个条件过滤后只返回了很少的结果集,优化的效果非常明显:在这个数据及上性能提高了很多,优化后的查询效率主要得益于只需读取40行完整数据行,而不是原查询中需要的30000行。
实例3中 ,子查询效率反而下降。因为索引过滤时符合第一个条件的结果集已经很小了,所以子查询带来的成本反而比从表中直接提取完整行更高。
在大多数存储引擎中,覆盖索引只能覆盖那些只访问索引中部分列的查询。不过,可以更进一步优化InnoDB。回想一下,InnoDB的二级索引的叶子节点都包含了主键的值,这意味着InnoDB的二级索引可以有效地利用这些额外的主键列来覆盖查询。
例如,people表中last_name字段有一个二级索引,虽然该索引的列不包括主键id,但也能够用于对id做覆盖查询:
select id,last_name from people where last_name='hua'
在实际开发中使用数据库时,难免会遇到一些大表数据,对这些数据进行查询时,有时候SQL会查询得特别慢,这时候,有经验的老师傅会告诉你,你看一下哪几个字段查的多,加一个索引就好了。
那么,怎么合理地建立索引呢?这里分享一下我的一些经验,如有不妥之处,欢迎批评指正。
1、不要盲目建立索引 , 先分析再创建
索引虽然能大幅度提升我们的查询性能,但也要知道,在你进行增删改时,索引树也要同样地进行维护。所以,索引不是越多越好,而是按需建立。最好是在一整块模块开发完成后,分析一下,去针对大多数的查询,建立联合索引。
2、使用联合索引尽量覆盖多的条件
这是说在一个慢sql里假如有五个where ,一个 order by ,那么我们的联合索引尽量覆盖到这五个查询条件,如果有必要,order by 也覆盖上 。
3、小基数字段不需要索引
这个意思是,如果一张表里某个字段的值只有那么几个,那么你针对这个字段建立的索引其实没什么意义,比如说,一个性别字段就两种结果,你建了索引,排序也没什么意思(也就是索引里把男女给分开了)
所以说,索引尽量选择基数大的数据去建立,能最大化地利用索引
4、长字符串可以使用前缀索引
我们建立索引的字段尽量选择字段类型较小的,比如一个varchar(20)和varchar(256)的,我们在20的上面建立的索引和在256上就有明显的差距(字符串那么长排序也不好排呀,唉)。
当然,如果一定是要对varchar(256)建立索引,我们可以选择里面的前20个字符放在索引树里(这里的20不绝对,选择能尽量分辨数据的最小字符字段设计),类似这样KEY index(name(20),age,job) ,索引只会对name的前20个字符进行搜索,但前缀索引无法适用于order by 和 group by。
5、对排序字段设计索引的优先级低
如果一个SQL里我们出现了范围查找,后边又跟着一个排序字段,那么我们优先给范围查找的字段设置索引,而不是优先排序。
6、如果出现慢SQL,可以设计一个只针对该条SQL的联合索引。
不过慢SQL的优化,需要一步步去进行分析,可以先用explain查看SQL语句的分析结果,再针对结果去做相应的改进。explain的东西我们下次再讲。
PS:在 select 语句之前增加 explain 关键字,MySQL 会在查询上设置一个标记,执行查询会返回执行计划的信息,而不是 执行这条SQL。
你的意思是通过建立足够多的索引,而不必去读行数据吗? 那就要把你的查询where 的每一个字段都要添加一个索引,是单独的字段,不要组合的字段索引。
组合索引是两个及以上的字段组合到一起,这样的话,只有where 前两个判断都到用到这个组合字段才有用,其他情况是用不到索引的。比如索引 a,b 只有where a=xx and b=xx的时候有用。
你的意思可能就是 where a=xx AND b=xx AND c=XX, 那么,要把这三个字段都要添加索引才行
索引也是需要空间的,建议最常用的查询字段建立索引就行了