Cómo mejorar la performance de tus queries en SFMC con subqueries SARGables

Spoiler: Sí, SFMC puede llorar menos si le hablas bonito… y SARGable.

¿Qué es SARGabilidad?

SARG (Search ARGument-able) es una característica de las consultas SQL que permite que los motores de base de datos usen índices de manera eficiente. Si haces cosas como WHERE FUNCTION(CAMPO) = valor, te cargas el índice. Y SFMC, que ya de por sí anda sensible, se te cae de la silla.

El problema clásico

Una consulta común para reportes mensuales podría verse así:

WHERE DateJoined >= DATEADD(MONTH, -12, GETDATE())

¿El problema? DATEADD(MONTH, -12, GETDATE()) se evalúa por fila, y eso impide que SQL use índices sobre DateJoined.

La solución: precalcular la fecha con una subquery

Como SFMC a veces no permite WITH (CTEs), puedes resolverlo con una subconsulta en el JOIN:

INNER JOIN (
    SELECT CAST(DATEADD(MONTH, -12, GETDATE()) AS DATE) AS MinDate
) d ON s.DateJoined >= d.MinDate

Tu query completa podría quedar así:

SELECT
    FORMAT(s.DateJoined, 'yyyyMM') AS MonthYear,
    s.Brand_Code,
    COUNT(*) AS Subscribers
FROM
    ent._Subscribers s
INNER JOIN (
    SELECT CAST(DATEADD(MONTH, -12, GETDATE()) AS DATE) AS MinDate
) d ON s.DateJoined >= d.MinDate
GROUP BY
    FORMAT(s.DateJoined, 'yyyyMM'),
    s.Brand_Code

Bonus de la casa: evitar hasheos innecesarios

Si usas tablas que requieren matching por SHA256, considera crear una columna con el email en texto plano (o el dato necesario) para evitar re-hashear cada vez que corres la query. Esto mejora enormemente la performance, especialmente en automations.

-- Antes
ON CONVERT(NVARCHAR(64), HASHBYTES('SHA2_256', ...)) = EMAILHASH

-- Después
ON s.Email = ldb.EmailPlain

En resumen:

– SFMC tiene limitaciones, pero también formas de optimizar si entiendes su lógica.

– No abuses de funciones dentro de tus WHERE o JOIN.

– Usa subqueries como si fueran tu mejor truco de magia backend.

– Y si puedes evitar el hash, evita el hash.