我們正在開發一個客戶端 - 服務器桌面應用程序（使用LINQ-SQL的sql server 2008 winforms）。我們現在發現許多與性能相關的問題。這些涉及到使用LINQ查詢太多數據，數據庫設計不好，緩存等。你有什麼建議，我們應該做 - 如何解決這些性能問題？有一件事，我正在做的sql分析，並試圖修復一些查詢。就緩存而言，我們有靜態列表。但是，如何讓它們更新，我們沒有任何服務器端實現。因此，這些如果有人更改數據，列表可能會過時。如何解決性能問題？
問候
對於更新，您可以創建一個表。我稱之爲ListVersions。
只是存儲列表ID，名稱和版本。
當您對列表進行一些更改時，只需增加其版本即可。在你的應用程序中，你只需要比較版本並且只在它發生變化時更新。更新列表版本增加，而不是全部。
我描述它在我回答這個問題
What is the preferred method of refreshing a combo box when the data changes?
祝您好運！
一般配方的性能問題：
很多時候，最大的瓶頸並不完全在你身上，雖然他們是。所以，將您的行爲建立在測量數據基礎上
儘量減少SQL查詢的數量。與重新構建單個查詢的SQL語法相比，通過降低查詢量可以提高性能。
我推薦添加一些服務器端邏輯，而不是直接從客戶端發起SQL查詢。您可以實現緩存共享，但可以在服務器端實現所有客戶端。
沒有工具的性能分析是徒勞的，錯誤的工具令人沮喪。 SQL Profiler是依賴於您所看到的內容的錯誤工具。我認爲這至少給你一個什麼是錯的暗示。
您需要使用代碼探查器來確定爲何/何時執行這些查詢。你應該能夠通過谷歌搜索找到一個，並運行一個X天試用版。
關鍵的問題是：
查詢是否被多次運行時，有沒有理由呢？數據是否已經在內存中（即使沒有靜態存儲）。這種情況發生在很多數據已經被檢索的地方，但是由於代碼的某些操作，它會再次加載數據。類屬性是一個大罪魁禍首。
應該將某些數據靜態存儲在整個應用程序中嗎？這些數據有多易變？你能承受顯示陳舊的數據？
決定＃2的唯一方法是有硬數據來檢查特定事務的成本。例如，如果我知道需要1983毫秒才能創建新發票，那麼在開始緩存數據之後會發生什麼。高速緩存之後的那個儲蓄顯着。但是要認識到，只有知道需要1983毫秒才能創建發票，你就不能回答這個問題。
當我剖析應用程序事務時，我將重點放在大貢獻者身上，並嘗試確定它爲何如此之大。我尋找速度慢的單個方法以及經常執行的任何代碼。它通常是後者，一千削減的死亡，讓你。
我想補充一點，知道何時停止解決性能問題也非常重要。