返回 500 萬條記錄的查詢需要多長時間？

Question

我意識到答案可能應該是“盡可能少的時間”，但我正在嘗試學習如何優化數據庫，但我不知道我的硬件可接受的時間是多少。

首先，我將本地機器與 sql server 2008 express 的副本一起使用。 我有一個雙核處理器、2GB 內存和一個 64 位操作系統（如果有區別的話）。 我只使用一個包含大約 6 個 varchar 字段的簡單表。

起初我在沒有任何索引的情況下查詢數據。 這花費了相當長的時間，所以我取消並在表中添加了一個聚集索引（使用 PK）。 這將時間縮短到 1 分 14 秒。 我不知道這是否是我能得到的最好的，或者我是否仍然能夠進一步減少它？

我是否受到硬件的限制，或者我可以對我的表/數據庫/查詢做些什么來更快地獲得結果？

僅供參考，我只使用標准的 SELECT * FROM 來檢索我的結果。

謝謝！

編輯：只是為了澄清，我這樣做只是為了測試目的。 我不需要提取所有數據，我只是將其用作一致的測試，看看是否可以減少查詢時間。

我想我要問的是：除了a）升級硬件和b）添加索引（假設模式已經很好）之外，我還能做些什么來加快查詢的性能？

Answer 1

我認為你問錯了問題。

首先——為什么本地機器上一次需要這么多文章？ 你想對他們做什么？ 我問是因為我認為您想將這些數據傳輸到某個地方，因此您應該測量傳輸數據所需的時間。

一些忠告：

您的應用程序當時不應選擇 500 萬條記錄。 嘗試拆分您的查詢並以較小的集合獲取數據。

更新：

因為你這樣做是為了測試，我建議你

1. 從您的查詢中刪除* - SQL 服務器需要一些時間來解決這個問題。
2. 將您的數據放在臨時存儲中，為此嘗試使用VIEW或臨時表。
3. 在您的服務器上使用計划緩存

以提高性能。 但即使您只是在測試，如果您的應用程序永遠不會使用這樣的查詢，我仍然不明白為什么您需要這樣的測試。 僅僅為了測試而測試是對時間的錯誤利用

Answer 2

我在 20 秒內完成了 550 萬個。 這將占用超過 10 萬個不同頻率的時間表，並預測未來 25 年的時間表。 只是最大場景測試，但證明了您可以在調度系統中實現的速度作為示例。

Answer 3

查看查詢執行計划。 如果您的查詢正在進行表掃描，則顯然需要很長時間。 查詢執行計划可以幫助您決定需要在表上建立什么樣的索引。 此外，在數據按條件（通常是日期和時間）進行分區的情況下，創建表分區有時會有所幫助。

Answer 4

最佳優化方式取決於您選擇的索引策略。 正如上面的許多答案一樣，我也會說對表進行分區有時會有所幫助。 在單個時間范圍內查詢所有十億條記錄並不是最佳做法。 如果您可以嘗試使用迭代進行部分查詢，將為您提供更好的結果。 您可以查看此鏈接以消除對 Sql server 2008 最低硬件要求和 Sql server 2008 最低軟件要求的疑慮

Answer 5

當處理 500 萬行時，您幾乎 100% 將后台打印到 tempdb。 您應該嘗試通過添加其他文件來優化您的臨時數據庫。 如果您在單獨的磁盤上有多個驅動器，您應該將表數據拆分為位於單獨磁盤上的不同 ndf 文件。 當查詢磁盤上的所有數據時，分區無濟於事 U 也可以使用查詢提示來強制並行 MAXDOP 這將增加 CPU 利用率。 確保列包含盡可能少的空值並重建您的索引和統計信息