代码之家 › 专栏 › 技术社区 › cjk

为什么INT不能比UNIQUEIDENTIFIER更有效(根据执行计划)?

sql-server

cjk · 技术社区 · 16 年前

子表在列上有一个聚集索引,该列将子表连接到父表(其主键也是聚集的)。

当我从父表中查询已知的20条记录时,从子表中提取所有相关的记录,两个表的查询成本都是相同的,即50/50的批次成本。

如果这是真的,那么像这样修改所有表的大型项目似乎毫无意义,除了加快插入速度。有人能提供有关情况的线索吗?

编辑:

问题不在于哪个更有效, 但是为什么查询执行计划显示两个查询具有相同的成本呢?

3 回复 | 直到 16 年前

Remus Rusanu 16 年前

在聚集索引中的键中查找与在4字节键、16字节键或160字节键中查找基本相同。比较时隙和谓词的成本只是查询总成本(执行准备、准备执行上下文、打开行集、定位页面等)中的噪音,

虽然没有人会说guid和INT是平等的,但是仅仅比较20次查找并不能揭示两者的区别。有件事你立即测量的是空间:每行节省12字节和聚集索引上的每个非叶页加上非聚集索引上的每个叶页上的12个字节,总计将超过数百万行和数十个表和索引。更少的空间意味着更少的IO、更好的内存缓存性能、更好的整体性能等等可以 实际载荷

在实验室条件下,您将能够测量寻找INT或GUID之间的原始速度差异,但这不应该是您的重点。INT vs.GUID的参数不是由seek中5%的性能增益驱动的,而是由空间节省和GUID的随机性驱动的,这两个参数都非常容易测量,根据它们自己的理由为INT提供了可靠的依据,不需要引入seek性能参数。

Ð¯egDwight kri 16 年前

很多效率更高。

Int要小得多。这意味着您可以获得更小的索引,这意味着您可以获得更好的内存使用和索引访问的加载时间。不过,这在很大程度上取决于你的桌子有多大以及你用它们做什么。

Piotr Rodak 16 年前

最重要的是,使用GUID作为聚集索引在大多数情况下会导致它们的巨大碎片化,从而影响查询在IO方面的性能。当您不使用按顺序生成的guid时就会发生这种情况,我想这主要是应用程序在数据库之外生成guid时的情况。要创建顺序guid(“大于”以前在数据库中生成的guid),必须使用函数 newsequentialid()