A veces, un pequeño detalle en una consulta puede marcar una gran diferencia en rendimiento o consumo de recursos.
Como DBAs y desarrolladores, todos compartimos el mismo objetivo: que las aplicaciones sean estables y rápidas.
En este artículo repasamos algunos ejemplos reales que pueden causar problemas de rendimiento en SQL Server y cómo prevenirlos con buenas prácticas simples.
1. Evitar SELECT *. Una de las buenas prácticas más conocidas.
La primar de las buenas prácticas es el uso de SELECT *. Parece inofensivo, pero tiene efectos negativos:
- Devuelve columnas que no se necesitan, aumentando el tráfico de red.
- Rompe la compatibilidad si la tabla cambia (por ejemplo, se agregan columnas).
- Impide que el optimizador reutilice planes de ejecución eficientemente.
Veamos unos ejemplos
Ejemplo no recomendado:
SELECT * FROM Clientes WHERE Activo = 1;Ejemplo recomendado:
SELECT IdCliente, Nombre, Correo FROM Clientes WHERE Activo = 1;Al especificar las columnas, SQL Server puede generar planes más eficientes y enviar solo los datos necesarios a la aplicación.
2. Cuidado con los tipos de datos en variables y parámetros
Este es uno de los errores más comunes y también uno de los más costosos.
Cuando en el código de aplicación o en un procedimiento almacenado se usa un tipo distinto al de la columna (por ejemplo, declarar NVARCHAR(4000) cuando en la tabla es VARCHAR(10)), SQL Server debe convertir implícitamente todos los valores antes de comparar.
Esto impide el uso de índices y genera un table scan, lo que puede ser devastador en tablas con millones de registros.
Ejemplo:
Ejemplo problemático
DECLARE @codigo NVARCHAR(4000) = 'A123';
SELECT * FROM Clientes WHERE Codigo = @codigo;Si Clientes.Codigo es VARCHAR(10), SQL Server tendrá que convertir la columna en cada fila antes de comparar. Eso obliga a recorrer toda la tabla (full scan).
Ejemplo correcto
DECLARE @codigo VARCHAR(10) = 'A123';
SELECT * FROM Clientes WHERE Codigo = @codigo;Es recomendable asegurarse de que los tipos de datos de las variables, parámetros y columnas coincidan exactamente.
3.Evitar funciones sobre columnas en filtros (WHERE)
Cuando aplicas funciones sobre una columna indexada dentro de la cláusula WHERE, el índice deja de ser útil, porque SQL Server debe evaluar la función fila por fila.
Ejemplo:
El índice sobre FechaRegistro no se usará
SELECT * FROM Ventas
WHERE YEAR(FechaRegistro) = 2025;Usa un rango para mantener el filtro sargable
SELECT * FROM Ventas
WHERE FechaRegistro >= '2025-01-01' AND FechaRegistro < '2026-01-01';En el segundo caso, SQL Server puede hacer seek directamente sobre el índice de FechaRegistro, reduciendo el costo de lectura drásticamente.
4.Cuidado al usar variables en lugar de parámetros
Cuando asignas un valor a una variable dentro de la misma consulta, SQL Server no puede estimar correctamente cuántas filas devolverá y genera un plan de ejecución genérico.
Ejemplo:
El optimizador no conoce la selectividad del valor
DECLARE @categoria INT = 5;
SELECT * FROM Productos WHERE CategoriaId = @categoria;Usa un parámetro de procedimiento almacenado o sp_executesql
EXEC sp_executesql
N'SELECT * FROM Productos WHERE CategoriaId = @categoria',
N'@categoria INT',
@categoria = 5;Los parámetros permiten a SQL Server obtener estadísticas precisas del valor y generar un plan más óptimo.
5. Revisa la fragmentación e índices no usados
Los índices ayudan al rendimiento, pero con el tiempo pueden fragmentarse o quedar en desuso.
Antes de reconstruirlos, es útil verificar cuáles realmente se utilizan.
Query para detectar índices poco usados:
SELECT
OBJECT_NAME(i.object_id) AS Tabla,
i.name AS Indice,
ius.user_seeks, ius.user_scans, ius.user_lookups, ius.user_updates
FROM sys.indexes AS i
LEFT JOIN sys.dm_db_index_usage_stats AS ius
ON i.object_id = ius.object_id AND i.index_id = ius.index_id
WHERE OBJECTPROPERTY(i.object_id, 'IsUserTable') = 1
ORDER BY ius.user_seeks + ius.user_scans ASC;Si un índice tiene cero lecturas (user_seeks, user_scans) pero muchas escrituras (user_updates), probablemente sea candidato para eliminarlo o reestructurarlo.
Aplica estas buenas prácticas
SQL Server es una herramienta poderosa, pero sensible a los detalles. Cuidar pequeños aspectos como los tipos de datos, la forma de filtrar o el uso de índices puede marcar la diferencia entre una consulta que tarda milisegundos y una que bloquea toda la base.
El objetivo no es señalar errores, sino construir código más eficiente, mantenible y predecible.
Con buenas prácticas y un poco de atención, se evitan grandes problemas de rendimiento.
Si quieres que revisemos tu entorno SQL Server, contacta con nosotros sin compromiso.
¿Aún no conoces Query Performance? Descubre cómo puede ayudarte en tu entorno Oracle. Más información en su página de LinkedIn.
Sígue a GPS en LinkedIn