Equals(=) vs. LIKE

后端 未结 15 2040
情书的邮戳
情书的邮戳 2020-11-22 15:19

When using SQL, are there any benefits of using = in a WHERE clause instead of LIKE?

Without any special operators, LIKE

相关标签:
15条回答
  • 2020-11-22 15:35

    Besides the wildcards, the difference between = AND LIKE will depend on both the kind of SQL server and on the column type.

    Take this example:

    CREATE TABLE testtable (
      varchar_name VARCHAR(10),
      char_name CHAR(10),
      val INTEGER
    );
    
    INSERT INTO testtable(varchar_name, char_name, val)
        VALUES ('A', 'A', 10), ('B', 'B', 20);
    
    SELECT 'VarChar Eq Without Space', val FROM testtable WHERE varchar_name='A'
    UNION ALL
    SELECT 'VarChar Eq With Space', val FROM testtable WHERE varchar_name='A '
    UNION ALL
    SELECT 'VarChar Like Without Space', val FROM testtable WHERE varchar_name LIKE 'A'
    UNION ALL
    SELECT 'VarChar Like Space', val FROM testtable WHERE varchar_name LIKE 'A '
    UNION ALL
    SELECT 'Char Eq Without Space', val FROM testtable WHERE char_name='A'
    UNION ALL
    SELECT 'Char Eq With Space', val FROM testtable WHERE char_name='A '
    UNION ALL
    SELECT 'Char Like Without Space', val FROM testtable WHERE char_name LIKE 'A'
    UNION ALL
    SELECT 'Char Like With Space', val FROM testtable WHERE char_name LIKE 'A '
    
    • Using MS SQL Server 2012, the trailing spaces will be ignored in the comparison, except with LIKE when the column type is VARCHAR.

    • Using MySQL 5.5, the trailing spaces will be ignored for =, but not for LIKE, both with CHAR and VARCHAR.

    • Using PostgreSQL 9.1, spaces are significant with both = and LIKE using VARCHAR, but not with CHAR (see documentation).

      The behaviour with LIKE also differs with CHAR.

      Using the same data as above, using an explicit CAST on the column name also makes a difference:

      SELECT 'CAST none', val FROM testtable WHERE char_name LIKE 'A'
      UNION ALL
      SELECT 'CAST both', val FROM testtable WHERE
          CAST(char_name AS CHAR) LIKE CAST('A' AS CHAR)
      UNION ALL
      SELECT 'CAST col', val FROM testtable WHERE CAST(char_name AS CHAR) LIKE 'A'
      UNION ALL
      SELECT 'CAST value', val FROM testtable WHERE char_name LIKE CAST('A' AS CHAR)
      

      This only returns rows for "CAST both" and "CAST col".

    0 讨论(0)
  • 2020-11-22 15:35

    The LIKE keyword undoubtedly comes with a "performance price-tag" attached. That said, if you have an input field that could potentially include wild card characters to be used in your query, I would recommend using LIKE only if the input contains one of the wild cards. Otherwise, use the standard equal to comparison.

    Best regards...

    0 讨论(0)
  • 2020-11-22 15:35

    In Oracle, a ‘like’ with no wildcards will return the same result as an ‘equals’, but could require additional processing. According to Tom Kyte, Oracle will treat a ‘like’ with no wildcards as an ‘equals’ when using literals, but not when using bind variables.

    0 讨论(0)
  • 2020-11-22 15:42

    LIKE and = are different. LIKE is what you would use in a search query. It also allows wildcards like _ (simple character wildcard) and % (multi-character wildcard).

    = should be used if you want exact matches and it will be faster.

    This site explains LIKE

    0 讨论(0)
  • 2020-11-22 15:44

    Really it comes down to what you want the query to do. If you mean an exact match then use =. If you mean a fuzzier match, then use LIKE. Saying what you mean is usually a good policy with code.

    0 讨论(0)
  • 2020-11-22 15:45

    To address the original question regarding performance, it comes down to index utilization. When a simple table scan occurs, "LIKE" and "=" are identical. When indexes are involved, it depends on how the LIKE clause is formed. More specifically, what is the location of the wildcard(s)?


    Consider the following:

    CREATE TABLE test(
        txt_col  varchar(10) NOT NULL
    )
    go
    
    insert test (txt_col)
    select CONVERT(varchar(10), row_number() over (order by (select 1))) r
      from master..spt_values a, master..spt_values b
    go
    
    CREATE INDEX IX_test_data 
        ON test (txt_col);
    go 
    
    --Turn on Show Execution Plan
    set statistics io on
    
    --A LIKE Clause with a wildcard at the beginning
    DBCC DROPCLEANBUFFERS
    SELECT txt_Col from test where txt_col like '%10000'
    --Results in
    --Table 'test'. Scan count 3, logical reads 15404, physical reads 2, read-ahead reads 15416, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    --Index SCAN is 85% of Query Cost
    
    --A LIKE Clause with a wildcard in the middle
    DBCC DROPCLEANBUFFERS
    SELECT txt_Col from test where txt_col like '1%99'
    --Results in
    --Table 'test'. Scan count 1, logical reads 3023, physical reads 3, read-ahead reads 3018, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    --Index Seek is 100% of Query Cost for test data, but it may result in a Table Scan depending on table size/structure
    
    --A LIKE Clause with no wildcards
    DBCC DROPCLEANBUFFERS
    SELECT txt_Col from test where txt_col like '10000'
    --Results in
    --Table 'test'. Scan count 1, logical reads 3, physical reads 2, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    --Index Seek is 100% of Query Cost
    GO
    
    --an "=" clause = does Index Seek same as above
    DBCC DROPCLEANBUFFERS
    SELECT txt_Col from test where txt_col = '10000'
    --Results in
    --Table 'test'. Scan count 1, logical reads 3, physical reads 2, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    --Index Seek is 100% of Query Cost
    GO
    
    
    DROP TABLE test
    

    There may be also negligible difference in the creation of the query plan when using "=" vs "LIKE".

    0 讨论(0)
提交回复
热议问题