复合索引的列顺序判断

复合索引最令人困惑的当属索引列的顺序,不仅依赖于使用该索引的查询,更需考虑排序和分组。

前段时候我发了个帖子:where条件顺序和复合索引字段顺序。感兴趣的朋友不妨参与讨论。

今天我提个自己的观点。

在应用开发阶段,【选择性】是我们首要考虑因素,请看简图:

当出现sql性能问题时,你可能需要注意以下几个:

1. 随机IO

2. 排序(order by)

3. 分组(group by or distinct)

这时不必也不应该在关注【选择性】

我的经验便是,在你手上已经有Top N SQL时,我们应该优先考虑【值的分布】,而不是选择性。

那么该如何判断【值的分布】,我们通过一种被geek称之为 【sarg】的方法,具体操作如下:

假如,我们有如下query:

[sql] view plain copy print?

  1. select * from userresult_f where askid=800808 and uid=110996854;
select * from userresult_f where askid=800808 and uid=110996854;

则有2个索引可供选择:

1. idx_1 (askid,uid)

2. idx_2 (uid,askid)

是1 还是2 ?

利用【sarg】方法:

[sql] view plain copy print?

  1. mysql> select sum(askid=800808),sum(uid=110996854) from userresult_f\G;
  2. *************************** 1. row ***************************
  3. sum(askid=800808): 6
  4. sum(uid=110996854): 2
  5. 1 row in set (0.00 sec)
mysql> select sum(askid=800808),sum(uid=110996854) from userresult_f\G;
*************************** 1. row ***************************
sum(askid=800808): 6
sum(uid=110996854): 2
1 row in set (0.00 sec)

依据查询输出,我们应该选择 idx_2

By 数据牧羊人

Good Luck!

2014-4-27 19:05  于福州

时间: 2024-10-10 17:51:13

复合索引的列顺序判断的相关文章

SQL Server 执行计划利用统计信息对数据行的预估原理二(为什么复合索引列顺序会影响到执行计划对数据行的预估)

本文出处:http://www.cnblogs.com/wy123/p/6008477.html 关于统计信息对数据行数做预估,之前写过对非相关列(单独或者单独的索引列)进行预估时候的算法,参考这里. 今天来写一下统计信息对于复合索引在预估时候的计算方法和潜在问题. 本文原形来自于是个实际业务问题,某SQL在利用一个符合索引做查询的时候,发现始终会出现预估误差较大的情况, 而改变复合索引的列顺序,这个预估行数的误差会发生变化, 也就是说,Create  index idx_index1 ON T

SQL Server创建复合索引时,复合索引列顺序对查询的性能影响

