Velocidad de consulta en una tabla

[humanista]

Hola,

Imagínense que tengo 2 tablas:

- Tabla A: 50.000 registros
- Tabla B: 2.000.000 registros

ambas ordenadas por un campo id clave primaria autonumérica.

ambas con idéntica estructura, lo único que cambia es el número de registros.

Quiero hacer una consulta por fecha entre hoy y los últimos 60 días, por ejemplo. La fecha no es campo clave.

Mi pregunta es... hay mucha diferencia entre lo que tardaría la tabla A a la tabla B? Estoy hablando de experiencia de usuario, es decir perceptible para el usuario. Si es 1 sg está bien, el usuario tampoco lo va a notar.

Y en una tabla de 5 millones de registros?

Lo que pido es una estimación nada más.

[gnzsoloyo]

Mi pregunta es... hay mucha diferencia entre lo que tardaría la tabla A a la tabla B?

Diferencias, si. ¿Cuánta?...
Bueno, se necesita más información para poder responderla, pero existen algoritmos que permiten hacer esas estimaciones, aunque para usarlos se necesita, como dije, más datos, como por ejemplo la estructura real de las tablas.

En principio, si el campo no está indexado, eso exigirá al DBMS realizar un full table scan, lo que es una pésima idea.

[humanista]

Básicamente la tabla tiene un campo título, descripción, link, todos varchar entre 350 y 650 caracteres, 6 campos smalltyint y la fecha que es datetime.

Debería poner la fecha como campo clave UNIQUE?

[gnzsoloyo]

Se necesitan, en realidad, algunos datos mejores que eso, porque la idea es mas o menos así:
- Los DBMS no leer registro a registro. Leen bloques de datos, que se almacenan en segmentos de memoria.
- Cada segmento, creo, que tiene alrededor de 8 Kb.
- No pueden entrar al bloque registros incompletos, por lo que la cantidad de registros leídos es el resultado de la división entera de 8 Kb por la longitud física de los registros.
- Eso devuelve la cantidad de registros por bloque, y sabiendo la longitud de la tabla en registros, puedes saber cuántos bloques [(registros/bloques)+ 1 si el resultado no es entero)] se necesitan para barrer la tabla.
- Cada bloque leído es un acceso a disco realizado por el sistema.
- Como cada acceso a disco es un cambio de contexto de sistema, cada vez que se lea un bloque eso reduce la performance global. Por eso se necesita realizar consultas tales que accedan la menor cantidad de veces al dico como sea posible (y no estoy considerando el swapping necesario).
- En tu contexto, como no hay índice declarado sobre la fecha, el DBMS deberá hacer el full scan para obtener datos comparables al rango, y por tanto mientras mayor sea la cantidad de registros de la tabla, mayor será el tiempo insumido en leer y comparar, sin contar con el requerido por el sistema cuando hace swap a disco, ni nos metemos a analizar la paginación de memoria, fragmentaciones, etc. etc.

Ahora bien, al usar un índice sobre la fecha, la cosa se simplifica. ¿Por qué? porque por lo pronto el índice con sólo fecha de clave implica una entrada de 8 bytes de clave, lo que sumado a la estructura de la hoja de entrada, significaría que en un mismo bloque de datos entran muchísimos más registros analizables.
Además, al usar comparaciones de fecha, en lugar de leer el índice completo, realiza búsquedas binarias, que son más rápidas. De se modo, lee los valores extremos, y según el resultado determina si sigue leyendo o descarta todo.
Si sigue leyendo, en pocos saltos puede ubicar el rango a leer, y luego simplemente va a la tabla, y saca los registros puntuales que necesita.
Todo ese proceso es muchísimo más rápido que leer toda la tyabla.
Esto no implica que la consulta no vaya a descarar el índice, si lo que pides supera la cantidad eficiente de registros a leer. Si el rango buscado abarca el 50% o más de los registros de la tabla, descarta el índice y lee la tabla.
Todo esto es lógica interna del MySQL, por lo que en realidad aunque lo veas en los manuales, lo aprendes cuando lo estudias formalmente. Es medio críptico para los que no han cursado un par de materias adicionales...

Como sea, yendo a tu segunda pregunta, un indice UNIQUE es una clave primaria alternativa, por lo que si en tu contexto, puede suceder que haya dos registros con igual valor, no sirve un UNIQUE. Deberás usar un INDEX.

[humanista]

Está claro y la explicación "profunda" muy necesaria. Gracias gnzsoloyo!