La mayoría de las empresas que trabajan con SQL Server no tienen ni la más remota idea de lo que les cuesta no optimizar sus consultas. Y no, no hablo de la típica pérdida de rendimiento que molesta al usuario de vez en cuando. Hablo de dinero. Del que se escapa cada mes por la rendija del servidor porque nadie se molestó en revisar ese SELECT con JOIN cruzado que parece escrito por un algoritmo con ganas de venganza.
Pero vamos por partes. Porque el drama tiene capítulos, y todos salen caros.
Hardware: más coste para hacer lo mismo (o menos)
Cuando una consulta no está optimizada, lo primero que pide el sistema es más CPU. Más RAM. Más disco. Y como somos humanos, y a veces un poco vagos, el primer impulso es escalar verticalmente: poner más hierro. Total, si ya funciona mal, con más recursos irá mejor, ¿no?
Pues sí. Durante un rato. Luego viene otra consulta igual de mala y vuelta a empezar. El patrón es de sobra conocido: base de datos lenta, compras hardware, mejora temporal, vuelve la lentitud, compras más hardware… y cuando te das cuenta, estás alimentando un monstruo que vive de cores, GB y licencias.
Y aquí entra la broma que siempre duele: SQL Server se licencia por core. Así que cada vez que decides “arreglar” un problema de rendimiento añadiendo CPU, estás aceptando voluntariamente pagar más en licencias, que no son baratas. Es como combatir la sed bebiendo agua salada: parece que ayuda, pero en realidad te estás hundiendo más.
El coste real en la nube: «elástico», sí, pero hacia arriba
Muchos creen que al migrar a la nube el problema desaparece. Que Azure SQL, AWS RDS o cualquier plataforma PaaS mágica va a solucionar lo que tu SELECT * no quiso arreglar. Y no, no es así.
En la nube todo se factura. Cada milisegundo de CPU, cada MB de RAM, cada GB de almacenamiento y cada IO de disco. Una consulta ineficiente en Azure no solo es lenta: es cara. Muy cara. Porque, a diferencia de tu servidor físico en el CPD, aquí no tienes un coste hundido. Aquí cada operación se convierte en un apunte contable. Y si te pasas, la factura no perdona.
He visto clientes triplicar su consumo mensual de Azure SQL sin añadir ni un solo usuario más. ¿La causa? Un informe mal diseñado, una vista que arrastra medio millón de registros y un desarrollador con más entusiasmo que criterio.
Una historia real de coste en azure
Y luego están los casos como este. Años atrás, un cliente me llamó porque su Azure SQL Managed Instance con 8 cores (unos 1.355€ al mes) tenía la CPU por encima del 90% casi todo el día, con picos constantes al 100% que parecían avisos de incendio. Lo más grave no era eso, sino que ya habían asumido que la única salida era duplicar recursos y pasar a 16 cores, lo que dispararía la factura a 2.700€/mes. Antes de firmar el salto, decidieron llamarme. Por suerte.
Lo que me encontré era un festival del despropósito. Ni un solo índice clustered, todos los índices nonclustered eran de una sola columna y, por supuesto, sin INCLUDE. Mirando el uso, el 95% de esos índices no se usaban. Y claro, la DMV de índices faltantes parecía la lista de tareas de un becario sin supervisión: infinita, desordenada y sin lógica.
Con un par de días de trabajo serio (revisión de patrones de consulta y una política de indexación con sentido común) no solo evitamos el escalado, sino que redujimos la instancia a 4 cores. El resultado fue sorprendente, CPU estable al 30% incluso en horas pico. Lo que se dice, respirar. Pero además, más de 25.000€ al año de ahorro respecto a la solución que estaban a punto de contratar.
El coste del “Pero si se lanza una vez al año…”
Ya que me he puesto en plan cuentacuentos, déjame contarte otra de esas anécdotas que se graban a fuego.
Un día me encontré con un informe, hecho en Tableau (pero eso es lo de menos), que lanzaban una vez al año y que tardaba en completarse… 22 horas. Bueno, yo lo pillé cuando llevaba 22 horas de ejecución en el SQL Server de producción, a saber cuánto más le quedaba. Cuando lo comenté, me dijeron que no pasaba nada, que solo se lanzaba una vez al año y que solían dejarlo corriendo de un día para otro, como quien pone la olla lenta con garbanzos.
Pero yo lo vi claro. La consulta tenía 47 subconsultas en el SELECT. Si, si, CUARENTA Y SIETE. No índices raros, no estructuras marcianas, solo una estructura de consulta absurda.
¿El cambio? Reescribir con LEFT JOIN bien definidos en lugar de esas subconsultas incrustadas. Nada más. Bueno si, una subconsulta que se repetía bastantes veces muy parecida se persistió como temporal al inicio del proceso. De esa manera los datos se leian y filtraban de una tabla grande una sola vez y se quedaban en una tabla pequeña para consultar el resto de las veces. Pero nada más, ni cambiar índices, ni tocar el esquema. Vamos, sin reformar la casa. ¿El resultado? Menos de 20 milisegundos.
Y esto amigos, esto no es una mejora. Eso es pasar de enviar la consulta en burro a ponerle un cohete. Y no exagero.
Porque no todo el coste es culpa del desarrollador
No vamos a demonizar. Todos hemos escrito consultas que después nos dieron vergüenza ajena. Y sí, hay veces que las prisas, las entregas y los deadlines te llevan a empalmar un par de subconsultas “de emergencia” con un UNION sin ALL y a mirar para otro lado.
Pero eso no justifica dejar ese código en producción durante años como si fuera parte del mobiliario. Porque esa consulta, aunque solo se ejecute una vez al día, puede ser la responsable de saturar el servidor, disparar el DTU en Azure o arrastrar a otras aplicaciones con ella.
Aquí entra en juego lo que me gusta llamar “el coste invisible de la desidia técnica”. No se ve, no se presupuesta, pero se paga igual. En horas de soporte, en tiempo perdido, en usuarios frustrados, en reputación quemada.
De 10 minutos a 2 milisegundos (sin efectos especiales)
Otra historia real, por si alguien aún cree que exagero.
Me llama un cliente porque un proceso tarda más de 10 minutos. Revisamos el plan de ejecución y canta como un tenor: falta un índice. Literalmente lo está pidiendo a gritos. Un Clustered Index Scan sobre una tabla de 10 millones de registros con 5 campos varchar(max).
Creamos un índice sencillo sobre los dos campos que busca… y bajamos a 20 segundos. Bien, ¿no?
Pero no me conformé. Me di cuenta de que esos campos varchar(max) apenas se usaban y propuse moverlos a otra tabla. Un cambio mínimo de esquema, sin traumas. El resultado: la consulta se resuelve ahora en 2 milisegundos.
Sí, de más de diez minutos a dos milisegundos. Sin comprar licencias, sin añadir cores, sin tirar la casa por la ventana. Solo sentido común.
Consultas eficientes, bases de datos rentables
Optimizar una consulta no es hacer magia negra ni sacrificar cabras sobre el plan de ejecución. Es técnica, análisis y experiencia. A veces basta con añadir un índice. O con quitar un SELECT * y poner solo las columnas que necesitas. O con evitar ese cursor que llevas arrastrando desde hace 10 años como si fuera un trauma sin resolver.
Una consulta optimizada no sólo corre más rápido. Consume menos CPU. Bloquea menos. Permite que más usuarios trabajen al mismo tiempo. Y, lo más importante, reduce directamente tu coste de infraestructura y licenciamiento.
No es filosofía, son matemáticas puras, si una consulta tarda 500 ms y logra pasar a 50 ms, puedes hacer 10 veces más operaciones con los mismos recursos. ¿Te imaginas que tu equipo hiciera 10 veces más tareas al mismo sueldo? Eso es lo que hace una base de datos bien afinada.
El coste del «si funciona, no lo toques»
Una de las excusas más repetidas cuando se habla de optimizar es: “Pero si ya funciona, ¿para qué meternos ahí?” Pues por eso mismo. Porque ahora va, pero mal. Y cada día que pasa, cada usuario que se conecta, cada nuevo informe que se genera, lo hace un poco peor.
La deuda técnica no caduca. Se acumula. Y cuando salta, no lo hace con un error bonito y fácil de arreglar. Lo hace con un rendimiento desastroso en el peor momento: justo antes del cierre contable, durante el Black Friday o cuando el CEO quiere ver “cómo va todo” desde Power BI (todo casos reales).
Si optimizar parece caro, espera a ver cuánto cuesta no hacerlo.
Formación, experiencia y algo de mala leche
Sí, optimizar lleva tiempo. Requiere saber leer planes de ejecución, entender estadísticas, conocer cómo SQL Server decide qué estrategia usar y cuándo. Pero también requiere actitud. Ganas de escarbar. De no conformarse con que funcione “más o menos”.
Y eso, lamentablemente, no lo da ningún botón mágico ni el asistente del Management Studio. Hay que aprenderlo. O contratar a alguien que lo sepa.
Aquí es donde entra mi parte, claro. No solo como autor de este blog, sino también como consultor. Llevo más de 12 años viendo barbaridades que harían llorar al optimizador de consultas. Y ayudando a equipos a entender por qué sus bases de datos son lentas, y cómo hacer que dejen de serlo sin hipotecar la nube ni sacrificar fines de semana enteros en tareas de mantenimiento que no deberían existir.
Y sí, estoy escribiendo un libro
Mi libro se va a llamar “SQL SERVER: La NO guía práctica de optimización”. Y no será el típico tocho con recetas milagrosas genéricas que nadie es capaz de aplicar en producción. Será un manual honesto, directo y realista. Uno que explica cómo optimizar sin morir en el intento, desde la base y comprendiendo el funcionamiento interno del motor de base de datos. Porque ya tenemos demasiadas presentaciones bonitas que no dicen nada.
Y sí, también haré formación. Y talleres. Y sesiones donde, si hace falta, nos peleamos con los planes de ejecución hasta que canten. Porque se puede. Porque debe hacerse. Y porque seguir pagando licencias por no optimizar… simplemente no tiene sentido.
¿Quieres dejar de pagar por no saber? Hablemos.
Si después de leer esto has pensado en esa consulta que lleva años sin tocar, en ese informe que tarda 12 minutos, o en ese servidor que cada semana pide más cores como si fueran cromos… ya sabes lo que hay.
Puedes seguir ignorándolo, puedes aprender cómo optimizar SQL Server o puedes llamarme y lo miramos juntos.
Tu factura lo va a notar.
