SQL Server 2008性能問題

Question

我有一個包含30列和約340萬條記錄的表。 SELECT * FROM [Table];需要8到12分鐘才能返回所有340萬個結果？

如果不是，哪裏是開始診斷我的問題的好地方/資源？

Answer 1

這很有可能是SQL服務器正在盡最大努力來獲取您要求的數據。 假設至少1K /記錄30列並非不合理。 3.4M×1K = 3.4Gb。

從盤面可能需要幾分鐘的平均機上只是閱讀3.4Gb（不要忘了，這不只是讀書，顯然有它的一些SQL處理開銷。

但是，當然在真實的場景中你不想檢索所有的數據...

Answer 2

是的，是合理的。對於一個系統，精細調諧和最佳運行可以在約12分鐘內提供3.4萬行，這正是預期的結果...

無論如何，一些地方尋找提高性能：

• 該表是否適合緩衝池？ IE瀏覽器。你有足夠的RAM來存儲你的整個數據庫嗎？如果不是，那麼你會打到磁盤的IO。 Page life expectancy計數器是一個很好的指標。
• 磁盤I/O子系統有多快？我們是在談論一個5000 RPM的二手IDE驅動器或RamSAN-500嗎？ sqliosim報告的吞吐量是多少？性能指標如何，Avg。磁盤隊列長度，平均值磁盤秒/物理磁盤上的傳輸？ Reads vs. Writes不同嗎？
• 表格有多碎片？掃描性能首先受到預讀效率的影響，預讀大小由霍普片段大小決定。也許你需要優化表的ETL，遵循FastTrack方法。
• 任何爭用正在進行？你有沒有測量鎖定等待時間？也許snasphot隔離可以解決問題。
• 客戶能夠及時收到3.4密耳的行嗎？客戶端上的服務器塊是否可用？再次，等待統計可以表明這一點。

另一個開始的好地方是遵循Wait and Queues方法。

Answer 3

有很多問題可能會被問到與磁盤IO，列的大小和其他設置相關的事情。底線，除非你是一個非常慢的磁盤和慢速網絡，它不應該需要12分鐘。

首先要看的是執​​行計劃。這應該讓你瞭解SQL Server如何處理事物。

夫婦的事情，我會問，以更好地排除故障？有主鍵嗎？它是否聚集？有訂單嗎？

Answer 4

開始診斷您的問題的最佳位置是確定您是否有任何問題。設定一個具體的，可衡量的，面向業務的績效目標，並確定您認爲合理的返回數據的時間。

如果你的答案是8-12分鐘，那麼你沒有問題，這總是一件好事。

如果你的答案比這還少，那麼你現在知道你有問題，問題有多大（如果你說5分鐘，那麼這可能不是一個很大的問題，如果你說10秒，那麼它是一個更大的問題）。在這種情況下，您可能需要開始查看數據庫性能計數器，以查看是否存在CPU/IO /內存/網絡瓶頸，並查看查詢的執行計劃以查看是否可以通過索引來改進儘管這對SELECT *來說不太可能）。

Answer 5

評估系統實際運行的查詢可能更有意思。 SQL Server附帶的Profiler工具可以記錄您的系統正在運行的所有查詢。讓它運行一段時間（假設您有足夠的額外磁盤空間），它將記錄正在運行的查詢以及給定的參數。它還會告訴你他們全部執行了多久。

考慮這一點並確定哪些查詢正在使用CPU時間將幫助您找出性能調整的位置 - 例如，如果查詢A需要60秒運行並且每天只運行一次，可能會對該特定應用程序產生重大影響，但調整該查詢不會讓您的SQL Server更快。但是如果查詢B每秒運行2秒並且每天運行4000次，那麼調整它可能會產生更大的整體影響。

通常，添加相關索引和調整「大罪犯」查詢的性能可能會對性能產生非常嚴重的積極影響。分析器告訴你哪些查詢可能會讓你大吃一驚。

Answer 6

比較合理嗎？

1. 行寬有多寬？
2. 你的CPU速度有多快？
3. 你有多少內存？
4. 當您開始查詢時，表是否已經在RAM中？
5. 您是通過網絡傳遞結果嗎？如果是這樣，它有多快？
6. 檢索行的客戶端有多快？
7. 你的磁盤有多快？
8. 表格有多碎片？
9. DB機器是否在同一時間做其他事情？

Answer 7

我同意你的觀點，我在不到3分鐘的時間內從SQL 2008服務器中取回了2000萬行數據 - 硬件成本低於SQL許可證。

除非您的硬件/網絡真的很糟糕，否則在某個地方會有性能提升。