使用非聚集和聚簇索引，但对sql中的时间执行没有影响 [英] using non clustered and clustered index but no effect on time execution in sql

问题描述

我有一个包含30000行的表，我用这个表的数据复制。



i在主键列上有一个聚簇索引和三个这个表上的其他索引



当我执行任何关于这些索引列的查询时..i在执行时没有看到任何改进。我已经尝试了很多查询...两个表（有和没有具有相同数据的索引）所用的时间是相同的。 （我尝试使用执行计划也花时间）



任何人都可以建议问题是什么......如何使用它们？

i have a table with 30000 rows in it , and i make an copy with data of this table .

i have one clustered index on primary key column and three other indexes on this table

when i am execut any query on theses indexed column behalf ..i have seen no improvement on time of execution . i have tried many query ... time taken for both table (with and without indexs with same data) are same . (i tried using execution plan for time taken also)

Can any one suggest what s the problem ...how to use them ?

推荐答案

一些提示...



你应该在你用于WHERE子句的列上应用索引

如果你正在使用连接，那么确保索引应用于该表的列'太多



检查执行计划如果有更多数据的表不应该扫描它应该寻找



不要在选择列表中包含不必要的列



快乐编码！

：）

some tips...

you should apply index on column which you are using for WHERE clause
and if you are using joins then make sure index is applied to that table's columns' too

check execution plan if table with more data should not be scan it should be seek

Do not include unnecessary columns in select list

Happy Coding!
:)

如果你有二级索引，聚集索引通常是一个坏主意，因为二级索引不能指向对于堆中的ROWID，它们必须指向聚簇索引。

这意味着对于它在二级索引中扫描的每一行，它需要在聚簇索引中进行索引搜索，使其成为效率低下母鸡查询许多行。

A clustered index is normally a bad idea if you have secondary indexes, because the secondary indexes cannot point to ROWIDs in the heap, they have to point to the clustered index.
This means that for EVERY row it scans in the secondary index, it needs to make an index seek in the clustered index, making it inefficient when querying many rows.

如果您的数据经常被删除或更改，聚集索引是一个坏主意。

A clustered index is a BAD idea if your data is often deleted or changed.

这篇关于使用非聚集和聚簇索引，但对sql中的时间执行没有影响的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！