像GUID这种数据类型，建成什么索引在查询的时候会提高效率？

[fattycat]

我的表中有一列是GUID类型，都是随机生成的，例如：

1b97b637-b276-4dd1-80fd-62eb2d538bc6

现在我经常需要写SQL语句进行select，查询条件就是某一个数据条目的GUID，例如：

select * from TableName where GUID='1b97b637-b276-4dd1-80fd-62eb2d538bc6'

我想对GUID列建立一个索引，不知道对这种没有任何规律的类型，采用聚集索引还是非聚集索引呢？

或者建立索引与否对查询效率影响不大呢？

请大家指点！

谢谢

^o^

[mschen]

没有必要建立聚集索引,建立非聚集索引就可以了.聚集索引对于范围查询是非常有效的,唯一的一条记录的查询使用非聚集索引就可以了.

[fattycat]

那如果我在表中很多数据行都拥有相同的GUID呢？例如：

select Col1 from TableName where GUID='1b97b637-b276-4dd1-80fd-62eb2d538bc6'

返回的10条相同GUID的数据行，是否要使用聚集索引呢？


谢谢 ^o^

[jobs002]

如果很多的行相同，建议不要建立索引.

[fattycat]

不是很多相同的，在2万条数据的表中，大概有10条的GUID是相同的，是否应该建立索引呢？建立聚集索引还是非聚集索引呢？

[fattycat]

upup

[yesyesyes]

GUID类型数据不应该有重复的吧

[fattycat]

哦，我是在程序中生成的GUID类型的值，然后插入到数据库中的，同一个GUID可能有很多条记录

[wangdehao]

有重复的是没办法建立聚集索引的,聚集索引是唯一的

[fattycat]

那你的意思是说，对于没有重复值的列，做聚集索引的效率是最高的？


我昨晚做了一个索引的试验，SQL2005，在有5万条数据的表中，根据ID列的某一个值（ID值随机且没有重复，不是自增长），返回一条唯一的数据

首先，我没有在表中建立任何索引或主键，上边的查询操作执行了Table Scan，且SubtreeCost值为 1.26487

然后，我在ID列上建立了Clustered Index，上边的查询操作执行了Clustered Index Scan，且Subtree Cost值为 1.24784

最后，我在ID列上建立了NonClustered Index，上边的查询执行了分步操作，先在索引表中取出了地址，然后到表中定位到具体数据条目，Subtree Cost值为 0.248621

这是否就说明了，对一张较大的表取一条数据的效率：
NonClustered > Clustered > Table Scan ？？？？？？


我查看一个命令的执行效率最有说服力的是什么数据呢？是Subtree cost，还是CPU Cost，还是I/O Cost呢？


请指点~~谢谢 ^o^

[wangdehao]

上面mschen(Co-ok)已经说了, 聚集索引对于范围查询是最有效的

[wangdehao]

对一张较大的表取一条数据的效率：
NonClustered > Clustered > Table Scan
---------------
可以这样认为,有一个关于索引讨论的帖子,http://community.csdn.net/Expert/topic/4430/4430562.xml?temp=.1002619
可以看一下,可惜现在打不开了 :(

[fattycat]

你说的是这个么？

http://topic.csdn.net/t/20051201/11/4430562.html#Top

呵呵

[fattycat]

刚才我又做了一个测试，在有100万条数据的表中，其中ID列是按顺序自增长的

我执行了select aaaa from table1 where id=99999

结果如下：

无索引时：
执行Table Scan，Subtree Cost为 5.79143

有Clustered Index时：
执行Clustered Index Seek，Subtree Cost为 0.0032831

有NonClustered Index时：
执行分布式查询，先在索引表中取出了地址，然后到表中定位到具体数据条目
Subtree Cost为 0.0065704


这是否又说明了，在一张大表中，如果根据一个按顺序自增长的ID列进行搜索，效率情况：

对ID列做Clustered Index > 对ID列做NonClustered Index > 无Index ？？？？？？


跟上次的试验结果不一样，是否是因为ID列是自增长的，并且经过Clustered Index按顺序进行物理排序了呢？

[suntt]

若经常的insert，guid的索引由于没有良好的排序性，所以能够引起大量的分页。
索引的效率会降低