1
00:00:05,080 --> 00:00:12,910
Bueno, vamos a hablar de algo que tiene que ver con la performance de nuestras consultas, cuando nosotros

2
00:00:13,180 --> 00:00:20,950
ya estamos trabajando en un nivel más importante, con mucho desarrollo, con mucho acceso a la base

3
00:00:20,950 --> 00:00:27,610
de datos, con tablas que tienen millones de registros o cientos de miles de registros.

4
00:00:28,060 --> 00:00:37,630
Vamos a necesitar conocer cómo está funcionando todo nuestro sistema, cómo está funcionando nuestras

5
00:00:37,630 --> 00:00:44,980
consultas, saber si lo que hemos hecho es óptimo o no es óptimo, si nos faltó crear algún índice.

6
00:00:45,370 --> 00:00:54,820
Bueno, la única forma de saber eso es usando una instrucción que nos da el motor llamada Explain.

7
00:00:55,300 --> 00:01:04,060
El Explain es una instrucción que se coloca antes de una sentencia SQL y que me permite analizar dicha

8
00:01:04,060 --> 00:01:08,440
sentencia, donde me va a dar mucha información acerca de si la.

9
00:01:08,490 --> 00:01:13,150
Con la consulta que está haciendo con las tablas es en base a un índice.

10
00:01:13,450 --> 00:01:15,850
Si está bien unidad las tablas.

11
00:01:16,090 --> 00:01:19,930
Si me se me está escapando algo que no estoy viendo.

12
00:01:20,680 --> 00:01:24,880
Así que vamos a hacer un ejercicio para entender cómo funciona.

13
00:01:25,180 --> 00:01:27,220
Vamos a hacer simplemente esto.

14
00:01:27,220 --> 00:01:32,050
Vamos a seguir a nuestra tabla ventas y vamos a ver su estructura.

15
00:01:32,740 --> 00:01:38,200
Yo aquí no tengo en venta fecha que sea un índice, lo cual está mal.

16
00:01:38,230 --> 00:01:40,390
Es un campo que tiene que ser índice.

17
00:01:40,420 --> 00:01:40,750
Por qué?

18
00:01:40,780 --> 00:01:47,110
Porque todas las estadísticas que yo le voy a tirar a la tabla ventas siempre van a estar englobadas

19
00:01:47,170 --> 00:01:51,370
dentro de un una consulta de rango de fechas.

20
00:01:51,820 --> 00:01:58,120
Quiero saber las ventas de una fecha determinada o de un Vitín entre dos fechas o si la fecha es mayor

21
00:01:58,120 --> 00:02:00,190
igual a tal fecha determinada.

22
00:02:00,490 --> 00:02:04,030
Entonces el campo venta fechas tiene que ser índice.

23
00:02:04,630 --> 00:02:05,200
Muy bien.

24
00:02:05,500 --> 00:02:10,380
Nosotros no lo tenemos hecho índice y vamos a ver ahora qué ocurre con esto.

25
00:02:10,390 --> 00:02:18,370
Cuando yo tire consultas hacia la tabla ventas en cuanto a segundos o décimas de segundo.

26
00:02:18,670 --> 00:02:21,280
No vamos a notar prácticamente diferencia.

27
00:02:21,470 --> 00:02:21,950
Por qué?

28
00:02:22,180 --> 00:02:23,110
Porque eso es.

29
00:02:23,230 --> 00:02:25,030
Tenemos una base de datos de prueba.

30
00:02:25,390 --> 00:02:26,920
Aquí no tenemos datos reales.

31
00:02:26,950 --> 00:02:34,060
Cuando ustedes están trabajando con bases de datos que no pesan 10 megas, sino que pesan 15 20 gigas,

32
00:02:34,360 --> 00:02:39,160
se van a dar cuenta de lo importante que es lo que vamos a ver a continuación.

33
00:02:39,760 --> 00:02:47,050
Entonces vamos a abrir una solapa de consultas y vamos a empezar a escribir una consulta SELECT para,

34
00:02:47,050 --> 00:02:52,700
por ejemplo, traer las ventas agrupadas por productos de y agrupada por fechas.

35
00:02:52,720 --> 00:02:57,550
Para que saber cuánto se vendió en dinero de cada producto?

36
00:02:57,760 --> 00:02:59,950
Vamos a hacer un select de prod.

37
00:03:00,040 --> 00:03:04,090
Hay DID le vamos a colocar el nombre de Haider, por ejemplo.

