從網上了解到的資料，preparestatement預設情況下是沒有開啟jdbc的預編譯功能的，也沒有開啟mysql的預編譯功能 。
也就是說，在效能上，與傳統的statement沒什麼差別。
這簡直是顛覆了我的認知，我以為preparestatement是開啟了預編譯的，效能會有所提公升，就來進行測試，看看preparestatement對效能到底有沒有提公升。
測試環境mysql8.0，jdbc驅動8.0
@test
public void t() throws sqlexception
instant end = instant.now();
preparedstatement.close();
start = instant.now();
for(int i=0;i<10000;i++)
end = instant.now();
statement.close();
connection.close();
}
不行，換個方式測試一下，我們把statement放在前面執行，看看有什麼不同的結果。
僅僅交換了兩個for迴圈的位置
@test
public void t() throws sqlexception
instant end = instant.now();
statement.close();
start = instant.now();
for(int i=0;i<10000;i++)
end = instant.now();
preparedstatement.close();
connection.close();
}
這是什麼情況？居然是先後順序影響的查詢結果,難道是mysql內部進行了優化？
希望有大佬能幫忙分析一下怎麼回事。
不行還要再換一種方式，測試還是要進行下去的。
@test
public void t1() throws sqlexception
instant end = instant.now();
preparedstatement.close();
connection.close();
}@test
public void t2() throws sqlexception
instant end = instant.now();
statement.close();
connection.close();
}
這下結果就正確了，兩個程式執行查詢，結果都差不多，甚至在某些時候，非預編譯的還要比與編譯的快一點（猜想可能是防止注入影響的，只是猜想），預編譯的那個比起非預編譯的的確是沒有效率的提公升。可以嘗試將查詢次數修改的更大，看看到底誰更快。
兩段測試經過多次的測試，結果都是在15s到16s的樣子。由此可見，jdbc預編譯在預設情況下，比起非預編譯確實是沒什麼提公升。
JS預編譯 函式預編譯和全域性預編譯
預編譯發生在函式執行前一步 建立ao物件 執行期上下文 找形參和變數宣告，將變數和形參名作為ao 屬性名，值為undefined 將實參值和形參統一 在函式體裡面找函式宣告，值賦予函式體 結果 預編譯過程 函式馬上要執行，但是還沒執行 首先建立ao物件，也就是函式它產生的儲存空間庫 ao，b und...
JDBC程式設計之預編譯SQL與防注入
在jdbc程式設計中，常用statement preparedstatement 和 callablestatement三種方式來執行查詢語句，其中 statement 用於通用查詢，preparedstatement 用於執行引數化查詢，而 callablestatement則是用於儲存過程。1 ...
預編譯與編譯
一c c 源 從最初的文字變為可執行檔案主要進行三大步 預編譯階段 主要是編譯器執行 文字處理工作，並不會進行語法檢查 主要執行三大類預編譯命令 巨集定義 文字替換功能，將使用了巨集的地方採取巨集定義方式直接展開 條件編譯 文字剪下功能，根據設定的條件選擇性刪除一些 片段 包含檔案 文字插入功能 i...