Si tengo miles de registros pero uso where...

[Leganz]

Hola, quería saber qué pasa con la velocidad de respuesta en el siguiente caso:

Una base de datos con 300.000 registros, todos son registros que se pueden identificar por una categoría y un ID

Supongamos un foro donde hay 300.000 foros y se reparten como 50.000 por categoría jeje es hipotético.

Será más lento localizar esos 50.000 registros mientras más registros haya en la tabla? es decir, si luego tengo 1.000.000 de foros pero siguen siendo 50.000 registros para esa consulta, ¿será igual de rápido que la primera vez o será más lento por la cantidad de registros generales?


Muchas gracias!
Saludos

[quimfv]

Como mas registros mas lento, eso siempre.

Pero si usas los indices adecuados puede seguir siendo muy rapido.

Un indice lo que hace, explicación intuitiva no técnica, es ordenar previamente los datos de manera que la consulta en realidad primero busca el valor en el indice y atraves de este se dirige al grupo de registros de ese valor.

Con lo que la operacion acaba siendo una busqueda en el numero de categorias y luego en el numero de registros de la categoria, por tanto en tu caso el primer numero (numero de categorias) no varia (o no mucho) y el segundo sigue siendo 50.000, tengas 300.000 o 1.000.000 de registros.

Quim

[Leganz]

Muchas gracias! esto de los indices conlleva una práctica desde mysql y otra desde php cierto?

[quimfv]

Debes crearlos en MySQL (7.4.5. Cómo utiliza MySQL los índices) en muchos casos no tendras que hacer nada mas que crearlos pero algunas veces se tiene que forzar su uso, o indicarle a mysql que quieres que se use (USE {INDEX|KEY}). Siempre sera en MySQL o en la sentencia Sql que ejecutas sea con php, directamente o con otro lenguaje.

Quim

(lo siento el primer link solo tiene traducido el titulo y el segundo ni eso)

[Bam_Margera]

Pregunta: Qué cantidad de registros puede empezar a notarse considereablemente? Es decir, en mi bbdd tengo unos 2.500 registros, no tengo ni idea de lo que son los Index (lo acabo de descubrir ahora y miraré), pero lo notaría?

[gnzsoloyo]

Depende del caso. Puedes hacer un JOIN con dos tablas de 5000 registros cada una y si está mal optimizado, terminar con un producto cartesiano de 25 millones; o puedes hacer otro con dos tablas de 5 millones de registros y obtener 28 registros en menos de un segundo....
No hay exactamente una cantidad precisa donde impacta. Existen casos donde se nota el impacto del índice en la consulta.
Hay formas de hacer el cálculo previo que te puede aproximar a la optimización sin necesidad de prueba y error, pero requiere un conocimiento bastante profundo de las bases de datos y el funcionamiento de los índices. Y es demasiado teórico para postearlo ahora.
Creo que pronto lo pondré entre las FAQs de MySQL.

[Bam_Margera]

Espero no desviarme del tema.. pero existe alguna manera de saber el tiempo de la consulta mysql?

[gnzsoloyo]

El tiempo... no con precisión y con ningún DBMS()Oracle y SQL Server incluidos), porque para saberlo hay que conocer el hardware, la estructura de las tablas que se usarán, los índices que afectarán la consulta, la selectividad de las condiciones, la cantidad de accesos a disco necesarios, el espacio de RAM disponible, etc., etc.
Básicamente, para lograr una aproximación necesitas los mismos elementos que el parser para establecer el plan de consulta, y aún así sería simplemente una aproximación, porque la ejecución de la misma consulta ejecutada en dos momentos distintos y con el mismo conjunto de datos puede tardar diferente según cuál sea el algoritmo que el DBMS use para resolver el plan...

No. No hay forma de conocer a priori cuánto dura una consulta. SOlo algunas aproximaciones. A lo más puedes establecer cuál es el segmento de la consulta que insume más tiempo y cuanto del tiempo total está consumiendo.