29/06/2011, 13:23
| ||||
| ||||
| velocidad SELECT Vs INSERT Hola, me gustaría saber si hay mucha diferencia (y más o menos cuánta) entre hacer un SELECT de 1000 registros por poner un ejemplo y un INSERT de 1000 registros, me refiero en cuanto a la eficiencia, velocidad de proceso, etc... |
|
29/06/2011, 13:43
| ||||
| ||||
| Respuesta: velocidad SELECT Vs INSERT Depende de qué contexto, de qué base, con qué tablas, con cuántos índices... Hay demasiadas consideraciones. No puedes hacer una afirmación taxativa de ningún modo. Por empezar, un SELECT que busque columnas que están en el índice y otro que no lo haga pueden tener resultados completamente diferentes, incluso con los mismos parámetros y con la misma tabla. Por otro lado, un INSERT masivo puede tener una velocidad completamente distinta que otro donde no se use in INSERT así, y ambos usar los mismo datos. Incluso, un INSERT masivo puede terminar siendo más lento que otro similar, si alimenta a una tabla con demasiados índices definidos... En definitiva, tu pregunta no se peude responder por "esto es mejor que aquello". Por eso existen las pruebas de benchmarking.
__________________ ¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente... "El problema es la interfase silla-teclado." (Gillermo Luque) |
|
30/06/2011, 02:00
| ||||
| ||||
| Respuesta: velocidad SELECT Vs INSERT Bueno lo que me refiero es que tengo un dilema. El tema es, siempre sobre la misma tabla, hacer: - SELECT de 100 registros, meterlos en una array, ordenarlos e INSERT de los 50 con el campo x (numérico) más alto. o... - INSERT de 100 registros y SELECT de los 50 con el mismo campo x más alto. no sé si te he contestado a la información que me pedías, gracias gnzsoloyo |
|
30/06/2011, 05:41
| ||||
| ||||
| Respuesta: velocidad SELECT Vs INSERT Cita: Por un lado, MySQL no tiene arrays, por lo que en realidad ese tiempo es de la aplicación y no de MySQL.- SELECT de 100 registros, meterlos en una array, ordenarlos e INSERT de los 50 con el campo x (numérico) más alto. Cita: Como dije, no son operaciones comparables si parte del proceso lo haces en programación...- INSERT de 100 registros y SELECT de los 50 con el mismo campo x más alto. Lo que sí es obvio es que si insertas 50 registros, no es lo mismo que insertar 100, pero con cantidades tan pequeñas las diferencias son de microsegundos (no te voy a decir picosegundos, pero...), y cuando hablamos de performance estamos hablando de cantidades realmente masivas de datos. Yo, para darte una idea, tengo un proceso en una base que alimenta 17 tablas. De esas, 3 son críticas, porque una recibe por vuelta 247.000 registros; la segunda tabla recibe por vez alrededor de 60.000, y la tercera más o menos 5000/6000. De las tres inserciones, la tercera es la más lenta, pero eso es por dos causas: 1) Recibe 3 datos que requieren conversiones implícitas (cadenas a DATETIME), y 2) tiene tres indices diferentes definidos. Curiosamente, de los aproximadamente 9 segundos que en una PC se tarda en almacenar las 17 tablas, la más grande se carga en menos de tres, mientras la última tarda más. En otra anécdota, tengo una consulta que me devuelve aproximadamente 150 registros de alrededor de 670000. Esto es una consulta que involucra 15 tablas. En un momento esta consulta tardaba aproximadamente 84 segundos. Luego, y sin cambiarle ni una línea a la consulta, le definí un índice adicional en una sola tabla, y la consulta pasó a tardar 7,8 segundos... ¿Se entiende por qué no se puede hacer una afirmación genérica? Con sólo un cambio, el tiempo de la consulta se redujo a menos de un décimo... Primero hay que ver los datos que tienes, la consulta que haces y recién allí podemos empezar a hablar de perfomance y qué es más rápido de hacer.
__________________ ¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente... "El problema es la interfase silla-teclado." (Gillermo Luque) Última edición por gnzsoloyo; 03/07/2011 a las 14:43 |
| Etiquetas: |
