postgresql sql like: guía práctica para buscar patrones sin errores

La expresión postgresql sql like permite encontrar valores de texto que coinciden con un patrón, sin exigir que el contenido sea idéntico. Es útil para localizar nombres incompletos, códigos con una estructura conocida o direcciones que contienen cierto fragmento. La clave está en entender dónde colocar los comodines, cómo tratar los caracteres especiales y qué impacto puede tener cada búsqueda en el rendimiento.

Cómo construir un patrón que encuentre lo esperado

En PostgreSQL, el operador LIKE compara una expresión de texto con un patrón. El signo de porcentaje (%) representa cero, uno o varios caracteres; el guion bajo (_) representa exactamente un carácter. Estos símbolos forman parte del patrón y no son comodines en cualquier lugar de la consulta: deben estar dentro de la cadena que se compara.

Por ejemplo, si una tabla clientes tiene una columna nombre, la condición nombre LIKE ‘Mar%’ encuentra valores que comienzan por Mar, como Marta o Marcos. El patrón ‘%son’ encuentra textos que terminan en son, mientras que ‘%art%’ busca esa secuencia en cualquier posición. En cambio, ‘A_’ coincide con dos caracteres: una A seguida de cualquier otro carácter.

La posición de los comodines cambia tanto el resultado como el coste potencial de la operación. Una búsqueda de prefijo suele ser distinta de una búsqueda de fragmento:

• Prefijo: apellido LIKE ‘Gar%’. Busca valores que empiezan por Gar.
• Sufijo: archivo LIKE ‘%.pdf’. Busca valores que terminan en .pdf.
• Fragmento: descripcion LIKE ‘%retraso%’. Busca la palabra en cualquier posición.
• Posición fija: codigo LIKE ‘AB_7%’. Exige AB, un carácter cualquiera, 7 y luego cualquier secuencia.

Si no se incluye ningún comodín, LIKE se comporta en la práctica como una comparación exacta de texto, aunque para igualdad suele ser más claro y adecuado escribir =. Elegir una condición expresiva ayuda a que otras personas entiendan qué se pretende encontrar.

LIKE, ILIKE y la diferencia entre mayúsculas y minúsculas

LIKE distingue entre mayúsculas y minúsculas en una comparación ordinaria. Por eso, el patrón ‘ana%’ no coincide necesariamente con ‘Ana Pérez’. Cuando la búsqueda debe ignorar esa diferencia, PostgreSQL ofrece ILIKE, una extensión propia del sistema:

SELECT nombre FROM clientes WHERE nombre ILIKE ‘ana%’;

La consulta encuentra variantes como Ana, ANA o anabel al comienzo del valor, según las reglas de comparación aplicables. Para una búsqueda parcial, puede usarse ILIKE ‘%ana%’. Esta comodidad tiene una contrapartida: la consulta puede requerir una estrategia de índice diferente, especialmente cuando el patrón empieza por un comodín.

También se puede normalizar el texto de forma explícita con lower(), por ejemplo lower(nombre) LIKE ‘ana%’. Esta opción puede ser útil si la aplicación define una política estable de normalización, pero una función aplicada a la columna puede impedir el uso de un índice convencional creado sobre nombre. Para optimizarla, se puede considerar un índice de expresión sobre lower(nombre), siempre que ese patrón de consulta sea frecuente y se haya comprobado el plan de ejecución.

La sensibilidad lingüística no se reduce siempre a pasar todo a minúsculas. Las reglas de ordenación, la configuración regional y los caracteres acentuados pueden influir en las comparaciones. Si el producto debe tratar de manera concreta acentos o variantes de escritura, conviene probar casos representativos con la configuración real de la base de datos, en lugar de asumir que ILIKE resuelve toda forma de equivalencia lingüística.

Caracteres especiales y búsquedas literales

El porcentaje y el guion bajo tienen significado especial dentro de un patrón LIKE. Si el usuario busca un nombre de archivo que contiene literalmente el carácter %, una condición normal podría interpretarlo como cualquier secuencia y devolver demasiados resultados. Para tratar un carácter como literal se utiliza un carácter de escape.

PostgreSQL permite declarar ese carácter con ESCAPE. Por ejemplo, WHERE codigo LIKE ‘A!_%’ ESCAPE ‘!’ busca valores que empiezan por A seguido de un guion bajo literal y luego cualquier secuencia. El signo ! es aquí el escape: !_ representa el carácter de subrayado, no cualquier carácter. Si también se necesita buscar literalmente el propio signo de escape, se duplica en el patrón.

En aplicaciones que construyen patrones a partir de texto escrito por una persona, no basta con parametrizar la consulta SQL. La parametrización evita que el dato se interprete como código SQL, pero los caracteres % y _ siguen actuando como comodines dentro de LIKE. Si la intención es una búsqueda literal, la aplicación debe escapar esos caracteres antes de añadir los comodines que necesita la funcionalidad.

Una estrategia sencilla consiste en definir un carácter de escape fijo, reemplazar primero ese carácter por una versión escapada y después escapar % y _. El orden importa: si se escapa el carácter de escape al final, también podría modificarse el propio texto añadido durante el proceso. La implementación concreta depende del lenguaje de la aplicación; lo esencial es separar dos tareas distintas: proteger la consulta SQL y conservar la semántica literal del texto buscado.

