報表查詢運行時SQL Server查詢超時（包括讀/寫）

我有一個SQL Server 2005數據庫，它在工作時間內有大約30-40個連接到同一個數據庫。報表查詢運行時SQL Server查詢超時（包括讀/寫）

當我執行一個報告查詢（這個查詢大約需要30分鐘到1小時），其他連接在某些特定表上進行選擇/寫入時開始超時。此報表查詢使用兩個或三個子查詢和連接級別進行SELECT操作。我看着SQL Server日誌，我根本找不到任何錯誤。查看活動監視器不顯示除tempdb（顯示正在運行）之外的任何正在運行的進程。查看錶上是否有鎖，只顯示共享鎖。

我走得更遠了，檢查tempdb有足夠的空間（500MB增長到10GB）。

你知道什麼可能會導致此問題嗎？我應該從哪裏開始看？（我正在尋找優化，以報告現在的查詢）

來源

2011-12-01 cfreak

發佈您的報告查詢或至少相關部分。你也有報告查詢中的NOLOCK提示嗎？ –

我聞到行/表鎖定和一些死鎖。 – Amy

你一定要嘗試修復該查詢。與此同時，您可以作爲樂隊幫助措施將報告查詢的隔離級別設置爲READ UNCOMMITTED

這可以cause inaccuracies in your report（因爲它可以讀取最終回滾的事務）引起。

來源

2011-12-01 19:43:58

謝謝。在開發服務器上，我添加了幾個索引，現在查詢在幾秒鐘內運行。哇！。你有什麼想法超時問題的原因是什麼？ – cfreak

嗯井表掃描與索引查找似乎做出巨大的差異。 –

@cfreak，與索引掃描相比，全表掃描** **慢**。我將你引用到[這個問題]（http://stackoverflow.com/questions/4810804/sql-indexes-vs-full-table-scan）以獲取更多信息。而且非常谷歌「全表掃描與索引」 – Amy

當您運行查詢時，您需要在數據庫上運行配置文件。至少這是最快和最簡單的方法。很明顯，當你不用用你的地獄查詢給你的用戶帶來負擔的時候，你可以在離職時進行。不要把這些建議當作福音，但它們一定會幫助你朝着正確的方向前進。

另請檢查查詢計劃。我相信2005年允許你在那裏生成查詢計劃。如果沒有，您可以獲得SQL Express 2008的Management Studio/Analyzer，並且它可以在2005年的數據庫上正常工作。

來源

2011-12-01 21:54:07

報表查詢運行時SQL Server查詢超時（包括讀/寫）

回答

相關問題