JDBC 最佳實踐：為什麼必須用 PreparedStatement 替代 Statement

JDBC 最佳實踐：為什麼必須用 PreparedStatement 替代 Statement

在 JDBC 開發中，PreparedStatement 不是可選優化，而是強制性標準。本文從代碼可讀性、執行效能、SQL 注入防護三個維度，鐵證如山地論證為什麼任何場合都不應使用 Statement。

對比直觀展示

❌ Statement - 字串拼接地獄

String sql = "INSERT INTO tb_user (name, email, age, status) VALUES (" 
    + "'" + name + "', "           // 字串需單引號
    + "'" + email + "', "           // 易漏引號、轉義
    + age + ", "                    // 數字無引號
    + "'" + status + "')";          // 維護噩夢
stmt.executeUpdate(sql);

✅ PreparedStatement - 參數化查詢

String sql = "INSERT INTO tb_user (name, email, age, status) VALUES (?, ?, ?, ?)";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setString(1, name);   // 索引從 1 開始
ps.setString(2, email);
ps.setInt(3, age);
ps.setString(4, status);
ps.executeUpdate();

理由一：代碼可讀性與可維護性

理由二：效能優化 - 預編譯與執行計劃緩存

資料庫處理流程對比

// Statement 每次執行流程
SQL 字串 → 詞法分析 → 語法分析 → 語義分析 → 優化器生成執行計劃 → 執行
                    ↑ 每次都要完整走一遍

// PreparedStatement 流程
首次: SQL 模板 → 解析 → 優化 → 緩存執行計劃 (Key: 模板文本)
後續: 參數綁定 → 直接使用緩存計劃 → 執行
                    ↑ 省去解析優化開銷

緩存匹配機制

• 緩存 Key：SQL 模板文本 (正規化後)
• 匹配條件：完全相同的模板文本 (大小寫、空格、註解敏感)
• 跨連接共享：多數資料庫 (Oracle、MySQL、PostgreSQL、SQL Server) 在實例級緩存執行計劃，不同 Connection 可複用
• Statement 緩存？：幾乎無資料庫緩存動態 SQL，因參數值內嵌導致文本幾乎唯一

實測效能差距

// 批量插入 10,000 條測試 (MySQL 8.0, 本地)
Statement:      ~ 8.2 秒 (每次解析優化)
PreparedStatement: ~ 1.3 秒 (複用計劃)
Batch + PreparedStatement: ~ 0.4 秒 (再加批次優化)

// 結論: 預編譯 + 批次 = 數量級提升

理由三：安全性 - 徹底防禦 SQL 注入

Statement 注入漏洞演示

// 登入查詢
String sql = "SELECT * FROM users WHERE username = '" + username 
    + "' AND password = '" + password + "'";

// 攻擊輸入
username: "admin' --"
password: "任意"

// 實際執行 SQL
SELECT * FROM users WHERE username = 'admin' --' AND password = '任意'
// -- 註解掉後續條件，直接以 admin 身份登入！

// 更嚴重：聯合注入
password: "'; DROP TABLE users; --"
→ 執行 DROP TABLE，資料全無

PreparedStatement 免疫原理

// 預編譯階段已確定語法結構
SELECT * FROM users WHERE username = ? AND password = ?

// 參數綁定階段：參數視為純數據，絕不參與語法解析
ps.setString(1, "admin' --"); // 視為字面字符串 "admin' --"
ps.setString(2, "anything");

// 實際查詢：尋找用戶名字面為 "admin' --" 的記錄
// 無法改變 SQL 邏輯結構

核心原理

代碼與數據分離：預編譯階段確定 AST (抽象語法樹)，參數只填入葉子節點值，永不改變樹結構。

進階用法最佳實踐

1. 批次處理 (Batch Processing)

String sql = "INSERT INTO orders (user_id, amount, status) VALUES (?, ?, ?)";
PreparedStatement ps = conn.prepareStatement(sql);

for (Order order : orders) {
    ps.setLong(1, order.getUserId());
    ps.setBigDecimal(2, order.getAmount());
    ps.setString(3, order.getStatus());
    ps.addBatch(); // 累積批次
}

int[] results = ps.executeBatch(); // 一次性提交
// results[i] 為各條影響行數

2. 獲取自增主鍵

ps.setBlob(1, inputStream, length);
ps.setClob(2, reader, length);
// 或
ps.setBinaryStream(1, inputStream, length);
ps.setCharacterStream(2, reader, length);

4. 存儲過程調用

反模式與常見誤區

誤區
正確做法
以為 PreparedStatement 只能用於 INSERT/UPDATE
SELECT、DELETE、DDL 同樣適用
動態 SQL (IN 列表、可選 WHERE) 無法用 PreparedStatement
動態構建 ? 佔位符字串，參數索引對應綁定
每次執行 new PreparedStatement
長連接場景複用 PreparedStatement 物件
setString 用於所有類型
嚴格匹配 setInt/setLong/setTimestamp/setBigDecimal 等
以為 PreparedStatement 完全杜絕注入
表名、欄位名、ORDER BY 子句無法參數化，需白名單驗證


動態 SQL 安全構建範例
= ?"); params.add(ageMin); }
if (ageMax != null) { sql.append(" AND age <= ?"); params.add(ageMax); }

PreparedStatement ps = conn.prepareStatement(sql.toString());
for (int i = 0; i < params.size(); i++) {
    ps.setObject(i + 1, params.get(i));
}

總結：鐵律

零例外：生產代碼中禁止出現 Statement (除非執行純靜態 DDL 如建表)
三重保障：可讀性 ✓ 效能 ✓ 安全性 ✓
工程規範：Code Review 必檢項、靜態分析規則 (SpotBugs/Checkstyle) 強制檢測
遺產代碼重構：將 Statement 重構為 PreparedStatement 是最高 ROI 的技術債務清理

PreparedStatement 不是「更好」，而是「唯一正確」的選擇。這不僅是最佳實踐，更是專業開發者的底線。