问guid主键创建用于最快的查询select where guid in ( guid1，guid2，guid3 ...)

EN

使用GUID作为聚集索引的事实肯定会对您的性能产生负面影响。即使使用NEWSEQUENTIALGUID，GUID也不是真正顺序的-它们只是部分顺序。它们的随机性必然会导致更高的索引碎片，从而导致不太理想的搜索时间。

此外，如果您有一个16字节的GUID作为您的聚集键，它将被添加到该表的任何非聚集索引中。这听起来可能不是那么糟糕，但如果你有10mio。使用16字节的GUID与4字节的INT相比，使用16字节的GUID和4字节的INT将浪费1.2GUID的存储-不仅是在磁盘上(这很便宜)，而且还会浪费在您的SQL server的内存中(因为SQL server总是将整个8k页加载到8k的内存块中，无论它们是满的还是空的)。

我可以理解使用GUID作为主键的意义--它们几乎100%保证是唯一的，这对开发人员很有吸引力。但是:作为聚集键，它们对您的数据库来说是一个噩梦。

我的最佳实践:如果我真的需要一个GUID作为主键，我将一个4字节的INT标识添加到表中，然后将其作为聚集键-这样结果会更好！

如果您有一个非集群化主键，那么使用GUID列表的查询速度将与使用集群化主键的查询速度一样快，并且通过不使用集群键的GUID，您的表最终会表现得更好。

在Kimberly Tripps的博客-索引女王中阅读更多关于簇关键字的内容，以及为什么选择正确的关键字是如此重要，并且可以比我更好地解释事情：

• GUIDs as PRIMARY KEY and/or clustered key
• The clustered index debate continues
• Ever-increasing clustering key - the Clustered Index Debate..........again!

Marc

除了GUID不好(来自marc_s的回答)之外，还有一个IN子句。这可以归结为：

productid = guid1 OR productid = guid2 OR ... OR productid = guidn

...in实践，这也不是最优的。

通常，对于自然键列上的聚集索引，natural_key like 'Something%'可能更好。

聚集索引最适合范围搜索，因此它可能满足您的查询：

productid in ( guid1 , guid2 ,..., guidn )

但如果索引是覆盖索引，则取决于您正在选择的其他内容、分组依据、排序依据等。否则，优化器可能会选择另一个非聚集索引，然后查找该聚集索引。在某种程度上，它还取决于该表中的行数。

此外，我认为您可能希望使用NEWID()，而不是NEWSEQUENTIALID()