38
00:03:04,810 --> 00:03:10,240
Descripción para que me muestre la descripción del producto.

39
00:03:11,830 --> 00:03:13,120
Vamos a colocarlo así.

40
00:03:13,240 --> 00:03:14,680
Vamos a traer la fecha.

41
00:03:14,710 --> 00:03:24,820
Obviamente Ventas fecha aquí es mayúscula fecha y vamos a hacer una suma ahora, porque ahora quiero

42
00:03:24,820 --> 00:03:31,160
que de esa fecha y de ese producto me sume todo lo que se ha vendido.

43
00:03:31,180 --> 00:03:36,460
En cuanto a multiplicar la cantidad con el precio, obviamente no lo saca de la tabla ventas, sino

44
00:03:36,460 --> 00:03:37,390
que los saca de venta.

45
00:03:37,390 --> 00:03:42,370
Detalles sí que luego vamos a hacer los chains correspondientes.

46
00:03:43,390 --> 00:03:46,020
Tenemos BD cantidad que es el precio.

47
00:03:46,090 --> 00:03:54,580
El campo que me indica la cantidad de productos que he vendido multiplicado por vede precio, me va

48
00:03:54,580 --> 00:04:00,640
a dar un subtotal, un parcial de lo que he vendido en una fecha determinada de ese producto.

49
00:04:02,650 --> 00:04:10,420
Muy bien, ahora vamos a decirle que todo lo haga en base a la tabla productos y vamos a hacer un saine

50
00:04:10,480 --> 00:04:17,710
no left join porque quiero que solamente me traiga los productos que encuentra en la tabla ventas detalle.

51
00:04:18,700 --> 00:04:24,400
Vamos a hacer un join que es lo mismo que colocar inner join ventas detalle.

52
00:04:26,590 --> 00:04:30,100
Ahí ya me pone en rosa porque reconoce que es una tabla.

53
00:04:30,100 --> 00:04:38,480
No importa si la tabla tiene minúscula mayúscula, lo reconoce igual y luego le vamos a colocar la cláusula

54
00:04:38,740 --> 00:04:41,500
de cómo vamos a unir productos con ventas.

55
00:04:41,500 --> 00:04:51,630
Detalle en este caso era B, de ahí de ID es igual A pero Eider muy bien, ahí ya tenemos unidad.

56
00:04:51,670 --> 00:04:55,510
Nuestra tabla productos a la tabla ventas detalle.

57
00:04:55,540 --> 00:05:02,530
Pero como vamos a filtrar por fecha nuestra consulta, las fechas se encuentran en la tabla ventas no

58
00:05:02,530 --> 00:05:03,610
en venta detalle.

59
00:05:05,040 --> 00:05:09,660
Vamos a tener que seiner la tabla ventas detalles a la tabla ventas.

60
00:05:10,770 --> 00:05:17,130
Colocamos la tabla ventas on BD ventas a id.id.

61
00:05:17,430 --> 00:05:23,630
Es igual a ventas Heidy y ahí tenemos ya unida nuestra tabla ventas y venta de.

62
00:05:24,090 --> 00:05:24,450
Muy bien.

63
00:05:25,110 --> 00:05:30,300
Ahora lo que vamos a hacer es colocar el rango de fechas que queremos analizar, porque yo quiero saber

64
00:05:30,540 --> 00:05:33,630
en la primer semana de enero del 2018.

65
00:05:33,960 --> 00:05:40,140
Recuerden que es una base que se creó en el 2018 en la primer semana de enero de 2018.

66
00:05:40,170 --> 00:05:43,680
Quiero saber cuánto fue la venta de cada producto.

67
00:05:43,830 --> 00:05:55,230
Entonces vamos a hacer un huer ventas fecha Brittain Vamos a dar los dos rangos de fechas del cero uno

68
00:05:55,230 --> 00:05:57,780
cero dos porque el primero fue feriado.

69
00:05:59,130 --> 00:06:00,780
Primero de enero no se trabaja.

70
00:06:01,650 --> 00:06:04,800
2018 cero uno cero siete.

71
00:06:06,000 --> 00:06:07,270
Bueno, muy bien, ahí tenemos.

72
00:06:07,290 --> 00:06:10,080
Podría ser del 2 al 6.

73
00:06:10,410 --> 00:06:11,860
Esto es un ejercicio?

74
00:06:11,940 --> 00:06:15,990
No, no es vinculante lo que queremos aquí y ahora.

