使用預準備語句有缺點嗎？

我一直在閱讀很多關於準備好的陳述和我讀過的所有內容，沒有人會談論使用它們的缺點。因此，我想知道是否有任何人會忽略的「龍」點？使用預準備語句有缺點嗎？

2009-09-01 Scott

IT中的一切都有缺點，你只需要檢查他們是否真的值得擔心你的具體問題。 :)這個鏈接在SO http://stackoverflow.com/questions/535464/when-not-to-use-prepared-statements/537834有一些關於預處理語句的缺點。 – GmonC 2009-09-01 15:32:05

準備好的語句只是一個解析並預編譯的SQL語句，它只是等待要提供的綁定變量被執行。

任何已執行的語句遲早會被準備好（它需要被解析，優化，編譯然後執行）。

準備好的語句只是重用解析，優化和編譯的結果。

通常，數據庫系統使用某種優化來節省查詢準備時間，即使您自己不使用準備好的查詢。例如，當解析查詢首先檢查庫緩存時，並且如果相同的語句已被解析，則它使用緩存的執行計劃。

來源

2009-09-01 15:20:41 Quassnoi

我認爲這個答案缺少準備好的語句的關鍵問題，例如。查詢計劃根據準備查詢時出現的數據統計信息進行優化，並且在執行查詢時將來可能不是最佳選擇。所以這是一個準備好的聲明的缺點。 – egbokul 2011-10-18 08:24:46

一些文章提到類似的缺點：https://medium.com/@devinburnette/be-prepared-7768d1a111e1 ---和--- https：//www.vividcortex。com/blog/2014/11/19/analyze-prepared-statement-performance-vividcortex/ – MarsAndBack 2018-01-31 23:23:18

如果使用語句一次，或者如果你自動生成動態SQL語句（，要麼適當逃避一切都很或者確切地知道你的參數只有安全字符），那麼你不應該使用準備好的語句。

來源

2009-09-01 15:25:12 flybywire

當然，這是非常罕見的。我發現只要在服務器端準備好的聲明內容進行輸入清理就容易多了。 – Powerlord 2009-09-01 15:29:55

我能想到的唯一缺點是它們佔用了服務器上的內存。這並不多，但可能有一些邊緣情況會出現問題，但我很難想到任何問題。

來源

2009-09-01 15:31:09

準備好的語句與動態sql還有一個小問題，那就是它可能更難調試它們。使用動態sql，您可以隨時將問題查詢寫入日誌文件，並直接在服務器上運行，就像程序看到的那樣。通過準備好的語句，可以花費更多的工作來測試您的查詢，並使用根據崩潰數據確定的特定參數集進行測試。但沒有那麼多，額外的安全性絕對證明了成本。

來源

2009-09-01 15:38:52

在某些情況下，數據庫引擎在使用預準備語句時可能會提出低級查詢計劃（因爲如果沒有搜索的實際綁定值，它就無法做出正確的假設）。

參見例如在

http://www.postgresql.org/docs/current/static/sql-prepare.html

「註釋」部分，因此它可能是值得與不準備語句，以找出哪些是更快的測試你的查詢。理想情況下，您可以根據每個陳述來決定是否使用預先準備好的陳述，儘管並非所有的ORM都允許您這樣做。

來源

2011-10-18 08:02:40 pmeidl

我發現最好的模式是使用全或無的方法來準備語句。數據庫管理系統比我們大多數人都更聰明，大多數時候都可以計算出最好的計劃。另外，我確定您知道不同的DBMS將有不同的查詢計劃策略，因此不應將該鏈接用作準備好的語句的全部內容。如果您使用DBMS進行Web工作，防禦SQL注入攻擊的最快速和最簡單的方法是始終使用預準備語句。 – bakoyaro 2011-10-18 18:20:29

使用預準備語句有缺點嗎？

回答

相關問題