where条件顺序与建索引顺序

查询时,如果数据量很大,where 后面的条件与建索引的顺序相同,也没有什么多少差别,聚集索引稍微快点; 但where 后面的条件与建索引顺序不同,速度会慢下来,到底慢多少,不同的机器会不一样,没有绝对的说法。

MSSQL引擎首先对条件进行优化,优化以后再查询。
1,还是那句,先看执行计划。
2.2008的话,对where的顺序它会自己优化,测试过,顺序对执行计划没有影响,不过2005好像有。所以从规范化来说,还是把筛选性高的放在where的前面,而不是考虑是否聚集索引
3.对于建立索引,就有讲究了,统计信息只看索引的第一列,所以创建索引时,筛选性高的那列应该放到索引定义的第一位。

#1.WHERE后面的条件只要一模一样,写在哪儿都是无所谓的。相同环境下,生成的执行计划也是一样的。
#2.至于建立索引的顺序,就有讲究了:1.复合索引的第一个字段最重要,SQL SERVER只生成复合索引第一个字段的统计信息,那么优化器也只能根据复合索引的第一个字段的统计信息来优化查询。2.当你自己从业务上了解了数据分布后,怎样写SQL和怎样建立索引就是一门学问了。有时候要根据SQL语句建立索引,有时候要根据已有索引更改SQL语句(用临时表等方法)。
#3.要想学会创建适合业务的索引,除了业务中的数据分布,你要了解索引的结构(聚集和非聚集),高选择性的概念,数据在页上的存储方式,及看得懂执行计划。

sp_help ‘表名‘,拉到最下,有索引的定义

--指的fieldA,fieldB的顺序,也就是说:把fieldA这个字段排在第一位,是要考虑考虑的
CREATE INDEX IX_tablename_fieldA_fieldB ON dbo.tablename
(
FieldB
)
GO

索引顺序有讲究,where一般没有,不过2005及以下版本听说是有的,不过我没环境,你最好试一下

1、那个是符合索引。
2、所谓的索引顺序,其实是复合索引的顺序,两个索引之间没啥顺序可言,具体由sql查询优化器去根据统计信息及查询语句,和当前资源,选择使用哪个索引而已。

1、程序端的sql语句中,mssql对where的顺序会优化。不存在“ 1=1 ”的问题;也不存在“聚集 and 非聚集”的顺序问题。
2、mssql表中的索引顺序,对查询效率有影响,具体的需要结合实际业务——能够将查询结果最小化的索引放置在前面。
(个人见解——其实大多数业务中,应该是主键—聚集索引—非聚集索引)
3、符合索引的“字段A、字段B”——不说了,这个清楚。

主键仅仅为了确保业务上的数据可标识性,实际上可以没有聚集索引(我就改过很多表,把主键上的聚集索引移到别的字段上,效果不错),但是很多业务又真的需要经常使用主键做一些适合聚集索引特性的操作,所以可能这也是微软默认把主键带有聚集索引的理由之一,而且聚集索引能组织数据。对性能和维护来说很重要

时间: 2024-10-19 04:46:13

where条件顺序与建索引顺序的相关文章

4. 蛤蟆的数据结构进阶四静态查询之索引顺序查询

4. 蛤蟆的数据结构进阶四静态查询之索引顺序查询 本篇名言:"凡是新的事情在起头总是这样一来的,起初热心的人很多,而不久就冷淡下去,撒手不做了,因为他已经明白,不经过一番苦工是做不成的,而只有想做的人,才忍得过这番痛苦. --陀思妥也夫斯基" 我们继续静态查询的索引顺序查询. 欢迎转载,转载请标明出处:http://blog.csdn.net/notbaron/article/details/47264703 1.  索引顺序查询 首先把表长为n的线性表分成b块,前b-1块记录个数为s

分块查找\索引顺序查找

简介: 分块查找又称索引顺序查找,它是顺序查找的一种改进方法,性能优于顺序查找. 方法描述: 将n个数据元素"按块有序"划分为m块(一般块的长度均匀,最后一块可以不满)(m<=n),每一块中的节点不必有序,但块与块之间必须"按块有序":即第一块中的关键字必须小于(或者大于)第二块中的关键字,第二块中的关键字必须小于(或者大于)第三块中的关键字,构造索引表,索引表按关键字有序排列. 如下图所示: 图示为一个索引顺序表,其中包括三个块,第一个块的其实地址为0,快内

