存儲在記錄中的數據大小是否會影響聚集索引性能？

主事實表（FactTable）
含有的int字段表+其他 'N' VARCHAR（50）字段（Table001）
含有的int字段表+其他 'N' VARCHAR（最大）字段（Table002）

記錄在每個表：＃500萬行

查詢：

select * from FactTable f with (nolock) 
inner join Table001 t001 with (nolock) on f.id = t001.id 
inner join Table002 t002 with (nolock) on t002.id = f.id 
where f.datefield = '2014-02-01'

代

所有表對所有在球場上「ID」一個聚集索引（在連接表中使用，即，像一個外鍵）

羣集索引不分散（破碎率< 5％）表

這種情況是當我加入所有三個表，我看到在執行計劃中加入table002的成本高於table001。這種行爲是否有任何理由？

鏈接到XML執行計劃：https://onedrive.live.com/redir?resid=7E436AE9D73999B0%21120

我不能粘貼，因爲大小限制的XML內容。

另一個鏈接：http://www.expinos.in/ExecutionPlan.sqlplan

來源

2014-03-06 M22an

是隻有您的數據被讀取？否則，NOLOCK可能會返回錯誤的結果，你知道的。更好地使用（readcommitted）。 – TomTom

是大多數時間都是靜態的，只有在一天中的某個小時內纔會插入，所以NOLOCK不會損害數據的完整性 – M22an

您可以發佈XML版本的執行計劃嗎？ –

在一排列中，不是在索引的大小，不會影響含索引本身的性能。

然而，

大非索引列會影響基於表操作的性能。您會在頁面上獲得更少的行，因此在掃描時，您必須閱讀更多頁面。

包含在查詢中的大型非索引列將對查詢性能產生明顯的直接影響。你必須從磁盤/內存中讀取更大的值，儘管優化器會盡量做到這一點。

索引中列的大小影響索引的性能。

列的聚集索引會影響在桌子上

所有indecies的性能大小爲便於比較，1字節或10000？散列1個字節還是10000個比較容易？從磁盤/內存或10000讀取1個字節比較容易嗎？

來源

2014-03-06 14:34:57 Jodrell

這很有道理，但我只是對上述查詢進行了快速檢查，沒有包含Table002中的任何字段，但執行計劃仍然只有60％。有什麼辦法可以降低這個連接的成本嗎？ – M22an

@ M22an，我看不到你的查詢計劃，是否都滿意索引查找？ – Jodrell

與Table001的連接有索引掃描，而Table002有索引查找 – M22an

存儲在記錄中的數據大小是否會影響聚集索引性能？

回答

相關問題