高性能的MySQL(5)索引策略-覆盖索引与索引排序

一、覆盖索引

索引是一种查找数据的高效方式,但是MySQL也可以使用索引来直接获取列的数据,这样就不再需要读取数据行。如果索引的叶子节点中已经包含要查询的数据,那么还有什么必要回表查询呢?

如果一个索引包含或者说覆盖所有需要查询的字段的值,我们就称之为“覆盖索引”。

覆盖索引的好处:

1、索引条目通常远小于数据行大小,所以如果只需要读取索引,就极大的减少数据访问量。这对MyISAM尤其正确,因为MyISAM能压缩索引以变得更小。

2、因为索引是按照顺序存储的,所以对于I/O密集型的范围查询会比随机从磁盘读取每一行数据的I/O要少很多。

3、由于InnoDB的聚簇索引,覆盖索引对InnoDB特别有用。InnoDB的二级索引在叶子节点中保存了行的主键值,所以如果二级主键能够覆盖查询,则可以避免对主键索引的二次查询。

覆盖索引必须要存储索引列的值,而哈希索引、空间索引、和全文索引都不能存储列的值,所以MySQL只能使用B-Tree索引做覆盖索引。

当发起一个索引覆盖的查询时,在EXPLAIN的Extra列可以看到Usingindex的信息。例如:

如果索引覆盖了WHERE条件中的字段,但不是整个查询涉及的字段,看看是什么情况

没有任何索引能覆盖这个查询,因为查询从表中选择了所有的列,而没有任何索引覆盖所有的列。但是索引还是用到了。

接下来可以对比一下,可以使用聚簇索引的InnoDB和MyISAM对覆盖索引的区别。

首先看MyISAM表,表结构如下

时间: 2024-10-27 20:09:23

高性能的MySQL(5)索引策略-覆盖索引与索引排序的相关文章

高性能的MySQL(5)索引策略-索引案例分析

理解索引最好的办法是结合实例,接下来分析一个例子. 假设要设计一个在线约会网站,用户信息表有很多列,包括国家,地区,城市,性别,眼睛颜色等等.网站必须支持上面的各种组合来搜索用户,包括根据用户的最后在线时间,评分等进行排序的限制. 需要考虑是需要索引来排序还是先检索数据再排序,因为使用索引排序会严格限制索引和查询的设计.如果MySQL使用了某个索引的范围查询,也就无法再使用另一个索引或者是该索引的后续字段进行排序了.接下来一步步讨论: 1.支持多种过滤条件 country列的选择性通常不高,但是

MySQL索引背后的之使用策略及优化(高性能索引策略)_Mysql

本章的内容完全基于上文的理论基础,实际上一旦理解了索引背后的机制,那么选择高性能的策略就变成了纯粹的推理,并且可以理解这些策略背后的逻辑. 示例数据库 为了讨论索引策略,需要一个数据量不算小的数据库作为示例.本文选用MySQL官方文档中提供的示例数据库之一:employees.这个数据库关系复杂度适中,且数据量较大.下图是这个数据库的E-R关系图(引用自MySQL官方手册):   图12 MySQL官方文档中关于此数据库的页面为http://dev.mysql.com/doc/employee/

高性能的MySQL(5)索引策略-索引和表的维护

维护表有三个主要的目的: 1.找到并修复损坏的表. 对于MyISAM存储引擎来说,表损坏通常是系统崩溃导致的.其他的引擎也会由于硬件的问题,MySQL本身的缺陷或者操作系统的问题导致索引的损坏. 损坏的索引,会导致查询返回错误的结果或者莫须有的主键冲突等问题,严重时还会导致数据库崩溃. 这类情况,可以尝试check table来检查是否发生了表损坏,有些存储引擎不支持这个命令. 可以使用repair table 来修复损坏的表,但同样不是所有引擎都支持该命令. 如果引擎不支持,可以使用alter

高性能的MySQL(5)索引策略一压缩,冗余,重复,索引和锁

一.压缩索引 MyISAM使用前缀压缩来减少索引的大小,默认只压缩字符串,但是通过设置也可以对整数做压缩. 压缩可以使用更少的空间,代价是某些操作可能更慢.特别是倒序的查询,测试表明,对于CPU密集型的应用,查询会很慢,特别是倒序.对于I/O密集型应用,查询可能会不错. 可以在CREATE TABLE的语句中指定PACK_KEYS参数来指定索引压缩方式. 二.冗余和重复索引 重复索引:指在相同的列上按照相同的顺序创建的相同类型的索引,要尽量避免重复索引,除非在同一列上创建不同类型的索引来满足不同

高性能的MySQL(5)索引策略

一.索引的优点 1.索引可以大大减少服务器需要扫描的数据量 2.索引可以帮助服务器避免排序和临时表. 3.索引可以将随即I/O变为顺序I/O 二.索引策略 1.独立的列 独立的列是指索引列不能是表达式的一部分,也不能是函数参数.例如: 一个有500W条记录的表,id是主键. 所以要始终将索引列单独放在比较符号的一侧. 2.前缀索引和索引选择性 对于比较大的列,通常可以索引开始的部分字符,这样可以节约索引空间,提高索引率.但是也会降低索引的选择性. 索引的选择性是指,不重复的索引值(基数)和表的记

高性能的MySQL(5)创建高性能的索引一哈希索引

哈希索引(hash index)基于哈希表实现,只有精确匹配索引的所有列的查询才有效,对于每一行数据,存储引擎都会对所有索引列计算一个哈希码,不同键值的行计算出来的哈希码也不一样,哈希码保存在哈希索引中,同时哈希表中保存指向每个数据的指针. 1.Memory引擎支持哈希索引,也支持B-Tree索引,而且支持非唯一的哈希索引,如果多个列的哈希值相同,索引会以链表的方式存放多个记录指针到同一个哈希条目,这个是和特别的. 举例说明: CREATE TABLE `testhash` ( `fname`

Mysql性能优化案例 - 覆盖索引分享_Mysql

场景 产品中有一张图片表,数据量将近100万条,有一条相关的查询语句,由于执行频次较高,想针对此语句进行优化 表结构很简单,主要字段: 复制代码 代码如下: user_id 用户ID picname 图片名称 smallimg 小图名称 一个用户会有多条图片记录 现在有一个根据user_id建立的索引:uid 查询语句也很简单:取得某用户的图片集合 复制代码 代码如下: select picname, smallimg from pics where user_id = xxx; 优化前 执行查

MySQL SQL优化之覆盖索引

前些天,有个同事跟我说:"我写了个SQL,SQL很简单,但是查询速度很慢,并且针对查询条件创建了索引,然而索引却不起作用,你帮我看看有没有办法优化?". 我对他提供的case进行了优化,并将优化过程整理了下来. 优化前的表结构.数据量.SQL.执行计划.执行时间 表结构 CREATE TABLE `t_order` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `order_code` char(12) NOT NULL, `o

浅析MySQL中的Index Condition Pushdown (ICP 索引条件下推)和Multi-Range Read(MRR 索引多范围查找)查询优化

原文:浅析MySQL中的Index Condition Pushdown (ICP 索引条件下推)和Multi-Range Read(MRR 索引多范围查找)查询优化   本文出处:http://www.cnblogs.com/wy123/p/7374078.html(保留出处并非什么原创作品权利,本人拙作还远远达不到,仅仅是为了链接到原文,因为后续对可能存在的一些错误进行修正或补充,无他)     ICP优化原理 Index Condition Pushdown (ICP),也称为索引条件下推