Bueno, vamos a hablar de algo que tiene que ver con la performance de nuestras consultas, cuando nosotros
ya estamos trabajando en un nivel más importante, con mucho desarrollo, con mucho acceso a la base
de datos, con tablas que tienen millones de registros o cientos de miles de registros.
Vamos a necesitar conocer cómo está funcionando todo nuestro sistema, cómo está funcionando nuestras
consultas, saber si lo que hemos hecho es óptimo o no es óptimo, si nos faltó crear algún índice.
Bueno, la única forma de saber eso es usando una instrucción que nos da el motor llamada Explain.
El Explain es una instrucción que se coloca antes de una sentencia SQL y que me permite analizar dicha
sentencia, donde me va a dar mucha información acerca de si la.
Con la consulta que está haciendo con las tablas es en base a un índice.
Si está bien unidad las tablas.
Si me se me está escapando algo que no estoy viendo.
Así que vamos a hacer un ejercicio para entender cómo funciona.
Vamos a hacer simplemente esto.
Vamos a seguir a nuestra tabla ventas y vamos a ver su estructura.
Yo aquí no tengo en venta fecha que sea un índice, lo cual está mal.
Es un campo que tiene que ser índice.
Por qué?
Porque todas las estadísticas que yo le voy a tirar a la tabla ventas siempre van a estar englobadas
dentro de un una consulta de rango de fechas.
Quiero saber las ventas de una fecha determinada o de un Vitín entre dos fechas o si la fecha es mayor
igual a tal fecha determinada.
Entonces el campo venta fechas tiene que ser índice.
Muy bien.
Nosotros no lo tenemos hecho índice y vamos a ver ahora qué ocurre con esto.
Cuando yo tire consultas hacia la tabla ventas en cuanto a segundos o décimas de segundo.
No vamos a notar prácticamente diferencia.
Por qué?
Porque eso es.
Tenemos una base de datos de prueba.
Aquí no tenemos datos reales.
Cuando ustedes están trabajando con bases de datos que no pesan 10 megas, sino que pesan 15 20 gigas,
se van a dar cuenta de lo importante que es lo que vamos a ver a continuación.
Entonces vamos a abrir una solapa de consultas y vamos a empezar a escribir una consulta SELECT para,
por ejemplo, traer las ventas agrupadas por productos de y agrupada por fechas.
Para que saber cuánto se vendió en dinero de cada producto?
Vamos a hacer un select de prod.
Hay DID le vamos a colocar el nombre de Haider, por ejemplo.
Descripción para que me muestre la descripción del producto.
Vamos a colocarlo así.
Vamos a traer la fecha.
Obviamente Ventas fecha aquí es mayúscula fecha y vamos a hacer una suma ahora, porque ahora quiero
que de esa fecha y de ese producto me sume todo lo que se ha vendido.
En cuanto a multiplicar la cantidad con el precio, obviamente no lo saca de la tabla ventas, sino
que los saca de venta.
Detalles sí que luego vamos a hacer los chains correspondientes.
Tenemos BD cantidad que es el precio.
El campo que me indica la cantidad de productos que he vendido multiplicado por vede precio, me va
a dar un subtotal, un parcial de lo que he vendido en una fecha determinada de ese producto.
Muy bien, ahora vamos a decirle que todo lo haga en base a la tabla productos y vamos a hacer un saine
no left join porque quiero que solamente me traiga los productos que encuentra en la tabla ventas detalle.
Vamos a hacer un join que es lo mismo que colocar inner join ventas detalle.
Ahí ya me pone en rosa porque reconoce que es una tabla.
No importa si la tabla tiene minúscula mayúscula, lo reconoce igual y luego le vamos a colocar la cláusula
de cómo vamos a unir productos con ventas.
Detalle en este caso era B, de ahí de ID es igual A pero Eider muy bien, ahí ya tenemos unidad.
Nuestra tabla productos a la tabla ventas detalle.
Pero como vamos a filtrar por fecha nuestra consulta, las fechas se encuentran en la tabla ventas no
en venta detalle.
Vamos a tener que seiner la tabla ventas detalles a la tabla ventas.
Colocamos la tabla ventas on BD ventas a id.id.
Es igual a ventas Heidy y ahí tenemos ya unida nuestra tabla ventas y venta de.
Muy bien.
Ahora lo que vamos a hacer es colocar el rango de fechas que queremos analizar, porque yo quiero saber
en la primer semana de enero del 2018.
Recuerden que es una base que se creó en el 2018 en la primer semana de enero de 2018.
Quiero saber cuánto fue la venta de cada producto.
Entonces vamos a hacer un huer ventas fecha Brittain Vamos a dar los dos rangos de fechas del cero uno
cero dos porque el primero fue feriado.
Primero de enero no se trabaja.
2018 cero uno cero siete.
Bueno, muy bien, ahí tenemos.
Podría ser del 2 al 6.
Esto es un ejercicio?
No, no es vinculante lo que queremos aquí y ahora.
Qué vamos a hacer una vez que ya tenemos todo esto unidos?
Yo quiero agrupar por producto.
Por qué?
Porque en un mismo día puede haber más de una venta de productos.
El mismo producto lo pudo haber vendido en tres facturas diferentes.
Entonces vamos a hacer un Group.
Voy de Haider, que es el nombre que le hemos puesto a nuestro producto.
Tengo que seguir la cadena, no puedo obviar campos, tengo que poner sí o sí la descripción, aunque
si yo ya estoy agrupando por ahí la descripción, no haría falta.
Pero bueno, el lenguaje se cuela y me obliga a incluir este campo.
Esto me parece que es una falla que en algún momento la tienen que solucionar.
Y ahora, por supuesto, la fecha.
En el caso de la suma, no hace falta agruparlas porque entiende que no es Agrupaba.
Yo no voy a agrupar por los resultados de un zum.
Esto ya queda afuera del Group.
Entonces tenemos nuestro id.id.
Nuestra descripción y nuestra fecha en el agrupamiento.
Y ahora lo que voy a hacer es para que me lo muestre como yo lo quiero.
Voy a hacer un order, voy order, voy a ir.
Si yo corro, esto seguramente va a demorar.
Nada, absolutamente nada.
Fíjense que demoró dieciséis centésimas de segundo.
A esto voy con que no le presten atención.
Con esta base de datos a los tiempos, porque aunque yo ahora coloque en venta fecha como índice, van
a ver que quizás demora lo mismo, que es un tiempo mínimo que demora el procesador en devolverme algo.
Yo ahora vuelvo a correr y van a ver que en lugar de decir 16 dice cero, o sea, o quince o menos y
va a ir bajando el tiempo cero según cero segundos porque?
Porque ya maneja el motor un caché de consulta donde ya sabe que es la misma consulta que tiró antes
y me vuelve a tirar los resultados porque detecta que no hubo cambios en la base de datos.
Muy bien, ahora tenemos nuestro nuestros resultados ordenados por ahí de productos por la fecha y las
unidades vendidas.
Fíjense que esto me arroja unos 447 registros y esto ha sido muy bueno.
Ahora, si lo que yo quiero saber es si esta consulta es óptima o no, más allá de que haya demorado
poco.
Recuerden, no le presten atención al tiempo que demora, porque quizás cuando la base de datos empieza
a crecer y en lugar de 10 megas tiene 10 siga ahí se van a notar las diferencias.
Entonces, si yo quiero saber si esta consulta es óptima antes del C.L.
Voy a colocar la cláusula o el o la instrucción o el comando EXPLAIN.
Al correr Explain no me va a traer toda esta información, sino que me va a traer la información inherente
a Explain.
Vamos a correrlo y fíjense que ahora lo que hace es darme una serie de información de las tablas que
tuvo que consultar para realizar esta consulta SELECT.
Como nosotros sabemos, tiene que realizar consulta a tres tablas.
La tabla ventas, venta, detalle y producto nos muestra en la columna tablas.
Muy bien.
Las columnas que nos importan aquí es si está usando un aquí.
En este caso, fíjense que en la columna aquí dice nulo.
Por qué?
Porque en la tabla ventas donde tengo mi fecha no pudo usar ninguna clave.
Porque venta fecha lo tengo como que no es un índice.
Ahora, a quien extra me dice que usó el huer, o sea, usó el weider, pero no usó un índice, realmente
aquí me tendría que aparecer un nul.
Uso el HUER, usó una tabla temporaria temporaria, usó un file, sólo un ordenamiento, siempre en
la primera fila.
Me va a parecer esto, pero lo que me está diciendo es todos los pasos que tuvo que hacer para ejecutar
esto, tuvo que usar una tabla temporaria, tuvo que agrupar y tuvo que usar un file short porque puse
un order Hervey.
Todos esos pasos los tuvo que hacer con el agravante de que no usó ninguna clave y por cada consulta
que hemos hecho tuvo que leer la totalidad de los registros de la tabla ventas.
Porque si yo en realidad lo que puse es que me consulte solamente los registros que tengan donde venta
fecha sea entre el 2 de enero y el 7 de enero.
Ahora, por qué lo hizo?
Porque al no tener una clave tuvo que leer todo la totalidad de la tabla.
Ahora imagínense que nosotros tenemos una tabla de prueba aquí tenemos una tabla de prueba que tiene
poquitos registros.
Fíjense lo que pesa la tabla venta 500 caballetes.
Ni siquiera llega un mega en el mundo real.
En la tabla de ventas van a encontrar, no sé, más de un millón de registros.
Por supuesto, uno con lo que hemos aprendido a lo largo del curso.
Uno halaba achicando.
Va armando tablas de resumen y demás, pero pueden encontrarse con cientos de miles de registros en
un en una empresa grande puede encontrarse con tablas muy grandes.
Entonces ahí sí que es crucial.
Y esta consulta que nosotros corremos aquí en décimas de segundo, en centésimas de segundo en el mundo
real, si lo tuviéramos así, puede llegar a demorar varios minutos.
Entonces es fundamental el uso de Spline.
Y fíjense qué pasa ahora si yo vuelvo a correr lo mismo, pero previamente voy a mi tabla ventas y coloco
que ventas fecha es un aquí que es un índice.
Ahora me va a aparecer en la solapa índices, ventas, fecha y voy a poder correr el EXPLAIN.
Fíjense que aquí me lee toda la tabla 7 00 18 registros y si yo corro nuevamente el Explain me dice
que solamente le yo 530 registros.
Ahora si me dice que la pudo filtrar al 100 por cien, porque hay una clave que en la columna aquí en
lugar de aparecer un null ahora aparece una venta fecha que es la clave aquí es Ventas Aydin porque
es el saine entre la tabla ventas y la tabla ventas detalle.
Y en el caso de los productos lo usa el group.
Voy por el la prima aquí que es, pero hay vida.
Entonces es fundamental que nos demos cuenta de que primero que en la columna aquí hay una clave, no
es nulo.
Si nosotros tenemos consulta, si estamos analizando consultas y vemos que dentro de la consulta estamos
haciendo un join a una tabla y que el join o el wear o el group voy está usando campos que no son índice.
Nos vamos a chocar con esto, con que aquí va a decir NUL y nos va a mostrar la totalidad de los registros.
Esa es la manera de analizar consultas, la manera de saber qué pasa adentro del motor.
Cuando hacemos un select es fundamental el uso de EXPLAIN para mejorar y optimizar más nuestras consultas.
Espero que les haya gustado esto.
Esto ya es bastante avanzado, estamos siempre yendo por más y en este caso a un tema que es muy importante,
que es la performance de nuestras consultas.
A ver si las estamos creando bien.
Si no se nos olvidó nada.
Si hemos creado los índices correctos y si los tiempos de nuestras consultas bajan o no bajan.
En mi trabajo actual, que es una empresa muy importante que maneja base de datos de los bancos más
importantes de Argentina, he logrado bajar las con una consulta que demoraba más de 10 minutos en ejecutarse.
He logrado bajarla a 2 segundos, a solamente 2 segundos.
Por qué?
Porque estaban mal configuradas, porque usaba tablas que no tenían los índices correctos y el sistema
alser vanse muy grandes.
Leía millones de registros por cada iteración que hacía.
Entonces esto es fundamental.
Esto es parte de nuestro trabajo profesional y espero que les haya gustado y nos vemos en el próximo
capítulo.