索引行Id與行DateTime

我有一個典型的表，它具有主鍵整數Id和DateTime列以記錄行的創建時間。理論上，Id列的順序應始終與DateTime列的順序相同。我的應用程序做了ORDER BY CreateDateTime DESC，我打算爲CreateDateTime列添加一個索引，但後來我意識到主鍵上的聚集索引應該完成相同的事情，即使它在語義上不正確，也許我應該按Id排序以防止創建另一個索引。無論如何你會添加CreateDateTime索引嗎？那麼如果它是一個LastUpdatedDateTime列（意味着偶爾更新索引）呢？索引行Id與行DateTime

來源

2011-07-30 kenwarner

「理論上」......如果實踐不符合理論，這有什麼關係嗎？

如果是，則創建索引並按該日期字段排序。如果否，請使用主鍵。

來源

2011-07-30 15:37:17 Mat

如果您不打算進行日期範圍搜索，請不要通過主鍵添加索引和順序。我認爲語義仍然是正確的，因爲您按照插入行的順序列出。 PK正在跟蹤您的訂單，而不是DateTime。

這是假設CreateDateTime始終使用getdate（）或行插入時可比較。如果您預計該日期是以其他方式創建的，那麼我將使用CreateDateTime上的索引並在Order By子句中使用該索引。

來源

2011-07-30 15:49:07 Mufaka

我有幾個場景，我們在日期時間列上有聚集索引。這可以很好地解決，因爲數據總是在增加（意味着頁面上的熱點，但沒有頁面拆分），並且幾乎所有的查詢都在日期範圍而不是上的任何其他數據。儘管這是針對大量的交易數據，而不是針對實體。

你會不會專門基於datetime列對錶進行大量查詢？如果沒有，那麼我認爲你不會從那裏的索引中受益 - 堅持實際的標識符作爲聚簇密鑰。更重要的是，如果我們正在討論最後更新的專欄 - 您的查詢中有多少百分比會使用這樣的索引？看起來好像根本不會增加你的成本（但是根據數據更新的頻率，它可能會花費你很多）。

究竟我們在談論什麼樣的實體？這些用戶，救護車，芭比娃娃，論壇帖子，火山還有其他的東西嗎？您每天，每週，每月要添加多少行？你對他們進行什麼樣的查詢？瞭解查詢的數量和類型可以在確定索引策略方面發揮重要作用。

來源

2011-07-30 21:28:05

使用Id。它將更好地考慮時區變化

來源

2017-02-15 21:56:02 Guy

您應該提供更多詳細信息並解釋您的答案。 – sabbahillel

索引行Id與行DateTime

回答

相關問題