说说复合索引 写索引的博客太多了,一直不想动手写,有一下两个原因:一是觉得有炒剩饭的嫌疑,有兄弟曾说:索引吗,只要在查询条件上建索引就行了,真的可以这么暴力吗?二来觉得,索引是个非常大的话题,很难概括出所有的情况,你不整出点新意来,倒是有抄袭照搬的嫌疑 既然写了,就写一点稍微不一样的东西出来,好了,废话打住,开搞 /* 20160814备注:今天发现一个类似的文章:http://www.cnblogs.com/fly_zj/archive/2012/08/11/2633629.html : 可以

SQL SERVER大话存储结构(4)_复合索引与包含索引

索引这块从存储结构来分,有2大类,聚集索引和非聚集索引,而非聚集索引在堆表或者在聚集索引表都会对其 键值有所影响,这块可以详细查看本系列第二篇文章:SQL SERVER大话存储结构_(2)_非聚集索引如何查找到行记录. 非聚集索引内又分为多类:单列索引.复合索引.包含索引.过滤索引等.之前文章有具体分析过非聚集索引的存储情况,但是没有对复合索引及包含索引做过多说明,本文来讲讲这两个索引. 如果转载,请注明博文来源: www.cnblogs.com/xinysu/   ,版权归 博客园 苏家小萝卜

复合索引介绍

什么是复合索引 1.1           复合索引定义 索引可以包含一个.两个或更多个列.两个或更多个列上的索引被称作复合索引. 利用索引中的附加列,您可以缩小搜索的范围,但使用一个具有两列的索引不同于使用两个单独的索引.复合索引的结构与电话簿类似,人名由姓和名构成,电话簿首先按姓氏对进行排序,然后按名字对有相同姓氏的人进行排序.如果您知道姓,电话簿将非常有用:如果您知道姓和名,电话簿则更为有用,但如果您只知道名不姓,电话簿将没有用处. 所以说创建复合索引时,应该仔细考虑列的顺序.对索引中的所

复合索引使用的先决条件

PS:懒得重新编辑图片了,直接把我从51上的日志拷过来了. 背景: 今天,接到一个项目的项目经理电话,告之说生产环境有几个查询超级慢,就是查询单张表的数据,查询条件也很简单,但是加了索引以后并没有走索引,依然还是走的全表扫描.听到该问题描述,我开始浮想联翩,统计信息太旧?存在隐式转换?索引树倾斜度太高,导致oracle认为走索引的成本更高?带着各种可能的原因猜想,火速赶到了现场,发现原来都是我想多了.不走索引单纯是建立的索引不合理,查询条件是多个字段,应该建立复合索引,现场维护人员只对其中单个字

mysql复合索引、普通索引总结

对于复合索引:Mysql从左到右的使用索引中的字段,一个查询可以只使用索引中的一部份,但只能是最左侧部分.例如索引是key index (a,b,c). 可以支持a | a,b| a,b,c 3种组合进行查找,但不支持 b,c进行查找 .当最左侧字段是常量引用时,索引就十分有效.下面用几个例子对比查询条件的不同对性能影响. create table test(a int,b int,c int,KEY a(a,b,c)); 优: select * from test where a=10 and

MySQL 复合索引

一. 1.索引越少越好,在修改数据时,第个索引都要进行更新,降低写速度.2.最窄的字段放在键的左边3.避免file sort排序,临时表和表扫描. 二.复合索引的建立原则: 如果您很可能仅对一个列多次执行搜索,则该列应该是复合索引中的第一列.如果您很可能对一个两列索引中的两个列执行单独的搜索,则应该创建另一个仅包含第二列的索引.如上图所示,如果查询中需要对年龄和性别做查询,则应当再新建一个包含年龄和性别的复合索引.包含多个列的主键始终会自动以复合索引的形式创建索引,其列的顺序是它们在表定义中出现

复合索引,覆盖索引,书签查找(键查找)

今天一位小伙伴问我关于SQL查询效率以及索引的东西. 我说只要尽量命中索引即可.特别是聚集索引.思前想后,好像总有什么不对! 于是又做了一番资料查询,发现索引不是那么简单,即使是命中索引也是没那么简单. 突然有些感慨,当个DBA不容易啊. 1.复合索引 先说说复合索引,相信大家都知道.两个或更多列上的索引就被称作复合索引. 最近在做某酒店的项目.拿这个举个例子: Order表名, 其中包含列:GuestSrcCode(客源代码),HotelID(酒店编号) tips:客源代码只有几种情况(散客,

通俗易懂 索引、单列索引、复合索引、主键、唯一索引、聚簇索引、非聚簇索引、唯一聚簇索引 的区别与联系

索引 数据库只做两件事情:存储数据.检索数据.而索引是在你存储的数据之外,额外保存一些路标(一般是B+树),以减少检索数据的时间.所以索引是主数据衍生的附加结构. 一张表可以建立任意多个索引,每个索引可以是任意多个字段的组合.索引可能会提高查询速度(如果查询时使用了索引),但一定会减慢写入速度,因为每次写入时都需要更新索引,所以索引只应该加在经常需要搜索的列上,不要加在写多读少的列上. 单列索引 与 复合索引 只包含一个字段的索引叫做单列索引,包含两个或以上字段的索引叫做复合索引(或组合索引).