MySQL PreparedStatement 預編譯性能測試與結論

MySQL PreparedStatement 預編譯性能測試與結論

測試背景

Oracle 中 PreparedStatement（綁定變量）可大幅減少 Library Cache 硬解析，提升高併發性能。MySQL InnoDB 架構差異大，是否同樣受益？

測試環境

• MySQL 5.6，InnoDB，JDBC 驅動 5.1.x
• 測試表 test1(id INT PRIMARY KEY, ...)，5000 行數據
• Java 程式分別用 Statement（硬解析）與 PreparedStatement 執行 5000 次 SELECT * FROM test1 WHERE id=?，循環 10 次取平均

測試代碼關鍵片段

// Statement 硬解析
String sql = "SELECT * FROM test1 WHERE id=" + i;
rs = stmt.executeQuery(sql);

// PreparedStatement
String sql = "SELECT * FROM test1 WHERE id=?";
pstm = conn.prepareStatement(sql);
pstm.setInt(1, i);
rs = pstm.executeQuery();

測試結果

結論分析

1. 性能差異極小（<7%）：MySQL 無 Library Cache 等效結構，解析開銷佔比低，網絡 RTT 為主導因素。
2. 驅動默認 Client-side prepare：僅在客戶端拼裝 SQL，Server 仍按普通查詢處理。
3. Server-side prepare 無額外收益：useServerPrepStmts=true 啟用後，Server 解析、優化、生成执行计划流程不變，反而增加準備階段開銷。
4. 真正優勢在安全：PreparedStatement 防 SQL 注入、類型安全、代碼可讀性，非性能考量。

最佳實踐建議

• 所有業務 SQL 統一使用 PreparedStatement，防注入、可維護。
• 高併發點查優化重點：索引覆蓋、連接池調優、減少網絡往返（批量/管道）。
• 若極致追求解析復用，可評估 ProxySQL、MySQL Router 等中間件的查詢快取/準備語句緩存功能。