mssql 建立索引第1/2页

表的索引与附在一本书后面的索引非常相似。它可以极大地提高查询的速度。对一个较大的表来说,通过加索引,一个通常要花费几个小时来完成的查询只要几分钟就可以完成。因此没有理由对需要频繁查询的表增加索引。

注意:
当你的内存容量或硬盘空间不足时,也许你不想给一个表增加索引。对于包含索引的数据库,SQL Sever需要一个可观的额外空间。例如,要建立一个聚簇索引,需要大约1.2倍于数据大小的空间。要看一看一个表的索引在数据库中所占的空间大小,你可以使用系统存储过程sp_spaceused,对象名指定为被索引的表名。

聚簇索引和非聚簇索引
假设你已经通过本书的索引找到了一个句子所在的页码。一旦已经知道了页码后,你很可能漫无目的翻寻这本书,直至找到正确的页码。通过随机的翻寻,你最终可以到达正确的页码。但是,有一种找到页码的更有效的方法。

首先,把书翻到大概一半的地方,如果要找的页码比半本书处的页码小,就书翻到四分之一处,否则,就把书翻到四分之三的地方。通过这种方法,你可以继续把书分成更小的部分,直至找到正确的页码附近。这是找到书页的非常有效的一种方法。

SQL Sever的表索引以类似的方式工作。一个表索引由一组页组成,这些页构成了一个树形结构。根页通过指向另外两个页,把一个表的记录从逻辑上分成和两个部分。而根页所指向的两个页又分别把记录分割成更小的部分。每个页都把记录分成更小的分割,直至到达叶级页。

索引有两种类型:聚簇索引和非聚簇索引。在聚簇索引中,索引树的叶级页包含实际的数据:记录的索引顺序与物理顺序相同。在非聚簇索引中,叶级页指向表中的记录:记录的物理顺序与逻辑顺序没有必然的联系。

聚簇索引非常象目录表,目录表的顺序与实际的页码顺序是一致的。非聚簇索引则更象书的标准索引表,索引表中的顺序通常与实际的页码顺序是不一致的。一本书也许有多个索引。例如,它也许同时有主题索引和作者索引。同样,一个表可以有多个非聚簇索引。

通常情况下,你使用的是聚簇索引,但是你应该对两种类型索引的优缺点都有所理解。

每个表只能有一个聚簇索引,因为一个表中的记录只能以一种物理顺序存放。通常你要对一个表按照标识字段建立聚簇索引。但是,你也可以对其它类型的字段建立聚簇索引,如字符型,数值型和日期时间型字段。

从建立了聚簇索引的表中取出数据要比建立了非聚簇索引的表快。当你需要取出一定范围内的数据时,用聚簇索引也比用非聚簇索引好。例如,假设你用一个表来记录访问者在你网点上的活动。如果你想取出在一定时间段内的登录信息,你应该对这个表的DATETIME型字段建立聚簇索引。

对聚簇索引的主要限制是每个表只能建立一个聚簇索引。但是,一个表可以有不止一个非聚簇索引。实际上,对每个表你最多可以建立249个非聚簇索引。你也可以对一个表同时建立聚簇索引和非聚簇索引。

假如你不仅想根据日期,而且想根据用户名从你的网点活动日志中取数据。在这种情况下,同时建立一个聚簇索引和非聚簇索引是有效的。你可以对日期时间字段建立聚簇索引,对用户名字段建立非聚簇索引。如果你发现你需要更多的索引方式,你可以增加更多的非聚簇索引。

非聚簇索引需要大量的硬盘空间和内存。另外,虽然非聚簇索引可以提高从表中取数据的速度,它也会降低向表中插入和更新数据的速度。每当你改变了一个建立了非聚簇索引的表中的数据时,必须同时更新索引。因此你对一个表建立非聚簇索引时要慎重考虑。如果你预计一个表需要频繁地更新数据,那么不要对它建立太多非聚簇索引。另外,如果硬盘和内存空间有限,也应该限制使用非聚簇索引的数量。

索引属性
这两种类型的索引都有两个重要属性:你可以用两者中任一种类型同时对多个字段建立索引(复合索引);两种类型的索引都可以指定为唯一索引。

你可以对多个字段建立一个复合索引,甚至是复合的聚簇索引。假如有一个表记录了你的网点访问者的姓和名字。如果你希望根据完整姓名从表中取数据,你需要建立一个同时对姓字段和名字字段进行的索引。这和分别对两个字段建立单独的索引是不同的。当你希望同时对不止一个字段进行查询时,你应该建立一个对多个字段的索引。如果你希望对各个字段进行分别查询,你应该对各字段建立独立的索引。

两种类型的索引都可以被指定为唯一索引。如果对一个字段建立了唯一索引,你将不能向这个字段输入重复的值。一个标识字段会自动成为唯一值字段,但你也可以对其它类型的字段建立唯一索引。假设你用一个表来保存你的网点的用户密码,你当然不希望两个用户有相同的密码。通过强制一个字段成为唯一值字段,你可以防止这种情况的发生。

当前1/2页 12下一页阅读全文

(0)