75
00:06:15,990 --> 00:06:18,270
Qué vamos a hacer una vez que ya tenemos todo esto unidos?

76
00:06:18,270 --> 00:06:20,220
Yo quiero agrupar por producto.

77
00:06:20,970 --> 00:06:21,320
Por qué?

78
00:06:21,420 --> 00:06:24,510
Porque en un mismo día puede haber más de una venta de productos.

79
00:06:24,840 --> 00:06:28,350
El mismo producto lo pudo haber vendido en tres facturas diferentes.

80
00:06:28,360 --> 00:06:31,650
Entonces vamos a hacer un Group.

81
00:06:31,770 --> 00:06:37,710
Voy de Haider, que es el nombre que le hemos puesto a nuestro producto.

82
00:06:39,240 --> 00:06:44,490
Tengo que seguir la cadena, no puedo obviar campos, tengo que poner sí o sí la descripción, aunque

83
00:06:44,940 --> 00:06:48,180
si yo ya estoy agrupando por ahí la descripción, no haría falta.

84
00:06:48,210 --> 00:06:52,680
Pero bueno, el lenguaje se cuela y me obliga a incluir este campo.

85
00:06:52,740 --> 00:06:57,750
Esto me parece que es una falla que en algún momento la tienen que solucionar.

86
00:06:58,590 --> 00:07:00,570
Y ahora, por supuesto, la fecha.

87
00:07:01,380 --> 00:07:06,610
En el caso de la suma, no hace falta agruparlas porque entiende que no es Agrupaba.

88
00:07:06,750 --> 00:07:09,960
Yo no voy a agrupar por los resultados de un zum.

89
00:07:10,080 --> 00:07:11,820
Esto ya queda afuera del Group.

90
00:07:12,630 --> 00:07:14,430
Entonces tenemos nuestro id.id.

91
00:07:14,520 --> 00:07:17,430
Nuestra descripción y nuestra fecha en el agrupamiento.

92
00:07:18,150 --> 00:07:21,690
Y ahora lo que voy a hacer es para que me lo muestre como yo lo quiero.

93
00:07:21,690 --> 00:07:27,590
Voy a hacer un order, voy order, voy a ir.

94
00:07:28,680 --> 00:07:33,870
Si yo corro, esto seguramente va a demorar.

95
00:07:33,960 --> 00:07:35,790
Nada, absolutamente nada.

96
00:07:35,820 --> 00:07:40,440
Fíjense que demoró dieciséis centésimas de segundo.

97
00:07:41,460 --> 00:07:44,130
A esto voy con que no le presten atención.

98
00:07:44,340 --> 00:07:51,150
Con esta base de datos a los tiempos, porque aunque yo ahora coloque en venta fecha como índice, van

99
00:07:51,150 --> 00:07:56,940
a ver que quizás demora lo mismo, que es un tiempo mínimo que demora el procesador en devolverme algo.

100
00:07:57,150 --> 00:08:03,050
Yo ahora vuelvo a correr y van a ver que en lugar de decir 16 dice cero, o sea, o quince o menos y

101
00:08:03,060 --> 00:08:08,030
va a ir bajando el tiempo cero según cero segundos porque?

102
00:08:08,040 --> 00:08:14,460
Porque ya maneja el motor un caché de consulta donde ya sabe que es la misma consulta que tiró antes

103
00:08:14,670 --> 00:08:19,620
y me vuelve a tirar los resultados porque detecta que no hubo cambios en la base de datos.

104
00:08:20,040 --> 00:08:29,190
Muy bien, ahora tenemos nuestro nuestros resultados ordenados por ahí de productos por la fecha y las

105
00:08:29,190 --> 00:08:30,210
unidades vendidas.

106
00:08:30,540 --> 00:08:37,950
Fíjense que esto me arroja unos 447 registros y esto ha sido muy bueno.

107
00:08:38,040 --> 00:08:44,730
Ahora, si lo que yo quiero saber es si esta consulta es óptima o no, más allá de que haya demorado

108
00:08:44,730 --> 00:08:45,330
poco.

109
00:08:45,630 --> 00:08:51,600
Recuerden, no le presten atención al tiempo que demora, porque quizás cuando la base de datos empieza

110
00:08:51,600 --> 00:08:56,910
a crecer y en lugar de 10 megas tiene 10 siga ahí se van a notar las diferencias.

111
00:08:57,240 --> 00:09:02,520
Entonces, si yo quiero saber si esta consulta es óptima antes del C.L.

