Aunque no soy ni mucho menos un profesional de SQL, tengo que admitir que es uno de los lenguajes que más me gustan (y cada día me siento más cómodo con él). Lo mejor del asunto es que no sé porqué me gusta; probablemente sea porque escribiendo bien poco, parece que estés haciendo cosas de genio
.
Uno de los temas más interesantes de SQL es el rendimiento: un mundo a explorar por muchos de nosotros.
Generalmente, cuando nos percatamos de lentitud en el sistema, e identificamos al SGBD (en mi caso MySQL) como posible culpable, lo primero que hacemos es pensar: “Puto MySQL, si tuviera un Oracle haría maravillas”. Al menos eso pensaba yo casi siempre… Pero claro, nunca nos paramos a mirarnos en el espejo. La culpa siempre es de otro/s (“todos somos inocentes hasta que se demuestre lo contrario”).
Hoy he estado revisando las SQL que hace apenas un año entregué en el proyecto de final de carrera, y me he reído un buen rato. Incluso he pensado en entregarme a la policía por hacer sufrir de esa forma tan atroz al servidor de BBDD.
Llevo un año trabajando con bases de datos diariamente, tocando SQL Server y MySQL principalmente. Y he aprendido una barbaridad. Pero no sólo a hacer SQLs, sino a hacer SQLs “como Dios manda”.
He leído mucho, he visto SQLs hechas por cracks del lenguaje, he trasteado… Y sigo llegando a la misma conclusión: por muy profesional que seas, siempre hay una SQL más eficiente que la tuya, y que hace lo mismo.
Así que ya no me doy de hostias cuando me doy cuenta de que la performance de mi SQL es mejorable; simplemente lo aprendo, lo asimilo y trato de no cometer el mismo error la próxima vez.
Y bueno, ya que tengo el blog (y no tengo muchas otras cosas que contar), me gustaría compartir mis experiencias con SQL, en busca de ayudar a aquellos que están en una situación algo retrasada respecto a lo que yo pueda saber, y también en busca de opiniones de gente que se ríe de lo que escribo
.
Y el primer tip será… Trrrrrrtrrrrtrrtrr… UNION VS UNION ALL.
Hace un par de días, tuve un problema con una SQL que hacía múltiples UNION; sin él, una de las consultas devolvía más de mil registros, pero haciéndolo, el result set era de 500 filas… ¿Cómo puede ser?
Googleando un poco, leí que UNION hace un DISTINCT de cada SQL que lo conforma, eliminando las duplicidades. Sinceramente, no lo sabía.
Si quieres mantener los registros duplicados, hay que hacer un UNION ALL entre las SQL.
Es entonces cuando me asaltaron las dudas: ¿Es UNION ALL más rápido que UNION? Si palabras como EXCEPT, JOIN, CROSS, SUBQUERY… suenan a lento, imagínate la expresión UNION ALL. No tiene pinta de ser precisamente rápido.
Pero como buen informático, me dispongo a despejar mis dudas, y a hacer pruebas de rendimiento. La consulta es bien sencilla:
SELECT id FROM tabla1 UNION SELECT id FROM tabla2
SELECT id FROM tabla1 UNION ALL SELECT id FROM tabla2
Mi mente vaticinaba que UNION ALL tiene que ser más rápido al no hacer DISTINCT; pero claro, la nomenclatura dice que UNION ALL es muuuuucho más lento que UNION (básicamente por el ALL).
Pues esta vez gana la lógica: ¡¡ UNION ALL es 6 veces más rápido que UNION !!. En el ejemplo (ambas tablas con 500.000 de registros), los resultados fueron (media aritmética de 10 pruebas):
- UNION: 24.1252 segundos
- UNION ALL: 3.9918 segundos
Moraleja: siempre que sepas de antemano que no existirán registros duplicados, usa UNION ALL.



