我们在生产中遇到了一些严重的表锁定问题。我注意到我创建了一个存储过程，它按订单号获取订单列表。订单号是 VARCHAR(150)。此列上没有任何类型的索引。
目前，此列中有很多 NULL 值。但是，随着时间的推移（此表最近上线），该表将显着增长。这次不会再添加 NULL 值了。
我的问题有两个。首先，索引在这里是否有益。 proc被大量使用。如果是这样，它是否应该集群？数据是 CP123456、DR126512 之类的东西。
可能会影响第一个问题的第二个问题是 - 将列更改为 CHAR(10) 是否有益，因为订单号“似乎”总是相同的大小。与 VARCHAR(150) 相比，将索引放在固定长度的 CHAR 上是否有任何速度优势？
（大小不同是因为创建列时需求未知）。
SQL Server 2008。
【问题讨论】：
标签： sql performance sql-server-2008
是的，绝对是！继续并添加索引。此处可能不需要对索引进行聚簇，如果表上已有另一个聚簇索引（例如主键），则无论如何也不可能。
将列更改为CHAR(10) 可能在存储大小方面有一些好处，但不太可能对索引性能产生特别大的影响。我暂时跳过它。
【讨论】：
对此我没有可引用的参考资料，只有经验/轶事证据。
首先，几乎总是可以通过使用索引来改进查询。确切的好处取决于查询。
- 如果查询只需要特定记录/表的一小部分，索引会有所帮助
- 如果查询需要整个表，但可以从有序数据中受益，索引会有所帮助
聚簇索引通常比非聚簇索引提供性能优势。在非常简化的意义上，使用非聚集索引就像使用两个表并将它们连接起来（首先使用搜索友好索引，然后将其连接到数据本身 - 除非索引包含您需要的所有数据字段）。
然而，这里需要考虑的是数据添加到表中的顺序。如果您的聚集索引意味着经常在表的中间插入或删除数据，您将获得碎片和其他伪像。然而，根据我的经验，只有在极端情况下才需要意识到和考虑这一点。
简而言之，一定要为您的数据编制索引。聚集索引通常最适合处理性能最差的查询。
至于VARCHAR和CHAR的区别？在过去，重要的是在数据末尾保留可变长度字段，以使固定长度字段更容易识别。这意味着将 VARCHAR 字段作为您的第一个字段并将其用作唯一标识符非常糟糕。
如今，性能差异微乎其微。就个人而言，我仍然会将唯一标识符保持为固定长度。可变长度数据通常不会产生明显的性能成本，但是当您实际对连接谓词等进行比较时，如果可能，使用固定长度字段会更整洁。
【讨论】：