Sql Varchar上的索引？

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

目前，此列中有许多空值。但是，随着时间的推移（该表最近上线），该表将显著增长。这次将不再添加任何空值

我的问题有两个方面。首先，指数在这里是否有益。这个过程被大量使用。如果是这样，它是否应该集群化？数据是CP123456、DR126512之类的东西

第二个问题，可能会影响第一个问题-将列更改为CHAR（10）是否有益，因为“看起来”订单号总是相同的大小。与VARCHAR（150）相比，将索引放在固定长度的CHAR上有什么速度优势吗

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

SQL Server 2008

是的，绝对是！继续添加索引。在这里，聚集索引可能是不必要的，如果表上已经有另一个聚集索引（例如主键），那么无论如何也不可能

将列更改为

CHAR（10）

在存储大小方面可能会有一些好处，但不太可能在索引性能方面产生特别大的差异。我现在不想说了

---

关于这一点，我没有参考文献，只有经验/轶事证据

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

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

然而，这里需要考虑的是数据添加到表中的顺序。如果聚集索引意味着数据经常在表的中间插入或删除，则会出现碎片和其他人工制品。然而，根据我的经验，只有在极端情况下才需要意识到并考虑到这一点

简而言之，一定要为数据编制索引。而聚集索引通常最适合为性能最差的查询提供服务

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

---

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

在ms sql server中当然可以使用非群集主键。