每個HTTP請求有多少SQL查詢是最佳的？

Question

我知道這個問題的答案大部分是“它取決於”，但是我想知道是否有人有一些指示。

我們在ASP.NET MVC中執行每個請求的查詢。 我們需要獲取用戶權限信息的每個請求，以及我們正在顯示的視圖的各種數據。 有多少是太多，我知道我應該意識到我正在執行的查詢數量。 我會假設如果他們是小問題並進行優化，那么半打應該沒問題？ 我對嗎？

你怎么看？

Answer 1

過早優化是萬惡之源:)

首先創建您的應用程序，如果它是緩慢的，您將必須確定原因並優化該部分。 確保減少查詢將節省您的時間，但也優化您必須執行的查詢。

您可以花一整天的時間來減少50％的時間花在查詢上，開始時只花費2毫秒，或花費2個小時來刪除一些內部INNER JOINS ，這使得另一個查詢需要花費10秒鍾。 在開始優化之前分析什么是錯誤的。

Answer 2

最佳數量為零。

鑒於這很可能無法實現，唯一合理的說法是：“盡可能少”。

Answer 3

• 簡化您的網站設計，直到它盡可能簡單，並仍然滿足您的客戶的要求。

• 緩存可以緩存的信息。

• 在可能的情況下，將信息預加載到請求外的緩存中。

• 僅詢問該請求中所需的信息。

• 如果您需要為單個請求進行大量獨立查詢，請盡可能並行加載。

您剩下的就是該網站的“最佳”金額。 如果這太慢，您需要再次檢查以上內容。

用戶權限信息可以被緩存，您可以在任何地方顯示其他常見信息。

您可以通過超出要求的緩存來逃避。 例如 - 您可以緩存“實時”信息，例如產品庫存水平和用戶的購物車。 使用SQL更改通知允許您在后台過期和重新填充緩存。

Answer 4

盡量少。

使用緩存進行查找。 還在會話中存儲一些輕量級數據（例如權限）。

Answer 5

您可以根據需要制作任意數量的查詢，直到您的網站速度過慢。

Answer 6

問：您是否遇到與數據庫查詢相關的性能問題？

是？ 答：比現在少。
沒有？ 答：你現在的號碼完全相同。

如果沒有損壞，請不要修理它。

雖然重構和優化以節省幾毫秒是程序員花時間的一種有趣且智力上有益的方式，但這通常是浪費時間。

此外，更改代碼以組合數據庫請求可能會以代碼中的簡單性和可維護性為代價。 也就是說，雖然技術上可以將多個查詢合並為一個，但這可能需要刪除代碼中業務對象的概念隔離，這很糟糕。

Answer 7

盡可能多，但不多。

換句話說，性能瓶頸不是來自查詢的數量 ，但你在查詢做什么以及如何處理數據（例如緩存一個巨大的尚未靜態結果集可能會幫助）。

Answer 8

除了減少旅行次數的所有其他建議外，還取決於每次往返時檢索的數據量。 如果它只是幾個字節，那么它可能很健談，性能也不會受到影響。 但是，如果每次旅行返回數百kb，那么你的表現會受到更快的傷害。

Answer 9

你已回答了自己的問題“ 這取決於你 ”。

盡管如此，試圖證明每個HTTP請求的最佳查詢數量是不可能的。 如果您的SQL服務器具有真正良好的硬件支持，那么您可以在更短的時間內運行大量查詢，並且HTTP請求的轉換時間非常短。 所以基本上，正如你正確地說的那樣，“它取決於”。

Answer 10

如上面的評論所示，某些緩存可能適合您的情況。 就像你的問題所暗示的那樣，真正的答案是“它取決於”。 通常，查詢越少，因為每個查詢都有與之關聯的成本，因此查詢越多越好。 您應該檢查數據模型和應用程序的要求，以確定哪些是合適的。

例如，如果用戶的權限在用戶會話期間可能是靜態的，則緩存權限數據是有意義的，因此需要的查詢更少。 如果View中顯示的數據的某些方面對於用戶的會話也是靜態的，則也可以緩存這些方面。