2008-10-07 90 views
3

我試圖擠壓一些額外的表現搜索通過一個很多行的表。 我目前的推理是,如果我可以從搜索表中刪除一些很少使用的成員,從而減少行數量的pagesplits,因此IO應該放棄給數據開始從內存溢出時的好處。SQL Server 2005 Rowsize對查詢性能的影響?

任何良好的資源詳細說明這種影響? 任何經驗?

謝謝。

回答

2

我現在沒有什麼你試圖提高性能,這似乎像抓住我的吸管。這並不意味着它不是一個有效的方法。根據我的經驗,這個好處可能很重要。只是它通常被其他優化所拖垮。

但是,您正在尋找的是統計學。有幾種方法可以收集它們。一個很好的介紹可以找到->here

3

如果RDBMS正在執行行的全表掃描,如果您的查詢可以僅使用索引選擇行,那麼調整行的大小隻是一個主要問題,然後行大小不太重要(除非您正在返回非常大量的行,其中返回實際結果的IO是顯着的)。

如果您正在執行大量行的全表掃描或部分掃描,因爲您有不使用索引的謂詞,則rowsize可能是主要因素。我記得的一個例子是,在一個100,000,000行的表格上,將大量「數據」列分成與用於查詢的列不同的表格,導致某些查詢的性能提高了一個數量級。

我只希望這是在相對較少的情況下的主要因素。

+0

我想你可能會低估有多少數據庫查詢正在使用表掃描或非常寬行的「書籤查找」!我將嘗試對我所知道的使用整個表格行進行搜索的查詢進行測試。 – 2011-08-13 00:00:29

1

SQL服務器查詢計劃優化器是一個非常複雜的算法和決定使用什麼索引或什麼類型的掃描取決於很多因素,如查詢輸出列,可用索引,可用統計數據,列中數據值的統計分佈,行數和行大小。

所以唯一有效的回答你的問題是:這取決於:)

給喜歡什麼樣的優化,你已經做了一些更多的信息,什麼是查詢計劃看起來像等

因爲,當sql server決定做一個表scna(聚簇索引掃描如果可用),你可以通過縮小行大小來降低io性能。但是在這種情況下,通過創建足夠的索引(這實際上是一個具有較小行大小的單獨表)可以顯着提高性能。

1

如果應用程序是事務性的,請查看錶中正在使用的索引。在這種情況下,表分區不太可能有幫助。

如果你有類似數據倉庫的東西,並對大量數據進行聚合查詢,那麼你可能會從分區中獲得一些里程數。

如果你正在做兩個大的表是不是在1之間的連接:M的關係查詢優化器可能需要單獨解決每個表上的謂詞,然後組合比較大的中間結果集或運行緩慢的運營商像嵌套循環匹配連接的一側。在這種情況下,您可能會從觸發器維護的非規範化表格中獲益以執行搜索。我已經看到了從一些大型應用程序的複雜屏幕的非規範化搜索表中獲得的好結果。

1

如果你有興趣在閱讀你需要檢查,如果索引覆蓋查詢或沒有數據減少IO。爲了最大限度地減少IO,您應該選擇包含在索引中的列或覆蓋查詢中使用的所有列的索引,這樣優化器將從索引讀取數據,並且永遠不會從實際錶行中讀取數據。
如果您正在研究這種細節,可能應該考慮升級硬件,更改控制器或添加更多磁盤,以便爲查詢處理器提供更多的磁盤主軸,從而允許SQL同時讀取更多數據

SQL Server磁盤I/O通常是大多數系統瓶頸的原因。 I/O子系統包括磁盤,磁盤控制器卡和系統總線。如果磁盤I/O一直很高,可以考慮:

移動某些數據庫文件到其他磁盤或服務器。
使用更快的磁盤驅動器或廉價磁盤(RAID)設備的冗餘陣列。
將額外的磁盤添加到RAID陣列(如果已經在使用)。
調整您的應用程序或數據庫以減少磁盤訪問操作。
考慮索引覆蓋率,更好的索引和/或規範化。

的Microsoft SQL Server使用Microsoft Windows I/O調用來執行磁盤讀取和寫入。 SQL Server管理何時以及如何執行磁盤I/O,但Windows操作系統執行底層I/O操作。 I/O綁定的應用程序和系統可能會使磁盤始終處於活動狀態。

不同的磁盤控制器及驅動器使用不同量的CPU時間來執行磁盤I/O。高效的控制器和驅動程序使用更少的時間,爲用戶應用程序提供更多處理時間,並提高整體吞吐量。

1

第一件事我會做的是確保你的索引已經重建;如果你正在處理大量的數據並且索引重建是不可能的(如果SQL Server 2005以上,你可以在不鎖定每個人的情況下執行在線重建),然後確保你的統計數據是最新的(稍後會有更多內容)。

SET STATISTICS IO ON 
GO 


-- Execute your query here 


SET STATISTICS IO OFF 
GO 

在井設置數據庫:

如果你的數據庫中包含有代表性的數據,那麼你就可以在讀取查詢是否通過執行以下操作使用(邏輯和物理)執行數量的簡單測量服務器,應該有很少或沒有物理讀取(高物理讀取通常表明您的服務器需要更多的RAM)。你在做多少個邏輯讀取?如果這個數字很高,那麼你需要看看創建索引。下一步是運行查詢並打開預計執行計劃,然後重新運行(首先清除緩存),顯示實際執行計劃。如果這些不同,那麼你的統計數據就會過時。

0

我認爲你會首先使用標準優化技術 - 檢查你的執行計劃,分析器跟蹤等,看看你是否需要調整你的索引,創建統計等 - 在看之前你桌子的物理結構。