Rendimiento: el comodín inicial cambia el escenario

Una condición como nombre LIKE ‘Mar%’ puede aprovechar un índice B-tree en circunstancias adecuadas, porque el comienzo del valor está definido. El resultado depende del tipo de índice, la intercalación y la configuración de PostgreSQL. Si la base usa una intercalación que no permite esa optimización, puede ser necesario un índice con una clase de operadores apropiada, como text_pattern_ops. No conviene añadirlo por rutina: primero hay que confirmar que la consulta importa y revisar el plan con EXPLAIN.

En cambio, una condición como nombre LIKE ‘%mar%’ no fija el inicio del texto. Un índice B-tree corriente normalmente no permite saltar directamente a los valores coincidentes, por lo que la base puede examinar muchas filas. En una tabla pequeña quizá no importe; en una tabla de millones de registros y consultas frecuentes, puede convertirse en un cuello de botella.

Para búsquedas de fragmentos, PostgreSQL puede trabajar con índices trigram de la extensión pg_trgm. Un índice GIN o GiST basado en trigrams puede acelerar patrones LIKE e ILIKE que contienen una secuencia suficientemente informativa. La mejora no es automática para todos los patrones: una cadena muy corta aporta pocos trigramas y puede seguir obligando a revisar muchos candidatos. Además, el índice ocupa espacio y añade trabajo a las escrituras.

Antes de cambiar índices, una revisión práctica debería considerar:

• Cuántas filas y cuántas coincidencias devuelve la consulta.
• Si el patrón empieza con %, o si es una búsqueda de prefijo.
• La frecuencia de lectura frente a la frecuencia de inserciones y actualizaciones.
• El plan que muestra EXPLAIN (ANALYZE, BUFFERS) con datos representativos.
• El coste de almacenamiento y mantenimiento del índice propuesto.

El plan debe probarse con parámetros y volumen parecidos a los de producción. Una consulta que responde rápido con cien filas de prueba puede comportarse de otra manera cuando la tabla crece o la distribución de valores cambia.

Parámetros, NULL y otros errores comunes

Los patrones deben pasarse como parámetros, no concatenarse directamente en el texto SQL. En una consulta parametrizada, la aplicación puede enviar el patrón completo como valor. Por ejemplo, para una búsqueda de prefijo, se puede construir el valor Mar% en la aplicación y asociarlo a un parámetro de la consulta. Así se evitan problemas de inyección SQL y de comillas, aunque la aplicación todavía debe decidir si admite comodines escritos por el usuario.

Un error frecuente es esperar que LIKE encuentre una cadena en una columna cuyo valor es NULL. Una comparación con NULL no resulta verdadera ni falsa en el sentido habitual: produce un valor desconocido, y la fila no pasa el filtro del WHERE. Si se deben incluir filas sin dato, hay que expresarlo aparte, por ejemplo con nombre IS NULL OR nombre LIKE ‘Mar%’. Esta decisión debe responder a la lógica del negocio; incluir los valores desconocidos no equivale a que coincidan con el patrón.

Otro problema aparece al escribir una búsqueda de prefijo sin el comodín final o al ponerlo en el lado equivocado. nombre LIKE ‘Mar%’ busca al comienzo; nombre LIKE ‘%Mar’ busca al final. También es habitual usar ‘%texto%’ para todo, aunque el requisito solo pida coincidencias iniciales. Evitar comodines innecesarios puede mejorar la claridad y permitir planes más eficientes.

Por último, no debe confundirse LIKE con una búsqueda lingüística avanzada. LIKE resulta apropiado para patrones simples y controlados. Si se necesitan relevancia, stemming, tolerancia a errores tipográficos o búsqueda por términos, las capacidades de búsqueda de texto completo de PostgreSQL u otra estrategia pueden encajar mejor. Forzar LIKE para cubrir esos casos suele generar consultas difíciles de mantener y resultados que no se ajustan a lo que espera el usuario.

Una decisión práctica para cada tipo de búsqueda

Para filtrar por un comienzo conocido, usa LIKE ‘prefijo%’ y comprueba si un índice B-tree puede atender la consulta. Para ignorar mayúsculas y minúsculas, considera ILIKE o una normalización coherente acompañada del índice correspondiente. Para localizar una secuencia en cualquier parte del texto, acepta que un B-tree común puede no bastar y evalúa pg_trgm con mediciones reales.

Si el patrón procede de una persona, define si los símbolos % y _ deben funcionar como comodines o tratarse literalmente. Parametriza siempre los valores y escapa los caracteres cuando la búsqueda deba ser literal. Después, valida los casos límite: texto vacío, caracteres especiales, acentos, valores NULL y patrones muy cortos.

Usar postgresql sql like de forma fiable no consiste solo en recordar dos comodines. Consiste en expresar con precisión qué coincidencia se busca y elegir una estrategia que siga siendo razonable con los datos reales. Empieza por un patrón claro, mide la consulta con EXPLAIN y añade índices especializados únicamente cuando el volumen y el uso justifiquen su coste.