SQL在WHERE子句中選擇IN與LIKE

哪一個性能更快？SQL在WHERE子句中選擇IN與LIKE

SELECT field1, field2, field3, field4 
FROM MyTable 
WHERE field5 LIKE '%AL'

與

SELECT field1, field2, field3, field4 
FROM MyTable 
WHERE field5 IN ('AAL', 'IAL')

，或不作任何區別？

來源

2011-05-02 itabashi

你自己嘗試看看？通常這並不重要，但我相信LIKE會變得更慢，因爲它不是一個簡單的等價測試。 – 2011-05-02 00:37:30

我也投「你試過嗎」？ – MatBailie 2011-05-02 01:07:28

您的里程可能會有所不同，但第二個應該更快，因爲它是兩個索引支持的查找，而不是全索引掃描。在field5上沒有索引的情況下，應該無關緊要（兩種情況都是全表掃描）。

來源

2011-05-02 00:40:12 Thilo

-1。你假設字段是索引的，但在問題中沒有跡象表明這些字段是;答案是沒有根據的。 – casperOne 2011-05-02 01:09:30

@casperOne：他沒有這樣的假設。答案涵蓋了兩種情況（帶和不帶索引），聲明如果沒有索引，則需要全表掃描，因此性能可能相同。 – MatBailie 2011-05-02 01:15:25

@Dems：我可以看到，但我認爲措辭非常具有誤導性，事後糾正自己。 – casperOne 2011-05-02 01:16:46

我肯定會測試你的平臺。一些RDBMS在IN邏輯上非常糟糕，即比你期望的要慢得多。 Mysql有這個問題，你沒有在你的問題中指定。

來源

2011-05-02 00:43:44 schemathings

真的嗎？大多數SQL（請不要調用SQL「relational」:)將簡單地將'IN'子句擴展爲'（field5 ='AAL'或field5 ='IAL'）'，如果您選擇的SQL產品無法優化那麼是時候去找一個新的！ – onedaywhen 2011-05-03 10:24:00

其他陳述取決於您選擇的RDBMS的，如果你使用的是MS SQL，這兩個語句是相同的。在性能方面

UPDATE：按照馬丁評論，上面是真實的，沒有當索引目前爲field5，這是該問題的最初假設。

來源

2011-05-02 01:05:53

-1這是不正確的。它可能是2個索引在'field5'上搜索的索引掃描。 – 2011-05-02 09:21:42

@Martin，如果有'field5'上的索引，這裏甚至不包括討論的一部分，因爲假設沒有索引，我的回答是100％正確的，請嘗試自己測試 – 2011-05-02 12:36:36

爲什麼你假設沒有索引？如果這是在其上運行的查詢的類型，那麼可能應該在該列上有索引。 – 2011-05-02 12:39:17

如果您沒有覆蓋索引（或至少是field5上的索引），那麼兩者都需要進行表掃描，因此會同樣很差。

關於查詢......第二個與WHERE field5 = 'AAL' OR field5 = 'IAL'相同，這是2個精確的值來查找（例如，可能尋找）。 LIKE和領先的通配符意味着「我不知道要找多少個值」尋求永遠不會發生

關於索引...如果您確實只有field5的索引，那麼第二個可能有2個重要的查找來獲取其餘的數據。第一個可能會忽略此索引，因爲它有一個主導通配符。因此，假設事情按我的預期行事，第二個更好。

隨着覆蓋索引，然後第二人再位無鍵查找

關於搜索參數...如果你改變IN變量，則計劃將再次發生變化。使用常量查詢更快，然後使用變量查詢，因爲使用常量前面已知這些值。

但是，你有沒有嘗試過...

來源

2011-05-02 06:47:50 gbn

+1「使用常量查詢更快，然後使用變量查詢，因爲使用常量，數據在前面已知。」好點，而且很少出現。特別是如果數據偏斜（例如95％的男性，5％的女性），這可能會產生可測量的差異。我總是會選擇常量，但只能來自非常有限的一組。否則，你最終會「發送垃圾」SQL緩存。在這種情況下，綁定變量會更好。 – Thilo 2011-05-03 01:10:04

IN比LIKE命令更快...

來源

2011-05-11 11:43:17 Deepesh

你能解釋爲什麼在這種情況下IN會比LIKE快？ – stukelly 2011-05-11 21:34:32

SQL在WHERE子句中選擇IN與LIKE

回答

相關問題