Velocidad de consulta en una tabla

[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.