相关推荐

  • MSSQL自动重建出现碎片的索引的方法分享

    1.索引碎片的产生? 由于在表里大量的插入.修改.删除操作而使索引页分裂.如果索引有了高的碎片,有两种情况,一种情况是扫描索引需要花费很多的时间,另一种情况是在查询的时候索引根本不使用索引,都会导致性能降低. 2.碎片类型分为: 2.1 内部破碎 由于索引页里的数据插入或修改操作而发生,以数据作为稀疏矩阵的形式的分布而结束,这将导致数据页的增加,从而增加查询时间. 2.2外部破碎 由于索引/数据页的数据插入或修改而发生,以页码分离和在文件系统里不连贯的新的索引页的分配而结束,数据库服务器不能利用

  • SQL2005CLR函数扩展 - 关于山寨索引

    本文只是一个山寨试验品,思路仅供参考. --------------------------------------------------------------------------------原理介绍:索引建立 目录结构划分方案也只是很简易的实现了一下,通过unicode把任意连续的两个字符(中文或英文)分为4个字节来做四层目录,把索引的内容对应的主关键字(主要为了使用sql索引和唯一性)作为文件名,两个字符在索引内容中的位置作为文件后缀来存储.文件本身为0字节,不保存任何信息. 比如一

  • MSSQL 大量数据时,建立索引或添加字段后保存更改提示超时的解决方法

    一般我们都喜欢用数据库管理器的UI来对数据表结构进行更改,然后自然而然地点"保存" 按钮进行保存,但数据量比较大的时候,用这招往往会出现"无法创建索引"IX_索引名". 超时时间已到.在操作完成之前超时时间已过或服务器未响应. "这种错误.一时不知所措,蜡人张的文章 复制代码 代码如下: 修改表属性后使用"索引/键"对话框为一个大型表(记录数13,239,473)创建索引,提示: - 无法创建索引"IX_TableN

  • 理解Sql Server中的聚集索引

    说到聚集索引,我想每个码农都明白,但是也有很多像我这样的猥程序员,只能用死记硬背来解决这个问题,什么表中只能建一个聚集索引,然后又扯到了目录查找来帮助读者记忆....问题就在这里,我们不是学文科,,,不需要去死记硬背,,,我们需要的就是能看到在眼里面的真实东西.....我们都喜欢聚集索引,因为它能够把无序的堆表记录变成有序,还玩起了B树...这样就把复杂度从N降低到了LogMN... 这样的话逻辑读,物理读就下来了.  一:现象 1:无索引的情况 还是老规矩,看个例子感受下,首先我有一个Prod

  • 在SQL SERVER中导致索引查找变成索引扫描的问题分析

    SQL Server 中什么情况会导致其执行计划从索引查找(Index Seek)变成索引扫描(Index Scan)呢? 下面从几个方面结合上下文具体场景做了下测试.总结.归纳. 1:隐式转换会导致执行计划从索引查找(Index Seek)变为索引扫描(Index Scan) Implicit Conversion will cause index scan instead of index seek. While implicit conversions occur in SQL Serve

  • SQL2005重新生成索引的的存储过程 sp_rebuild_index 原创

    公司运营着的网站,流量很大,网站是交互式的,经常在过了三四个月的时候索引生成的碎片就很多,由于很大一部分页面没有生成静态,这就导致网站在打开的速度上会变慢. 以前都是手工右击索引重新生成,但是索引太多,操作起来费时费力,索引在网上找了个存储过程,自己整理了一下,执行的时候只需要选择相应的数据库,运行exec sp_rebuild_index即可,如下. USE [master] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE

  • 详解sqlserver查询表索引

    SELECT   索引名称=a.name ,表名=c.name ,索引字段名=d.name ,索引字段位置=d.colid FROM sysindexes a JOIN sysindexkeys b ON a.id=b.id AND a.indid=b.indid JOIN sysobjects c ON b.id=c.id JOIN syscolumns d ON b.id=d.id AND b.colid=d.colid WHERE a.indid NOT IN(0,255) -- and

  • Sql Server中的非聚集索引详细介

    非聚集索引,这个是大家都非常熟悉的一个东西,有时候我们由于业务原因,sql写的非常复杂,需要join很多张表,然后就泪流满面了...这时候就有DBA或者资深的开发给你看这个猥琐的sql,通过执行计划一分析...或许就看出了不该有的表扫描...万恶之源...然后给你在关键的字段加上非聚集索引后...才发现提速比阿斯顿马丁还要快...那么一个问题来了,为什么非聚集索引能提速这么快...怎么做到的???是不是非常的好奇??? 这篇我们来解开神秘面纱.  一:现象 先让我们一睹非聚集索引的真容,看看到底

  • SQL2000 全文索引完全图解

    全文检索可以对varchar,text,image型字段进行检索,但一个表最多只能建一个全文索引SQL Server 2000 引入了对存储在 image 列中的这些类型的数据执行全文检索的能力.如果没有全文索引,对字符的模糊查询只能对基表进行全表扫描(或索引扫描),执行模糊查询都需要对全表扫描或索引扫描意味着消耗大量IO.如果模糊查询经常发生,会造成数据库性能恶化.本篇为简单起见,仅在varchar型字段上图文演示非常完整的而且是高效可行的全文索引创建及维护过程.1:在企业管理器中展开要建立全

  • 关于重新组织和重新生成索引sp_RefreshIndex的介绍

    开始: -------------------------------------------------------------------------------- 在上周,客户反映一个系统问题,当处理大量数据的时候,出现网络超时.后来,我们跟踪测试,发现是由于索引碎片多而引起的网络超时. 解决方法,自然是重新组织和重新生成索引.在这里,我写了一个存储过程sp_RefreshIndex来实现. 存储过程sp_RefreshIndex: 复制代码 代码如下: use mastergoif ob

随机推荐