MySQL LIKE 查詢陷阱：下劃線（_）與百分號（%）通配符導致的全表掃描風險

實踐中發現：用戶輸入 ___ 或 .__ 等關鍵字進行 LIKE 查詢時，會匹配返回全表數據。根因在於 MySQL LIKE 語法中 _ 代表「任意單字符」，% 代表「任意長度字符」，未經轉義直接拼接 SQL 將導致語義異常。

問題複現

-- 用戶輸入 "___"
SELECT * FROM articles WHERE title LIKE '___';  -- 等價於任意三字符標題，極大概率全表命中
-- 用戶輸入 ".__"
SELECT * FROM articles WHERE title LIKE '.__'; -- 任意單字符開頭 + 任意字符結尾

官方文檔定義

修復方案：輸入轉義

在拼接 SQL 前，將用戶輸入中的 _、%、\ 進行轉義：

// PHP 示例
$safe = str_replace(['\\', '_', '%'], ['\\\\', '\\_', '\\%'], $user_input);
$sql = "SELECT * FROM articles WHERE title LIKE '$safe'";

或使用預處理語句（參數化查詢），由驅動層自動處理轉義，徹底消除注入與語義異常。

影響範圍

經驗證，IPB、PHPBB 等主流論壇早期版本均存在此缺陷，vBulletin 已內建過濾。所有構建動態 LIKE 查詢的應用均需排查修復。

最佳實踐

1. 全站統一使用預處理語句（mysqli_prepare/PDO::prepare）。
2. 若必須拼接 SQL，封裝統一轉義函數並強制代碼審查。
3. 在應用層限制用戶輸入長度與字符集（如僅允許字母數字）。
4. 部署 WAF 規則攔截異常 LIKE 模式（如純通配符查詢）。

看似微小的語法細節，實則是資安防線的一環。開發規範與自動化掃描相結合，方能避免此類低級邏輯漏洞。