重複SQL查詢

Question

執行重複SQL查詢的最佳做法是什麼？我的理解是使用參數化查詢，並在第一次執行時將其變爲準備好的語句。如果這個查詢需要由多個線程執行，該怎麼辦？我需要爲每個線程的每種查詢類型創建一個準備好的語句嗎？ 或者現在SQL語句的解析非常高效，現在已經不需要準備語句了？

Answer 1

好問題 - 一次回答一個問題。

• 什麼是執行重複SQL查詢的最佳實踐？

如果查詢將在參數差異之外重複，則使用預準備語句。

• 我的理解是使用參數化查詢，並把它變成在第一次執行一個準備好的聲明。

這是我對應該做什麼的看法。通常，建議是在程序啓動時準備所有查詢。在我看來，這總是無稽之談。它使用查詢重載服務器，其中許多將不會用於任何給定的運行，浪費客戶端和DBMS中的內存。按需編寫報表總是最明智的;當它第一次需要時，而不是除非需要它。我會允許一個會「總是」執行的語句的例外 - 但我必須確信，「總是」真的接近100％的時間。

• 如果此查詢需要由多個線程執行，該怎麼辦？我需要爲每個線程的每種查詢類型創建一個準備好的語句嗎？

這取決於不同線程如何與DBMS進行通信。在我熟悉的DBMS中，如果線程共享一個單一連接，那麼您只需爲單個連接準備一次即可。如果每個線程都有自己的單獨連接，則需要分別爲每個線程準備語句。

• 或者是SQL語句時下非常高效，編制報表不再需要的解析？

機器速度很快 - 是的。對於不重複的陳述，不值得擔心開銷。但是，如果你要執行幾百萬次查詢，那麼準備幾百萬次的開銷就會增加。另外，數據庫服務器機器通常是共享資源，但是可能會爲每個用戶單獨準備聲明，因此如果您有多個用戶使用重複查詢丟棄系統，系統會忙於準備查詢以執行任何操作他們的速度很快。

所以，我的答案是「不」。當查詢經常重複時，準備好的陳述仍然有用 - 「經常性」可能不是經常出現的情況。數百次 - 使用準備好的語句。幾十次 - 可能使用準備好的語句。少於這一點 - 也許不要使用準備好的語句。

Answer 2

那麼，你沒有提到你正在使用的環境，但一般來說，你也可以考慮存儲過程（如果你的數據庫引擎支持它）。它具有在數據庫本身中構建額外的抽象層的好處，從而使確切的數據庫模式與客戶端應用程序的關聯性降低。

大多數情況下都鼓勵使用參數化查詢，這不僅是爲了提高性能，還是爲了防範SQL注入和防止數據類型轉換問題（本地化日期時間）。