l'opérateur equals ( = ) est un "opérateur de comparaison compare deux valeurs pour l'égalité."En d'autres termes, dans un énoncé SQL, il ne retournera pas vrai à moins que les deux côtés de l'équation sont égaux. Par exemple:

SELECT * FROM Store WHERE Quantity = 200;

L'opérateur LIKE "met en œuvre une correspondance de modèle de comparaison" qui essaie de faire correspondre une "chaîne de valeur par rapport à un modèle de chaîne de caractères contenant des caractères génériques."Par exemple:

SELECT * FROM Employees WHERE Name LIKE 'Chris%';

comme est généralement utilisé seulement avec des cordes et des égaux (je crois) est plus rapide. L'opérateur equals traite les caractères wild-card comme des caractères littéraux. Les différences de résultats sont les suivantes:

SELECT * FROM Employees WHERE Name = 'Chris';

et

SELECT * FROM Employees WHERE Name LIKE 'Chris';

renverrait le même résultat, bien que L'utilisation de LIKE prendrait généralement plus longtemps que son une correspondance de modèle. Toutefois,

SELECT * FROM Employees WHERE Name = 'Chris%';

et

SELECT * FROM Employees WHERE Name LIKE 'Chris%';

donnerait des résultats différents, où utiliser " = "ne donne que des résultats avec" Chris% "retourné et l'opérateur similaire retournera tout ce qui commence par"Chris".

Espère que ça aide. Quelques bonnes informations peuvent être trouvées ici .

LIKE et = sont différents. LIKE est ce que vous utiliseriez dans une requête de recherche. Il permet également les jokers comme _ (simple caractère Joker) et % (multi-caractère Joker).

= doit être utilisé si vous voulez des Correspondances exactes et il sera plus rapide.

ce site explique LIKE

ceci est une copie / pâte d'une autre de mes réponses à la question SQL 'like' vs ' = 'performance :

un exemple personnel en utilisant mysql 5.5: j'ai eu une jonction interne entre 2 tables, une de 3 millions de lignes et une de 10 000 lignes.

l'utilisation d'un tel dans un index comme ci-dessous(pas de Joker) a pris environ 30 secondes:

where login like '12345678'

à l'aide "d'expliquer" j'obtiens:

quand on utilise un ' = 'sur la même requête, cela prend environ 0.1 secondes:

where login ='12345678'

à l'Aide "d'expliquer" j'obtiens:

comme vous pouvez le voir, le like a complètement annulé la recherche d'index, donc la requête a pris 300 fois plus de temps.

une différence - en dehors de la possibilité d'utiliser des caractères génériques avec comme - est dans les espaces de fuite: l'opérateur = ignore l'espace de fuite, mais comme ne le fait pas.

Dépend du système de base de données.

généralement sans caractères spéciaux, oui, = et comme sont les mêmes.

certains systèmes de bases de données, cependant, peuvent traiter les paramètres de collation différemment des différents opérateurs.

par exemple, dans les comparaisons MySQL avec = on strings est toujours insensible à la casse par défaut, donc comme sans caractères spéciaux est le même. Sur d'autres RDBM, le genre est insensible à la casse alors que = est pas.

pour cet exemple, nous tenons pour acquis que varcharcol ne contient pas '' et n'a pas de case vide contre cette colonne

select * from some_table where varcharCol = ''
select * from some_table where varcharCol like ''

le premier résultat est 0 ligne de sortie tandis que le second affiche toute la liste. = est strictement respecter la casse, tout comme agit comme un filtre. si le filtre n'a pas de critères, toutes les données sont valides.

comme-par la vertu de son but fonctionne un peu plus lent et est destiné à être utilisé avec varchar et des données similaires.

utilisant = évite les caractères génériques et les conflits de caractères spéciaux dans la chaîne lorsque vous construisez la requête au moment de l'exécution.

cela rend la vie du programmeur plus facile en n'ayant pas à échapper à tous les caractères génériques spéciaux qui pourraient glisser dans la clause similaire et de ne pas produire le résultat prévu. Après tout, = 99% scénario de cas d'utilisation, il serait une douleur d'avoir à échapper à chaque fois.

