¿Alguna vez has sentido que tus consultas en SQL Server tardan más en ejecutarse que un lunes en llegar al viernes? ⏳💀
Pues justo me pasaba eso con un Stored Procedure (SP) que manejaba una base de datos con millones de registros, y decidí meterle mano para hacerlo volar. 🛠️⚡
Después de optimizarlo, logré estos resultados:
✔ Antes: ⏳ 21 segundos de ejecución.
✔ Después: ⚡ 13 segundos (38% más rápido).
✔ Costo de ejecución antes: ❌ 155.
✔ Costo de ejecución después: ✅ 0.04 (Sí, casi cero 😱).
🛠️ ¿Cómo lo hice?
No fue magia (aunque lo parezca 😏), sino que apliqué varias técnicas de optimización que cualquier dev de SQL puede aplicar:
✅ Tablas temporales con índices bien puestos → Para evitar escaneos innecesarios y hacer las consultas más rápidas.
✅ HASH JOINs en lugar de NESTED LOOPS → Para que SQL Server no se rompa la cabeza comparando registros.
✅ Paralelismo con MAXDOP → Para que los núcleos de la CPU trabajen en equipo y no como si fuera una chamba de un solo compa.
✅ TABLOCK en inserciones masivas → Evita bloqueos innecesarios y acelera la carga de datos.
✅ FORCESEEK y RECOMPILE → Para evitar que SQL se ponga creativo con planes de ejecución raros.
📂 Código y recursos en GitHub
Si quieres ver el código con todos los cambios, lo subí al repo de Compilatte en GitHub. Ahí puedes comparar el SP mal optimizado vs. el SP bien optimizado y ver las capturas de los resultados. 📊
📁 sp_bien_optimizado.sql → El SP optimizado.
📁 sp_mal_optimizado.sql → El SP antes de optimizar.
📁 Índices.sql → Los índices que usé.
📁 Bulk_Inserts.sql → Para cargar datos rápido.
📁 Create.sql → Creación de tablas.
📁 Capturas del costo antes y después 📷
📁 ValidacionConsistenciadeDatos.sql → Forma de validar que los datos sean los mismos en ambos SPs.
🔗 Repositorio en GitHub: Compilatte - SP Optimizado
📊 ¿Y cómo probé que de verdad funciona?
Hice las pruebas con una base de datos bien pesadita, con 4 millones de registros (pa' que no digan que era suerte 🤓).
Si quieres jugar con estos datos, aquí puedes descargar los archivos CSV y hacer tus propias pruebas:
🔗 Descargar Dataset - 4M Registros
⚡ ¿Cómo lo puedes probar tú?
Si quieres ver la magia en acción, sigue estos pasos:
1️⃣ Crea la base de datos en SQL Server:
USE master;
CREATE DATABASE PRUEBAS;
GO
2️⃣ Ejecuta Create.sql para crear las tablas.
3️⃣ Carga los datos con Bulk_Inserts.sql o importa los CSV.
4️⃣ Ejecuta sp_mal_optimizado.sql y mide cuánto tarda.
5️⃣ Ejecuta Indices.sql para meter los índices.
6️⃣ Ejecuta sp_bien_optimizado.sql y ve la diferencia.
7️⃣ Ejecuta ValidacionConsistenciadeDatos.sql y valida que en ambos SPs los datos sean los mismos.
📢 Información Importante
1️⃣ En el SP sp_bien_optimizado Se utiliza MAXDOP para mejorar la concurrencia y agilizar la consulta.
MAXDOP es una configuración que controla el número máximo de procesadores (núcleos de CPU) que SQL Server puede usar para ejecutar una consulta en paralelo.
Si tu tu PC tiene menos de 8 núcleos de CPU (por ejemplo, solo 2 o 4), SQL Server intentará usar más subprocesos de los que el sistema puede manejar eficientemente. Esto puede causar: Contención de CPU: Los subprocesos compiten por los recursos limitados de CPU, lo que genera sobrecarga y ralentiza la consulta.
Cambios de contexto excesivos: El sistema operativo tiene que cambiar constantemente entre subprocesos, lo que añade latencia. Por lo que dependiendo el entorno de trabajo deberías probar si vale la pena tenerlo de esta manera, modificarlo o eliminarlo.
2️⃣ El tiempo de ejecución de ambos sps (el mal optimizado y el bien optimizado) puede variar dependiendo el entorno (pc o servidor) donde este sea ejecutado de manera que la finalidad de este ejercicio es que se analicen las maneras comunes de bajar costos (Creación de índices, creación de tablas temporales, uso de MAXDOP, TABLOCK, RECOMPILE, TOPs, etc) y se usen aquellos que sean útiles en tu etorno de trabajo, por lo que si se usa siempre la misma configuración en diferentes entornos puede resultar contraproducente.
🎯 ¿Qué aprendimos con esto?
🚀 SQL Server no es lento, lo hacemos lento si no optimizamos bien.
📉 Bajar los tiempos de ejecución te puede ahorrar muchos dolores de cabeza y $$$ en servidores.
💡 Con las técnicas correctas, hasta el peor código puede volverse eficiente.
Así que si te late la idea de optimizar tus bases de datos y hacer que tus queries vayan full turbo, échale un ojo al repo. Y si tienes dudas o sugerencias, ¡échame un DM o comenta! 😎🔥
📬 Contacto
📧 Email: carlosfrancoc@compilatte.com
🔗 GitHub: github.com/Compilatte
💼 LinkedIn: linkedin.com/in/carlosfrancoc
🖋️ Carlos Alejandro Franco Camacho | 🚀 Compilatte - Haciendo código más eficiente y menos doloroso. 😎
