SQL 'like' vs '=' rendimiento

Esta pregunta bordea lo que me pregunto, pero las respuestas no lo abordan exactamente.

Parecería que, en general, '=' es más rápido que 'me gusta' cuando se utilizan comodines. Esta parece ser la sabiduría convencional. Sin embargo, supongamos que tengo una columna que contiene un número limitado de diferentes identificadores varchar fijos, codificados, y quiero seleccionar todas las filas que coincidan con uno de ellos:

select * from table where value like 'abc%'

y

select * from table where value = 'abcdefghijklmn'

'Me gusta' solo debería necesitar probar los primeros tres caracteres para encontrar una coincidencia, mientras que '=' debe comparar toda la cadena. En este caso, me parecería que "me gusta" tendría una ventaja, en igualdad de condiciones.

Esto está pensado como una pregunta académica general, por lo que no debería importar qué base de datos, pero surgió con SQL Server 2005.

Ver https://web.archive.org/web/20150209022016/http://myitforum.com/cs2/blogs/jnelson/archive/2007/11/16/108354.aspx

Cita desde allí:

las reglas para el uso de índices con LIKE son vagamente así:

• Si su criterio de filtro usa igual a = y el campo está indexado, lo más probable es que use una BÚSQUEDA DE ÍNDICE / ÍNDICE CLUSTER

• Si su criterio de filtro usa LIKE, sin comodines (como si tuviera un parámetro en un informe web que PODRÍA tener un%, pero en su lugar usa la cadena completa), es tan probable que el # 1 use el índice. El aumento de costo es casi nada.

• Si su criterio de filtro usa LIKE, pero con un comodín al principio (como en Name0 LIKE '% UTER'), es mucho menos probable que use el índice, pero aún puede realizar al menos un ESCANEO DE ÍNDICE en un rango completo o parcial de El índice.

• SIN EMBARGO, si su criterio de filtro usa LIKE, pero comienza con una STRING FIRST y tiene comodines en algún lugar DESPUÉS de eso (como en Name0 LIKE 'COMP% ER'), entonces SQL puede usar INDEX SEEK para encontrar rápidamente filas que tengan lo mismo primero caracteres iniciales y luego busque en esas filas una coincidencia exacta.

(También tenga en cuenta que es posible que el motor SQL todavía no use un índice de la forma que espera, dependiendo de qué más está sucediendo en su consulta y a qué tablas se está uniendo. El motor SQL se reserva el derecho de reescribir su consulta un poco para obtener los datos de la manera que crea que es más eficiente y que puede incluir un INDEX SCAN en lugar de una INDEX SEEK)

Es una diferencia medible.

Ejecute lo siguiente:

Create Table #TempTester (id int, col1 varchar(20), value varchar(20))
go

INSERT INTO #TempTester (id, col1, value)
VALUES
(1, 'this is #1', 'abcdefghij')
GO

INSERT INTO #TempTester (id, col1, value)
VALUES
(2, 'this is #2', 'foob'),
(3, 'this is #3', 'abdefghic'),
(4, 'this is #4', 'other'),
(5, 'this is #5', 'zyx'),
(6, 'this is #6', 'zyx'),
(7, 'this is #7', 'zyx'),
(8, 'this is #8', 'klm'),
(9, 'this is #9', 'klm'),
(10, 'this is #10', 'zyx')
GO 10000

CREATE CLUSTERED INDEX ixId ON #TempTester(id)CREATE CLUSTERED INDEX ixId ON #TempTester(id)

CREATE NONCLUSTERED INDEX ixTesting ON #TempTester(value)

Entonces:

SET SHOWPLAN_XML ON

Entonces:

SELECT * FROM #TempTester WHERE value LIKE 'abc%'

SELECT * FROM #TempTester WHERE value = 'abcdefghij'

El plan de ejecución resultante le muestra que el costo de la primera operación, la LIKEcomparación, es aproximadamente 10 veces más caro que la =comparación.

Si puede utilizar una =comparación, hágalo.

También debe tener en cuenta que, al usar like, algunos tipos de SQL ignorarán los índices y eso matará el rendimiento. Esto es especialmente cierto si no usa el patrón "comienza con" como en su ejemplo.