roule des yeux à années '90

je pense aussi que c'est un peu plus lent, mais je doute que ce soit significatif s'il n'y a pas de jokers dans le motif.

pour répondre à la question initiale concernant la performance, il s'agit de utilisation de l'indice . Quand un simple scan de table se produit, "comme" et " = "sont identique . Quand les index sont impliqués, il dépend sur la façon dont la clause similaire est formée. Plus précisément, où se trouve le ou les caractères génériques?

considérer ce qui suit:

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

il peut également y avoir une différence négligeable dans la création du plan de requête en utilisant " = "vs"LIKE".

si vous recherchez une correspondance exacte, vous pouvez utiliser les deux, = et LIKE.

utiliser " = "est un tout petit peu plus rapide dans ce cas (recherche d'une correspondance exacte) - vous pouvez vérifier cela vous-même en ayant la même requête deux fois dans SQL Server Management Studio, une fois en utilisant"=", une fois en utilisant" LIKE", puis en utilisant la" requête " / "inclure plan d'exécution réelle".

exécutez les deux requêtes et vous devriez voir vos résultats deux fois, plus les deux plans d'exécution réels. Dans mon cas, ils ont été divisés 50% contre 50%, mais le plan d'exécution "=" a un plus petit "coût estimé sous-trois" (affiché lorsque vous survolez la gauche - plus "Sélectionner" boîte) - mais encore une fois, ce n'est vraiment pas une énorme différence.

mais quand vous commencez à chercher avec des caractères génériques dans votre expression similaire, la performance de recherche va diminuer. La recherche "comme Mill%" peut toujours être très rapide - SQL Server peut utiliser un index sur cette colonne, s'il y en a un. Chercher " LIKE % expression%" est horriblement lent, depuis la seule façon SQL Server peut satisfaire cette recherche est en faisant un balayage complet de la table. Alors faites attention à vos goûts !

Marc

outre les caractères génériques, la différence entre = et LIKE dépendra à la fois du type de serveur SQL et du type de colonne.

prendre cet exemple:

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 '

• en utilisant MS SQL Server 2012 , les espaces de fuite seront ignorés dans la comparaison, sauf avec LIKE lorsque le type de colonne est VARCHAR .

• en utilisant MySQL 5.5 , les espaces de fuite seront ignorés pour = , mais pas pour LIKE , à la fois avec CHAR et VARCHAR .

• utilisant PostgreSQL 9.1 , les espaces sont significatifs à la fois avec = et LIKE utilisant VARCHAR , mais pas avec CHAR (voir documentation ).

  le comportement avec LIKE diffère aussi de CHAR .

  en utilisant les mêmes données que ci-dessus, en utilisant un CAST explicite sur le nom de la colonne fait également une différence :

  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)
  

  cela renvoie seulement les lignes pour" CAST both "et"CAST col".

le même mot-clé vient sans aucun doute avec une" performance price-tag " attaché. Cela dit, si vous avez un champ d'entrée qui pourrait inclure des caractères wild card à utiliser dans votre requête, je vous recommande D'utiliser comme seulement si l'entrée contient une des cartes wild. Sinon, utilisez la norme égale à la comparaison.

meilleures salutations...

en fait, il s'agit de ce que vous voulez que la requête à faire. Si vous voulez dire une correspondance exacte puis utiliser =. Si vous voulez dire un match plus fuzzier, alors utilisez comme. Dire ce que vous entendez est généralement une bonne politique avec le code.

dans Oracle, un ‘like’ sans joker retournera le même résultat qu'un ‘equals’, mais pourrait nécessiter un traitement supplémentaire. selon Tom Kyte , Oracle traitera un "like" sans caractères génériques comme un "equals" lorsqu'il utilise des caractères littéraux, mais pas lorsqu'il utilise des variables bind.

= et LIKE n'est pas le même;

1. = correspond à la chaîne exacte
2. LIKE correspond à une chaîne qui peut contenir des caractères génériques ( % )