Nivel 4 · Encuentra a los clientes de Gmail

= necesita que coincida el valor completo. LIKE busca un patrón:

comodín	coincide con
%	cualquier cantidad de caracteres, incluso ninguno
_	exactamente un carácter

WHERE name LIKE '%Lamp%'      -- contains "Lamp"
WHERE name LIKE 'Oak%'        -- starts with "Oak"
WHERE email LIKE '%@gmail.com' -- ends with "@gmail.com"

Sin ningún comodín, LIKE se comporta como =.

La distinción de mayúsculas cambia según la base de datos

• Postgres, DuckDB, BigQuery: LIKE distingue mayúsculas. 'Megan@Gmail.com' LIKE '%@gmail.com' es falso.
• MySQL: no distingue mayúsculas por defecto (depende de la intercalación de la columna).
• Postgres y DuckDB también tienen ILIKE, un LIKE sin distinción de mayúsculas. MySQL y BigQuery no lo tienen.

La solución portable es pasar la columna a minúsculas y escribir el patrón en minúsculas:

WHERE LOWER(email) LIKE '%@gmail.com'

Esto filtra con el valor en minúsculas pero sigue devolviendo email exactamente como está guardado, porque la lista de SELECT usa la columna original.

Por qué importa

El texto que escriben los clientes es desordenado. Los datos de Harbor & Pine tienen correos con mayúsculas y nombres de ciudad con mayúsculas y espacios raros, igual que los CRM reales. Si filtras con un patrón que distingue mayúsculas, cuentas de menos y nadie lo nota porque la consulta no dio error. Un buen hábito: cuando un filtro de texto es parte de un número sobre el que alguien actuará, compara el conteo con y sin LOWER(). Si difieren, menciónalo.

En este conjunto de datos la diferencia es real: un email LIKE '%@gmail.com' que distingue mayúsculas se pierde a un cliente cuya dirección se escribió en mayúsculas. Una fila suena trivial, pero el mismo hábito en una tabla de un millón de filas pierde miles.

Los comodines al inicio son lentos

LIKE 'Oak%' puede usar un índice sobre una columna ordenada. LIKE '%lamp%' no puede, porque la coincidencia podría empezar en cualquier parte, así que la base de datos recorre cada fila. En una tabla de 2,000 filas no lo notarás. En una tabla de eventos de mil millones de filas sí. Los motores columnares como DuckDB y BigQuery recorren todo de todos modos, así que allí importa menos.

Errores comunes

• Olvidar el %: LIKE '@gmail.com' solo coincide con la cadena exacta @gmail.com.
• Coincidir de forma demasiado laxa: LIKE '%gmail%' también atrapa notgmail.co. Ancla el patrón tan estrictamente como lo permita la pregunta.
• Buscar un % o _ literal. Necesitan escape, por ejemplo LIKE '%10\%%' ESCAPE '\'.

En SQL Server

% y _ funcionan igual, pero la intercalación por defecto no distingue mayúsculas, así que LIKE '%@gmail.com' ya coincide con ‘@Gmail.com’ y no hay ILIKE. SQL Server también admite clases de caracteres entre corchetes, y usa LEN donde DuckDB usa LENGTH:

WHERE last_name LIKE '[A-M]%'      -- starts with A to M
  AND LEN(first_name) = 5