112
00:09:02,610 --> 00:09:09,090
Voy a colocar la cláusula o el o la instrucción o el comando EXPLAIN.

113
00:09:09,660 --> 00:09:16,620
Al correr Explain no me va a traer toda esta información, sino que me va a traer la información inherente

114
00:09:16,710 --> 00:09:18,000
a Explain.

115
00:09:18,630 --> 00:09:25,950
Vamos a correrlo y fíjense que ahora lo que hace es darme una serie de información de las tablas que

116
00:09:25,950 --> 00:09:30,190
tuvo que consultar para realizar esta consulta SELECT.

117
00:09:30,630 --> 00:09:35,220
Como nosotros sabemos, tiene que realizar consulta a tres tablas.

118
00:09:35,280 --> 00:09:40,980
La tabla ventas, venta, detalle y producto nos muestra en la columna tablas.

119
00:09:41,400 --> 00:09:41,910
Muy bien.

120
00:09:42,720 --> 00:09:48,780
Las columnas que nos importan aquí es si está usando un aquí.

121
00:09:48,870 --> 00:09:52,470
En este caso, fíjense que en la columna aquí dice nulo.

122
00:09:52,500 --> 00:09:53,100
Por qué?

123
00:09:53,340 --> 00:09:58,920
Porque en la tabla ventas donde tengo mi fecha no pudo usar ninguna clave.

124
00:09:58,950 --> 00:10:02,790
Porque venta fecha lo tengo como que no es un índice.

125
00:10:03,930 --> 00:10:11,580
Ahora, a quien extra me dice que usó el huer, o sea, usó el weider, pero no usó un índice, realmente

126
00:10:11,580 --> 00:10:13,270
aquí me tendría que aparecer un nul.

127
00:10:13,620 --> 00:10:21,960
Uso el HUER, usó una tabla temporaria temporaria, usó un file, sólo un ordenamiento, siempre en

128
00:10:21,960 --> 00:10:22,890
la primera fila.

129
00:10:22,900 --> 00:10:29,370
Me va a parecer esto, pero lo que me está diciendo es todos los pasos que tuvo que hacer para ejecutar

130
00:10:29,370 --> 00:10:35,970
esto, tuvo que usar una tabla temporaria, tuvo que agrupar y tuvo que usar un file short porque puse

131
00:10:36,300 --> 00:10:37,350
un order Hervey.

132
00:10:38,130 --> 00:10:46,530
Todos esos pasos los tuvo que hacer con el agravante de que no usó ninguna clave y por cada consulta

133
00:10:46,530 --> 00:10:51,840
que hemos hecho tuvo que leer la totalidad de los registros de la tabla ventas.

134
00:10:52,230 --> 00:11:00,000
Porque si yo en realidad lo que puse es que me consulte solamente los registros que tengan donde venta

135
00:11:00,000 --> 00:11:04,440
fecha sea entre el 2 de enero y el 7 de enero.

136
00:11:05,160 --> 00:11:07,740
Ahora, por qué lo hizo?

137
00:11:07,770 --> 00:11:12,030
Porque al no tener una clave tuvo que leer todo la totalidad de la tabla.

138
00:11:12,600 --> 00:11:17,730
Ahora imagínense que nosotros tenemos una tabla de prueba aquí tenemos una tabla de prueba que tiene

139
00:11:18,000 --> 00:11:18,990
poquitos registros.

140
00:11:18,990 --> 00:11:22,140
Fíjense lo que pesa la tabla venta 500 caballetes.

141
00:11:22,230 --> 00:11:25,770
Ni siquiera llega un mega en el mundo real.

142
00:11:25,860 --> 00:11:31,020
En la tabla de ventas van a encontrar, no sé, más de un millón de registros.

143
00:11:31,350 --> 00:11:34,980
Por supuesto, uno con lo que hemos aprendido a lo largo del curso.

144
00:11:35,010 --> 00:11:36,120
Uno halaba achicando.

145
00:11:36,120 --> 00:11:42,390
Va armando tablas de resumen y demás, pero pueden encontrarse con cientos de miles de registros en

146
00:11:42,390 --> 00:11:46,960
un en una empresa grande puede encontrarse con tablas muy grandes.

147
00:11:47,010 --> 00:11:49,200
Entonces ahí sí que es crucial.

148
00:11:49,410 --> 00:11:57,810
Y esta consulta que nosotros corremos aquí en décimas de segundo, en centésimas de segundo en el mundo

