使用「=」和「LIKE」有什麼不同嗎？

Question

首先，我想提一下，我試着谷歌搜索這個無濟於事。

我想在我的所有列中使用通配符的選項。因此，我希望我所有的SELECT對帳單都使用LIKE而不是=。讓我指出在我的應用程序中有用戶輸入數據，這排除了注入攻擊的任何問題。

如果查詢的其餘部分保持不變，兩者之間是否存在速度差異？ （也就是說，如果條件的右側不包含通配符）。

Answer 1

沒有區別。

WHERE姓LIKE '弗雷德'

是不是從

感知不同的WHERE姓名= '弗雷德'

所以，你可以自由地使用 「LIKE」， 「=」，在所有的，而不是 需要存在通配符來控制是否要 調用通配符搜索。

我找不到參考，但我已經看到這個不止一次提到，它是 是有道理的。索引策略將等同於任何一種方式（它只能匹配 相同索引上的相同字符），並且我有時會以這種方式編寫查詢，因爲在特定調用中存在或不存在通配符是可以接受的。 另外，我從來沒有見過某個人試圖解析出存在一個狂野的角色，並根據情況不同地調用SQ1的情況。這樣做可能會帶來風險，因爲使用錯誤的表達式編寫低效（unSARGable）查詢會更容易。

Answer 2

是的，雖然有多大依賴。

如果列被索引，那麼它可能會慢很多。特別是如果您比較類似'%suffix'之類的內容，因爲百分號出現在搜索字符串的開頭時，索引根本無法使用。

Answer 3

任何像樣的DBMS都應該在like中檢測到一個非通配符字符串，並將它看作與=完全相同。但即使這樣檢查也需要一些時間，但無論如何都是微不足道的。

如上所述，這樣做的時間會很短，並且每個查詢只會發生一次。 真的需要注意的性能問題是每行產生成本的東西，比如select to_lower(column_name)。換句話說，你可能不需要關心你的具體情況。

如果你有使用通配符，那麼它幾乎肯定會變慢，只是因爲你必須檢查部分列。像like 'xyz%'這樣的子句不會太慢，但是在字符串末尾以外的任何地方都可能導致更嚴重的問題。

但是，如果您使用通配符爲，則不會有選項 - like將是唯一的可能性。底線：除非您的DBMS死腦筋，=和like之間的非通配符字符串之間的差異將是微不足道的。

但是，如同所有數據庫優化：措施，不要猜測！

---

我做仍然受到你的問題的一個方面，雖然混淆。您聲明：

讓我指出在我的應用程序中沒有用戶輸入數據。

我假設我們確保SQL注入攻擊是不可能的。

但是因爲這個原因，你一定會事先知道（在代碼中）查詢是通配符還是非通配符。在這種情況下，爲什麼不恰當地在適當的地方使用=變體，並消除所有疑問。

如果，你在評論中註明，有沒有通配符查詢，你爲什麼會連使用like考慮。

Answer 4

@Jonathan Wood說了些什麼。例如，當您詢問MySQL時，要使用通配符'％'查找值，服務器必須讀取整個表中的每一行以查找匹配項。