一个mysql索引顺序优化的案例

sql: select imsi from g_businessimsi where status='0' and channel='xiaomi' and expirdate<'201605300101' order by lastmodifytime asc limit 1; 这么一个需要频繁执行的sql,感觉性能不太理想,g_businessimsi表字段如下:mysql> show index from g_businessimsi;+----------------+--------

分块查找(索引顺序表查找)

分块查找:分块查找又称索引顺序查找,它是顺序查找的一种改进方法. 方法描述:将n个数据元素"按块有序"划分为m块(m<=n).每一块中的数据元素不必有序,但块与块之间必须"按块有序",即第1快中的任一元素的关键字都必须小于第2块中任一元素的关键字:而第2块中任一元素又都小于第3块中的任一元素,-- 图示分块如下: 操作步骤: 1.先选取各快中的最大关键字构成一个索引表 2.查找分两部分:先对索引表进行二分查找或顺序查找,以确定待查记录在哪一块中:然后在已确定的

建索引的原则-以innodb为例

一.写在前面       随着开发.测试任务进入尾声,大家都在整理一些项目发布前的一些准备工作,其中一个重要的工作就是为之前写的一些sql语句建立索引,这高并发.高访问量的环境下是非常有必要的,建立一个好的索引能够极大地提高sql语句的查询效率,那么问题来了,到底什么是索引,怎样才能建立一个好的索引呢?本文以mysql Innodb存储引擎为例,结合实际的项目来看一下,如何建立一个好的而索引. 二.索引定义 MySQL官方对索引的定义为:索引(Index)是帮助MySQL高效获取数据的数据结构.

MySQL 索引B+树原理,以及建索引的几大原则

MySQL事实上使用不同的存储引擎也是有很大区别的,下面猿友们可以了解一下. 一.存储引擎的比较 注:上面提到的B树索引并没有指出是B-Tree和B+Tree索引,但是B-树和B+树的定义是有区别的. 在?MySQL?中,主要有四种类型的索引,分别为:B-Tree 索引, Hash 索引, Fulltext 索引和 R-Tree 索引. B-Tree?索引是?MySQL?数据库中使用最为频繁的索引类型,除了 Archive 存储引擎之外的其他所有的存储引擎都支持 B-Tree 索引.Archiv

solr 的客户端调用solrj 建索引+分页查询

一.利用SolrJ操作solr API 使用SolrJ操作Solr会比利用httpClient来操作Solr要简单.SolrJ是封装了httpClient方法,来操作solr的API的.SolrJ底层还是通过使用httpClient中的方法来完成Solr的操作. 需要的包如下: 1. apache-solr-solrj-3.5.0.jar 2. commons-httpclient-3.1.jar 3.slf4j-api-1.6.0.jar 4.commons-logging-1.1.jar 在

Mysql索引分析:适合建索引?不适合建索引?【转】

数据库建立索引常用的规则如下: 1.表的主键.外键必须有索引: 2.数据量超过300的表应该有索引: 3.经常与其他表进行连接的表,在连接字段上应该建立索引: 4.经常出现在Where子句中的字段,特别是大表的字段,应该建立索引: 5.索引应该建在选择性高的字段上: 6.索引应该建在小字段上,对于大的文本字段甚至超长字段,不要建索引: 7.复合索引的建立需要进行仔细分析:尽量考虑用单字段索引代替: A.正确选择复合索引中的主列字段,一般是选择性较好的字段: B.复合索引的几个字段是否经常同时以A

MySql系列一:建索引

本文主要目的是测试单列是否应该建立索引,并以查询时间和扫描行数作为参考依据.mysql版本5.5.20 一:建表 CREATE TABLE `record` ( `id` int(11) NOT NULL AUTO_INCREMENT, `openid` varchar(63) NOT NULL, `tagId` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_openid` (`openid`) USING BTREE ) ENGINE=I