149
00:11:57,810 --> 00:12:02,010
real, si lo tuviéramos así, puede llegar a demorar varios minutos.

150
00:12:02,370 --> 00:12:04,830
Entonces es fundamental el uso de Spline.

151
00:12:05,070 --> 00:12:13,020
Y fíjense qué pasa ahora si yo vuelvo a correr lo mismo, pero previamente voy a mi tabla ventas y coloco

152
00:12:13,290 --> 00:12:16,740
que ventas fecha es un aquí que es un índice.

153
00:12:17,160 --> 00:12:23,660
Ahora me va a aparecer en la solapa índices, ventas, fecha y voy a poder correr el EXPLAIN.

154
00:12:23,670 --> 00:12:31,200
Fíjense que aquí me lee toda la tabla 7 00 18 registros y si yo corro nuevamente el Explain me dice

155
00:12:31,200 --> 00:12:35,220
que solamente le yo 530 registros.

156
00:12:35,490 --> 00:12:42,600
Ahora si me dice que la pudo filtrar al 100 por cien, porque hay una clave que en la columna aquí en

157
00:12:42,600 --> 00:12:50,010
lugar de aparecer un null ahora aparece una venta fecha que es la clave aquí es Ventas Aydin porque

158
00:12:50,010 --> 00:12:54,000
es el saine entre la tabla ventas y la tabla ventas detalle.

159
00:12:54,300 --> 00:12:57,270
Y en el caso de los productos lo usa el group.

160
00:12:57,300 --> 00:13:00,360
Voy por el la prima aquí que es, pero hay vida.

161
00:13:01,140 --> 00:13:09,300
Entonces es fundamental que nos demos cuenta de que primero que en la columna aquí hay una clave, no

162
00:13:09,300 --> 00:13:09,990
es nulo.

163
00:13:10,380 --> 00:13:16,830
Si nosotros tenemos consulta, si estamos analizando consultas y vemos que dentro de la consulta estamos

164
00:13:16,830 --> 00:13:26,910
haciendo un join a una tabla y que el join o el wear o el group voy está usando campos que no son índice.

165
00:13:27,150 --> 00:13:34,260
Nos vamos a chocar con esto, con que aquí va a decir NUL y nos va a mostrar la totalidad de los registros.

166
00:13:34,860 --> 00:13:39,330
Esa es la manera de analizar consultas, la manera de saber qué pasa adentro del motor.

167
00:13:39,360 --> 00:13:47,700
Cuando hacemos un select es fundamental el uso de EXPLAIN para mejorar y optimizar más nuestras consultas.

168
00:13:47,940 --> 00:13:49,590
Espero que les haya gustado esto.

169
00:13:49,680 --> 00:13:57,750
Esto ya es bastante avanzado, estamos siempre yendo por más y en este caso a un tema que es muy importante,

170
00:13:57,750 --> 00:14:00,760
que es la performance de nuestras consultas.

171
00:14:00,780 --> 00:14:03,030
A ver si las estamos creando bien.

172
00:14:03,240 --> 00:14:05,100
Si no se nos olvidó nada.

173
00:14:05,700 --> 00:14:12,120
Si hemos creado los índices correctos y si los tiempos de nuestras consultas bajan o no bajan.

174
00:14:12,570 --> 00:14:19,080
En mi trabajo actual, que es una empresa muy importante que maneja base de datos de los bancos más

175
00:14:19,080 --> 00:14:27,210
importantes de Argentina, he logrado bajar las con una consulta que demoraba más de 10 minutos en ejecutarse.

176
00:14:27,540 --> 00:14:32,550
He logrado bajarla a 2 segundos, a solamente 2 segundos.

177
00:14:32,580 --> 00:14:33,120
Por qué?

178
00:14:33,360 --> 00:14:40,920
Porque estaban mal configuradas, porque usaba tablas que no tenían los índices correctos y el sistema

179
00:14:40,980 --> 00:14:42,240
alser vanse muy grandes.

180
00:14:42,240 --> 00:14:46,410
Leía millones de registros por cada iteración que hacía.

181
00:14:46,710 --> 00:14:49,740
Entonces esto es fundamental.

182
00:14:49,860 --> 00:14:56,340
Esto es parte de nuestro trabajo profesional y espero que les haya gustado y nos vemos en el próximo

183
00:14:56,340 --> 00:14:56,760
capítulo.