3.2w+
社区成员
- 主页
- 基础类
- 应用实例
- 新技术前沿
关于非聚集索引的问题，有经验的都来看一下
我在8月份的时候对表A的字段B建了一个非聚集索引，结果这之前基于字段B的查询操作（分组求和）就快了很多。但是现在对8月份以后插入的数据进行相同的查询速度还是很慢，我把索引删了又重新建了一下，速度变快了。难道建的索引只对当前数据有效？有人能分析一下并指导一下该怎么做才好吗，总不能每次都删了索引再建。
...全文
当前发帖距今超过3年，不再开放新的回复
发表回复
w2jc 2007-12-05
但是在数据量不大的情况下每个月都要维护倒是没想到。
-------------------------------------------
根据你的表结构和索引的不同情况，有时候数据量不大也会造成索引碎片，
懒（或者容易）一点的办法就是定期重建索引（不要自己手工删除），比如建一个维护计划定期运行，每2周，每周...
如果数据量太大，更新频繁，可参考5楼给的命令，用dbcc showcontig 来确定碎片很多的索引，
然后只对这个索引进行重建操作。
-------------------------------------------
根据你的表结构和索引的不同情况，有时候数据量不大也会造成索引碎片，
懒（或者容易）一点的办法就是定期重建索引（不要自己手工删除），比如建一个维护计划定期运行，每2周，每周...
如果数据量太大，更新频繁，可参考5楼给的命令，用dbcc showcontig 来确定碎片很多的索引，
然后只对这个索引进行重建操作。
w2jc 2007-12-04
每条数据也就几十个字段
-------------------------
这种字段很多的表比较容易造成碎片。
LZ这种情况多半是索引有碎片，或者统计信息没有更新
DBCC DBREINDEX
( 'table_name' [ , 'index_name' [ , fillfactor ] ] )
在SQL 2000里面使用上面的命令去重建你的索引，看联机文档跟详细；
从SQL 2005开始 DBCC DBREINDEX 将被ALTER INDEX取代；
DBCC DBREINDEX 的另外一个好处是可以更新相关的统计信息。
-------------------------
这种字段很多的表比较容易造成碎片。
LZ这种情况多半是索引有碎片，或者统计信息没有更新
DBCC DBREINDEX
( 'table_name' [ , 'index_name' [ , fillfactor ] ] )
在SQL 2000里面使用上面的命令去重建你的索引，看联机文档跟详细；
从SQL 2005开始 DBCC DBREINDEX 将被ALTER INDEX取代；
DBCC DBREINDEX 的另外一个好处是可以更新相关的统计信息。
rouqu 2007-12-04
大致原理
======
非聚集索引与聚集索引的一个本质区别 B*树底部没有数据页 默认索引填充因子0% 是极不饱和状态
你后来插入的数据会在B*树下继续填充现有或添加额外索引页 但不维护索引顺序和数据页针对索引列的物理排序 针对索引列的query会去按照算法搜索或遍历索引页 对于大表可想而知 性能会有提升
如果你的表总数据不到1W条 其实也没必要用索引了 直接扫描表说不定更快
======
非聚集索引与聚集索引的一个本质区别 B*树底部没有数据页 默认索引填充因子0% 是极不饱和状态
你后来插入的数据会在B*树下继续填充现有或添加额外索引页 但不维护索引顺序和数据页针对索引列的物理排序 针对索引列的query会去按照算法搜索或遍历索引页 对于大表可想而知 性能会有提升
如果你的表总数据不到1W条 其实也没必要用索引了 直接扫描表说不定更快
qiashzhou 2007-12-04
说错了，8月份以后一共插入几千条数据
orochi_gao 2007-12-04
帮顶,关注学习!
qiashzhou 2007-12-04
MS SQL 2005里面怎么扫描索引碎片呢？
从8月份新建索引以来一共才插入800多条数据，而且每条数据也就几十个字段，基本没有删除更新操作，怎么就会出这种问题了呢？
从8月份新建索引以来一共才插入800多条数据，而且每条数据也就几十个字段，基本没有删除更新操作，怎么就会出这种问题了呢？
ivyrich 2007-12-04
DBCC SHOWCONTIG 可确定表是否高度碎片化。在对表进行数据修改（INSERT、UPDATE 和 DELETE 语句）的过程中会出现表碎片现象。由于这些修改通常并不在表的行中平均分布，所以每页的填满状态会随时间而改变。
如果索引的碎片非常多，可选择以下方法来减少碎片：
删除然后重新创建聚集索引。
重新创建聚集索引将重新组织数据，从而使数据页填满。填满程度可以使用 CREATE INDEX 中的 FILLFACTOR 选项进行配置。这种方法的缺点是索引在删除/重新创建周期内为脱机状态，并且该操作是一个整体，不可中断。如果中断索引创建，则不能重新创建索引。
对索引的叶级页按逻辑顺序重新排序。
使用 ALTER INDEX…REORGANIZE，对索引的页级页按逻辑顺序重新排序。由于此操作是联机操作，因此语句运行时索引可用。此外，中断该操作不会丢失已完成的工作。这种方法的缺点是在重新组织数据方面没有聚集索引的删除/重新创建操作有效。
联机重新生成索引。
如果索引的碎片非常多，可选择以下方法来减少碎片：
删除然后重新创建聚集索引。
重新创建聚集索引将重新组织数据，从而使数据页填满。填满程度可以使用 CREATE INDEX 中的 FILLFACTOR 选项进行配置。这种方法的缺点是索引在删除/重新创建周期内为脱机状态，并且该操作是一个整体，不可中断。如果中断索引创建，则不能重新创建索引。
对索引的叶级页按逻辑顺序重新排序。
使用 ALTER INDEX…REORGANIZE，对索引的页级页按逻辑顺序重新排序。由于此操作是联机操作，因此语句运行时索引可用。此外，中断该操作不会丢失已完成的工作。这种方法的缺点是在重新组织数据方面没有聚集索引的删除/重新创建操作有效。
联机重新生成索引。
areswang 2007-12-04
依LZ意思看是索引不起作用了，再建之后又重新起作用。难道会有冲突。学习！
ivyrich 2007-12-04
建议扫描一下索引碎片
fa_ge 2007-12-04
对所有记录有效
hui_hui_2007 2007-12-04
应该不会的，索引都是引对所有记录的。
是不是有别的因素呀。
是不是有别的因素呀。
qiashzhou 2007-12-04
楼上的说我对索引不了解，这个确实是事实，我也是因为刚开始查询觉得速度比较慢，建了一个索引就快多了。
索引需要维护我倒也知道一点，但是在数据量不大的情况下每个月都要维护倒是没想到。
索引需要维护我倒也知道一点，但是在数据量不大的情况下每个月都要维护倒是没想到。
中国风 2007-12-04
索引的重建和整理:
http://topic.csdn.net/u/20070329/17/38398e78-adac-4d7e-a8b6-f2d319d283e8.html
http://topic.csdn.net/u/20070329/17/38398e78-adac-4d7e-a8b6-f2d319d283e8.html
wzy_love_sly 2007-12-04
学习，支持w2jc一下
hb_gx 2007-12-04
LZ 看来对索引不是很了解，索引不是建了以后就不用去管的，索引是需要经常去维护的，知道为什么维护计划里面会有重新组织和重新生成索引吗？删除重建就相当于是在重新生成索引
既然用Sql2005就看看这个动态管理函数 sys.dm_db_index_physical_stats 好了，或者是联机帮助上的 重新组织和重新生成索引 ，学习一下自己理解理解比较好
既然用Sql2005就看看这个动态管理函数 sys.dm_db_index_physical_stats 好了，或者是联机帮助上的 重新组织和重新生成索引 ，学习一下自己理解理解比较好