Realmente debería mirar el plan de ejecución de la consulta y ver qué está haciendo, adivinar lo menos posible.

Dicho esto, el patrón "comienza con" puede y está optimizado en el servidor SQL. Se va a utilizar el índice de la tabla. EF 4.0 cambió a likepara StartsWithpor esta misma razón.

Si valueno está indexado, ambos dan como resultado un escaneo de tabla. La diferencia de rendimiento en este escenario será insignificante.

Si valueestá indexado, como señala Daniel en su comentario, =dará como resultado una búsqueda de índice que es el rendimiento O (log N). El LIKE (lo más probable, dependiendo de qué tan selectivo sea) dará como resultado un escaneo parcial del índice >= 'abc'y < 'abd'requerirá más esfuerzo que el =.

Tenga en cuenta que estoy hablando de SQL Server aquí, no todos los DBMS serán buenos con LIKE.

Estás haciendo la pregunta incorrecta. En las bases de datos no es el rendimiento del operador lo que importa, es siempre la SARGability de la expresión y la cobertura de la consulta general. El desempeño del propio operador es en gran parte irrelevante.

Entonces, ¿cómo comparar LIKEy =comparar en términos de SARGability? LIKE, cuando se usa con una expresión que no comienza con una constante (por ejemplo, cuando se usa LIKE '%something'), por definición no es SARGabale. ¿Pero eso hace =o LIKE 'something%'SARGable? No. Al igual que con cualquier pregunta sobre el rendimiento de SQL, la respuesta no está en la consulta del texto, sino en el esquema implementado. Estas expresiones pueden ser SARGable si existe un índice para satisfacerlas.

Entonces, a decir verdad, hay pequeñas diferencias entre =y LIKE. Pero preguntar si un operador u otro operador es "más rápido" en SQL es como preguntar "¿Qué va más rápido, un coche rojo o un coche azul?". Debería hacer preguntas sobre el tamaño del motor y el peso del vehículo, no sobre el color ... Para abordar las preguntas sobre la optimización de tablas relacionales, el lugar para buscar son sus índices y sus expresiones en la cláusula WHERE (y otras cláusulas, pero generalmente comienza con el DÓNDE).

Un ejemplo personal usando mysql 5.5: tenía una combinación interna entre 2 tablas, una de 3 millones de filas y una de 10 mil filas.

Al usar un me gusta en un índice como se muestra a continuación (sin comodines), tomó aproximadamente 30 segundos:

where login like '12345678'

usando 'explicar' obtengo:

Al usar un '=' en la misma consulta, tomó alrededor de 0.1 segundos:

where login ='600009'

Usando 'explicar' obtengo:

Como puede ver, la likebúsqueda de índice canceló por completo, por lo que la consulta tomó 300 veces más tiempo.

Quizás esté buscando una búsqueda de texto completo .

A diferencia de la búsqueda de texto completo, el predicado LIKE Transact-SQL solo funciona en patrones de caracteres. Además, no puede utilizar el predicado LIKE para consultar datos binarios formateados. Además, una consulta LIKE contra una gran cantidad de datos de texto no estructurados es mucho más lenta que una consulta equivalente de texto completo contra los mismos datos . Una consulta LIKE contra millones de filas de datos de texto puede tardar minutos en devolverse; mientras que una consulta de texto completo puede tomar solo unos segundos o menos con los mismos datos, dependiendo del número de filas que se devuelvan.

Lo primero es lo primero ,

no siempre son iguales

    select 'Hello' from dual where 'Hello  ' like 'Hello';

    select 'Hello' from dual where 'Hello  ' =  'Hello';

cuando las cosas no siempre son iguales, hablar de su desempeño no es tan relevante.

Si está trabajando con cadenas y solo variables de caracteres, puede hablar sobre el rendimiento. Pero no use like y "=" como si fueran generalmente intercambiables.

Como habrá visto en muchas publicaciones (anteriores y otras preguntas), en los casos en que son iguales, el rendimiento de Me gusta es más lento debido a la coincidencia de patrones (intercalación)