索引键列和包含性列

1、主键必须是唯一性的,不一定就是聚集索引,我们在创建主键时默认是设主键为聚集索引。可通过手动删除后重新建聚集索引。

2、sql语句是where先执行,然后再执行order by,所以我们在建非聚集索引时要注意顺序并且where与order by里面的列都要在索引键列里面。select部份可以放在包含性列里面,但请注意索引大小的空间问题。

3、order by里面的升序和降序问题一定要和索引键列里面的一样。

例:select id,title from table1 where classid=123 order by created DESC

情况一

操作:建非聚集索引IX_A->索引键列为classid(升序降序无所谓)、created(一定要降序)

注意索引键列中两个字段的先后顺序,两个键列缺一不可。

执行:1.IX_A索引查找出ID,2.根据ID通过 键查找 找出title->返回结果

情况二

操作:建非聚集索引IX_B->索引键列为classid(升序降序无所谓)、created(一定要降序) ->添加包含性列id,title

注意索引键列中两个字段的先后顺序,两个键列缺一不可。

执行:1.IX_B索引查找->返回结果

以上两个方法如果created的排序弄错了,还将多一步,即:

情况一:1.IX_A索引查找出ID,2.根据ID通过 键查找 找出title,3.排序->返回结果

情况二:1.IX_B索引查找,2.排序->返回结果

时间: 2024-08-30 03:09:35

索引键列和包含性列的相关文章

具有包含性列的索引

在 SQL Server 2005 中,可以通过将非键列添加到非聚集索引的叶级别来扩展非聚集索引的功能.通过包含非键列,可以创建覆盖更多查询的非聚集索引.这是因为非键列具有下列优点: 它们可以是不允许作为索引键列的数据类型. 在计算索引键列数或索引键大小时,数据库引擎不考虑它们. 当查询中的所有列都作为键列或非键列包含在索引中时,带有包含性非键列的索引可以显著提高查询性能.这样可以实现性能提升,因为查询优化器可以在索引中找到所有列值:不访问表或聚集索引数据,从而减少磁盘 I/O 操作. 注意:

[转帖]SQL Server 索引中include的魅力(具有包含性列的索引)

SQL Server 索引中include的魅力(具有包含性列的索引) http://www.cnblogs.com/gaizai/archive/2010/01/11/1644358.html 上个月刚发现sql2016 之前仅支持 索引包含 16个键 (之后支持32个键) 这个月发现 可以 使用include 的方式来处理. 开文之前首先要讲讲几个概念 [覆盖查询] 当索引包含查询引用的所有列时,它通常称为“覆盖查询”. [索引覆盖] 如果返回的数据列就包含于索引的键值中,或者包含于索引的键

选择列表中的列……无效,因为该列没有包含在聚合函数或 GROUP BY 子句中

今天用SQL Server尝试实现一个SQL语句的时候,报了如标题所示的错误,通过在百度里面搜索,并亲自动手实现,终于发现问题所在,现在把它记录下来. 语句如下: select [OrderID],[ProductID], min(UnitPrice) as MinUnitPrice into NewDetails FROM [Northwind].[dbo].[Order Details] Group by [OrderID] 执行该语句之后,SQL Server报错如下: "消息 8120,

选择列表中的列无效,因为该列没有包含在聚合函数或 GROUP BY 子句中

T-SQL核心语句形式: SELECT     --指定要选择的列或行及其限定  [INTO ]      --INTO子句,指定结果存入新表 FROM      --FROM子句,指定表或视图 [WHERE ]                 --WHERE子句,指定查询条件 [GROUP BY ]           --GROUP BY子句,指定分组表达式 [HAVING ]                --HAVING子句,指定分组统计条件 [ORDER BY [ASC|DESC]] 

数据库SQL查找包含某列的所有table

--声明必要变量DECLARE @tablename NVARCHAR(80),@columnname NVARCHAR(20),@sql NVARCHAR(2000),@sql2 NVARCHAR(2000),@sql3 NVARCHAR(2000),@CName NVARCHAR(20)SET @CName='RegionCode'--游标DECLARE cur CURSOR FOR--1.查找包含某列的tableSELECT '['+TABLE_SCHEMA+'].['+TABLE_NAM

索引键的唯一性(4/4):非唯一聚集索引上的唯一和非唯一非聚集索引

在上一篇文章里,我谈了唯一聚集索引上的唯一和非唯一非聚集索引的区别.在这篇文章里,我想谈下非唯一聚集索引上的唯一和非唯一聚集索引的区别.我们都知道,SQL Server内部把非唯一聚集索引当作唯一聚集索引处理的.如果你定义了一个非唯一聚集索引,SQL Server会增加叫做uniquifier到你的索引记录,它导致你聚集索引的导航结构(B树的非叶子层)里,每条索引行都要用到4 bytes的开销. 下列代码再次创建我们的Customers表,这次在它上面定义非唯一聚集索引,最后定义2个非聚集索引,

第十二章——SQLServer统计信息(2)——非索引键上统计信息的影响

原文:第十二章--SQLServer统计信息(2)--非索引键上统计信息的影响 前言: 索引对性能方面总是扮演着一个重要的角色,实际上,查询优化器首先检查谓词上的统计信息,然后才决定用什么索引.一般情况下,默认会在创建索引时,索引列上均创建统计信息.但是不代表在非索引键上的统计信息对性能没有用. 如果表上的所有列都有索引,那么将会是数据库负担不起,同时也不是一个好想法,包括谓词中用到的所有列加索引同样也不是好方法.因为索引会带来负载.因为需要空间存放索引,且每个DML语句都会需要更新索引. 一般

从性能的角度谈SQL Server聚集索引键的选择

简介 在SQL Server中,数据是按页进行存放的.而为表加上聚集索引后,SQL Server对于数据的查找就是按照聚集索引的列作为关键字进行了.因此对于聚集索引的选择对性能的影响就变得十分重要了.本文从旨在从性能的角度来谈聚集索引的选择,但这仅仅是从性能方面考虑.对于有特殊业务要求的表,则需要按实际情况进行选择. 聚集索引所在的列或列的组合最好是唯一的 这个原因需要从数据的存放原理来谈.在SQL Server中,数据的存放方式并不是以行(Row)为单位,而是以页为单位.因此,在查找数据时,S

数据(连接查询、纵向联合、索引/键、CHECK约束)

-----连接查询----- ---纵向联合--- 索引/键 添加-列-确定 CHECK约束:规定他范围,不能超过范围 stable表-设计-cid右键-CHECK约束-添加-表达式后面的省略号 - 设置为年龄大于0,小于150,超过设置范围语句与约束冲突终止