Varchar上的索引？

Question

我们在生产中遇到了一些沉重的表锁定问题。我注意到我创建了一个存储过程，它按订单号获取订单列表。订单号是VARCHAR（150）。此列上没有任何类型的索引。

目前，此列中有很多NULL值。但是，随着时间的推移（该表最近上线），该表将显着增长。此时不会再添加NULL值。

我的问题有两个问题。首先，指数在这里是否有益。 proc被大量使用。如果是这样，它应该聚集在一起吗？数据类似于CP123456，DR126512。

第二个问题，可能影响第一个问题是 - 将列更改为CHAR（10）是有益的，因为它似乎'订单号始终是相同的大小。将索引放在固定长度CHAR上是否有任何速度优势，而不是VARCHAR（150）？

（大小不同是因为创建列时未知的要求）。

SQL Server 2008。

Answer 1

1. 是的，绝对！继续前进并添加索引。这里可能不需要对索引进行聚类，如果您已经在表上有另一个聚簇索引（例如主键），则无法进行聚类。

2. 将列更改为CHAR(10)可能会在存储大小方面带来一些好处，但它不太可能在索引性能方面产生特别大的差异。我暂时不会跳过它。

Answer 2

我没有引用这个，只有经验/轶事证据。

首先，通过使用索引几乎总能改进查询。确切的好处取决于查询 - 如果查询只需要特定记录/表的一小部分，索引将有助于 - 如果查询需要整个表，但可以从有序数据中受益，则索引将有所帮助

群集索引通常比非群集索引提供性能优势。在非常简单的意义上，使用非聚集索引就像使用两个表并加入它们一样（首先使用搜索友好索引，然后将其连接到数据本身 - 除非索引包含您需要的所有数据字段）。

但是，此处的考虑因素是数据添加到表中的顺序。如果您的聚簇索引意味着经常在表的中间插入或删除数据，那么您将获得碎片和其他伪像。然而，根据我的经验，只有在极端情况下才需要对此有所认识和考虑。

简而言之，绝对是您数据的索引。而聚集索引通常最适合为性能最差的查询提供服务。

至于VARCHAR和CHAR之间的区别？在过去，重要的是在数据末尾保留可变长度字段，以便更容易识别固定长度字段。这意味着将VARCHAR字段作为第一个字段并将其用作唯一标识符非常差。

如今，性能差异很小。就个人而言，我仍然将唯一标识符保留为固定长度。可变长度数据通常不会有明显的性能成本，但是当您实际进行连接谓词等的比较时，如果可能的话，使用固定长度字段会更加整洁。