LIKE — Referencia de SQL en Marketing Cloud

LIKE es cómo matcheás patrones de texto adentro de un WHERE. En MC SQL funciona como T-SQL: % matchea cualquier secuencia (incluso vacía), _ matchea exactamente un caracter, las comparaciones son case-insensitive en la mayoría de los tenants. La trampa es performance — una query con un % inicial no puede usar índice, así que lo que corre instantáneamente contra 10k filas se arrastra contra 1M.

Sintaxis oficial

-- Wildcards: % (cualquier secuencia) y _ (exactamente un caracter)
WHERE EmailAddress LIKE '%@enterprise.com'        -- termina con
WHERE EmailAddress LIKE 'german.%'                -- empieza con
WHERE EmailAddress LIKE '%@%.gov'                 -- contiene @ + termina con .gov
WHERE EmailAddress LIKE 'g_rman@%'                -- wildcard de un solo caracter

-- NOT LIKE para el inverso
WHERE EmailAddress NOT LIKE '%@%.test'

-- ESCAPE para literal % o _
WHERE Topic LIKE '50\% off%' ESCAPE '\'
WHERE FieldName LIKE 'user\_id' ESCAPE '\'

-- Combinado con otras condiciones de WHERE
WHERE Status = 'Active'
  AND EmailAddress LIKE '%@enterprise.com'
  AND LastPurchase >= DATEADD(day, -90, GETDATE())

LIKE solo opera sobre columnas de texto (varchar / nvarchar). Comparar fechas o números requiere CAST primero — y a esa altura generalmente querés = o una comparación de rango en su lugar.

Referencia:

• Salesforce Help — Sintaxis T-SQL soportada ↗
• Salesforce Help — Queries SQL para Data Views (ejemplos de filtrado) ↗

Lo que sobrevive en producción

Los wildcards iniciales matan la performance

LIKE 'prefix%' puede usar un índice sobre la columna (si existe uno). LIKE '%suffix' y LIKE '%substring%' no — tienen que escanear cada fila. Sobre un Data Extension de 50k filas es invisible. Sobre un DE de 5M empujando el timeout de 30 min, es la diferencia entre éxito y falla de la Activity.

-- RÁPIDO — prefijo anclado, el optimizer puede usar índice sobre EmailAddress
WHERE EmailAddress LIKE 'support@%'

-- LENTO — wildcard inicial fuerza un full scan
WHERE EmailAddress LIKE '%@enterprise.com'

-- PEOR — wildcards en ambos lados, full scan + match caracter por caracter
WHERE EmailAddress LIKE '%enterprise%'

No siempre podés evitar wildcards iniciales (matchear dominios de email, por ejemplo, requiere LIKE '%@domain.com'). Cuando no podés evitarlo, stagéa el filtro primero — corré el LIKE contra un DE stagéado más chico al que ya le aplicaste filtros más baratos (Status = 'Active', rangos de fecha) así el scan caro toca una fracción de las filas.

No uses LIKE cuando = funcionaría

LIKE 'gold' es idéntico en resultado a = 'gold' pero más lento — el optimizer trata LIKE como pattern matching incluso cuando no hay wildcards. Si la comparación es un match exacto contra un literal, usá =.

-- EN RIESGO — LIKE sin wildcards es solo un = lento
WHERE LoyaltyTier LIKE 'gold'

-- CORRECTO
WHERE LoyaltyTier = 'gold'

El costo es chico por fila, pero compoundea — cada fila del DE de origen paga el overhead de pattern-matching, aún cuando la respuesta es solo un check de igualdad de string.

Escapeá % y _ cuando matcheás texto literal

Si estás buscando un string que contiene un % o _ literal, el significado de wildcard se impone salvo que escapes. Elegí un caracter ESCAPE (comúnmente \) y prefijá.

-- BUG — % se interpreta como wildcard, matchea todo lo que empieza con "50"
WHERE Subject LIKE '50% off%'

-- CORRECTO — \% es el signo de porcentaje literal
WHERE Subject LIKE '50\% off%' ESCAPE '\'

-- También para underscores en nombres de campo o códigos
WHERE FieldName LIKE 'user\_id' ESCAPE '\'

Esto aparece más seguido cuando matcheás subjects de email, códigos promocionales, o nombres de variables AMPscript — donde sea que % o _ aparezcan en datos reales.

LIKE para patrones de supresión: stagéa y reusá

La supresión por dominio ("nunca le mandes email a nadie en @competitor.com") es un patrón LIKE '%@competitor.com'. No lo corras adentro de cada query de producción — stagéa una vez, reusá el DE stagéado.

-- EN RIESGO — LIKE corre contra la lista de subscribers completa cada send
SELECT s.SubscriberKey
FROM master_subscribers s
WHERE s.Status = 'Active'
  AND s.EmailAddress NOT LIKE '%@competitor.com'
  AND s.EmailAddress NOT LIKE '%@partner-private.com';

-- DURABLE — stagéa direcciones suprimidas una vez, después anti-join
INSERT INTO de_stg_domain_suppressed
SELECT SubscriberKey
FROM master_subscribers
WHERE EmailAddress LIKE '%@competitor.com'
   OR EmailAddress LIKE '%@partner-private.com';

SELECT s.SubscriberKey
FROM master_subscribers s
LEFT JOIN de_stg_domain_suppressed d
  ON s.SubscriberKey = d.SubscriberKey
WHERE s.Status = 'Active'
  AND d.SubscriberKey IS NULL;

La primera versión paga el costo de LIKE en cada Send. La segunda lo paga una vez por corrida de snapshot, después cada Send es un anti-join rápido. Ver JOIN para el patrón anti-join.

Decisión rápida

Usá LIKE cuando:

• Estás matcheando un patrón de texto, no un valor exacto.
• Podés anclar el wildcard a un lado (matching de prefijo o sufijo).
• El dato es lo bastante chico como para que el costo del scan sea aceptable.

Usá = en lugar de LIKE cuando:

• El patrón no tiene wildcards. Siempre.

Usá LEFT JOIN ... IS NULL en lugar de NOT LIKE cuando:

• Estás suprimiendo muchos patrones y la fuente es grande. Stagéa la lista de supresión una vez.

Usá LIKE con cuidado cuando:

• El patrón empieza con wildcard (%suffix, %substring%) — stagéa filtros aguas arriba primero.
• El dato contiene % o _ literal — usá ESCAPE.
• La query tiene que funcionar entre tenants con sensibilidad al case potencialmente diferente — envolvé en LOWER().

Relacionado

• Basics — subset de T-SQL soportado
• WHERE — LIKE vive adentro de WHERE
• JOIN — patrón anti-join para supresión a escala
• MC SQL gotchas — ver #5 para sensibilidad al case / comportamiento NULL

Próximas páginas de referencia: CASE · INSERT INTO · String / Date / Numeric / Conversion / Aggregate / Null Functions · Style Guide.

Más snippets how-to para debugging común en producción — sends de email, largo de valores, alcance de contactos, etc.