MySQL 預處理語句性能實測：是否真能提升查詢效率？

關於 MySQL 預處理語句是否能提升性能，社區存在兩種截然不同的觀點。本文通過嚴謹的基準測試，在 MySQL 5.1.57 環境下對比直接查詢與預處理語句的執行效率，得出令人驚訝的結論。

實驗設計

測試環境

• MySQL 版本：5.1.57-win32
• 測試表 MyTable，含字段 DictID
• 使用 SET profiling=1 開啟性能分析，從 information_schema.profiling 獲取微秒級耗時
• 預熱表：先執行一次查詢打開表，避免首次 open table 干擾
• 調整 profiling_history_size=100 保留足夠樣本

對比兩組腳本

NormalQuery.sql（直接查詢）

SET profiling=1;
SELECT * FROM MyTable WHERE DictID = 100601000004; -- 預熱
SELECT DictID FROM MyTable LIMIT 1, 100;
SELECT DictID FROM MyTable LIMIT 2, 100;
...
SELECT DictID FROM MyTable LIMIT 100, 100;
-- 導出結果分析

StmtQuery.sql（預處理語句）

SET profiling=1;
SELECT * FROM MyTable WHERE DictID = 100601000004; -- 預熱
SET @stmt = 'SELECT DictID FROM MyTable LIMIT ?, ?';
PREPARE s1 FROM @stmt;
SET @s = 100;
SET @s1 = 101; ... SET @s100 = 200;
EXECUTE s1 USING @s1, @s;
EXECUTE s1 USING @s2, @s;
...
EXECUTE s1 USING @s100, @s;
-- 導出結果分析

實驗結果

場景一：無查詢緩存（100 條不重複查詢）

場景二：有查詢緩存

NormalQuery 同樣完勝，預處理語句無優勢。

微觀步驟分析

通過 profiling 細節對比發現：

• 預處理語句比直接查詢多出一個準備步驟
• 雖然部分步驟（如 parsing）預處理較快，但 executing 階段明顯更慢
• 總體耗時 = 各步驟之和，直接查詢佔優

結論與思考

在 MySQL 5.1 命令行/腳本場景下，預處理語句不僅未提升效率，反而比直接執行 SQL 更慢。

可能的原因

1. 客戶端協議開銷：PREPARE/EXECUTE 需要額外網絡往返
2. 查詢緩存不兼容：早期版本預處理語句不走 Query Cache
3. 優化器重複工作：每次 EXECUTE 仍需優化，未複用執行計劃
4. 測試場景局限：本測試為單連接、無並發、參數化程度低

什麼場景下預處理有效？

• 編程語言調用（PHP/Java/Go）：複用 PreparedStatement 對象，避免重複解析
• 高並發、重複執行同結構 SQL：節省解析/優化 CPU
• 防止 SQL 注入：參數綁定是核心價值，性能是副產品

建議

不要盲目相信「預處理提升性能」。在應用層使用參數化查詢主要為安全性；性能優化應優先關注索引設計、SQL 重寫、架構分層等更高收益手段。