我有一个包含 50 万行的表。
主键是 guid 列。
我发现查询 select * from T where id ='xxxx' 非常慢。
我应该怎样做才能提高性能？
最佳答案
如果可以的话，我会推荐以下内容:
删除现有主键 - 特别是如果它也是集群键(默认情况下也是如此)
添加新的
INT IDENTITY列ALTER TABLE dbo.YourTable ADD NewID INT IDENTITY(1,1)将该 INT 字段设为主键/集群键:
ALTER TABLE dbo.YourTable ADD CONSTRAINT PK_YourTable PRIMARY KEY(NewID)
GUID 列上的主键(或更准确地说:聚集键)是一个可怕的想法，会导致大量索引碎片，从而降低 SELECT 性能。
如Kimberly Tripp - 索引女王 - 和其他人已经说过很多次 - GUID 作为集群键并不是最佳的，因为由于它的随机性，它将导致大量页面和索引碎片以及通常较差的性能。
是的，我知道 - SQL Server 2005 及更高版本中有 newsequentialid() - 但即便如此，它也不是真正且完全顺序的，因此也会遇到与 GUID 相同的问题 - 只是有一点点不太明显。
然后还有另一个问题需要考虑:表上的聚集键也将添加到表上每个非聚集索引的每个条目中 - 因此您确实希望确保它尽可能小。通常，具有 2+ 十亿行的 INT 对于绝大多数表来说应该足够了 - 与作为集群键的 GUID 相比，您可以在磁盘和服务器内存中节省数百兆字节的存储空间。
快速计算 - 使用 INT 与 GUID 作为主键和聚类键:
- 具有 1'000'000 行的基表(3.8 MB 与 15.26 MB)
- 6 个非聚集索引(22.89 MB 与 91.55 MB)
总计:25 MB 与 106 MB - 而且这只是在一个表上!
还有一些值得深思的东西 - Kimberly Tripp 写的很棒的东西 - 读它，再读它，消化它!这确实是 SQL Server 索引福音。
关于sql - 如果我在 guid 列上使用主键，如何提高性能？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5699478/