Cita: - SELECT de 100 registros, meterlos en una array, ordenarlos e INSERT de los 50 con el campo x (numérico) más alto.
Por un lado, MySQL no tiene arrays, por lo que en realidad ese tiempo es de la aplicación y no de MySQL.
Cita: - INSERT de 100 registros y SELECT de los 50 con el mismo campo x más alto.
Como dije, no son operaciones comparables si parte del proceso lo haces en programación...
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.