MySQL: ¿Los condicionales reducen el consumo de recursos?

[iLeaz]

Hola, quería saber si me podrían aclarar esta duda. En el supuesto caso de que posea una tabla con 300.000 registros de 15 columnas cada uno. Si yo busco un registro determinado aplicando un condicional WHERE consumiría más o menos recursos que si realizara la misma consulta teniendo 100 registros de 15 columnas cada uno?

Muchas gracias!

PD: La consulta se realizaría mediante PHP - MySQL.

[Vun]

Eso depende de los indices que crees para dicha tabla, precisamente los indices son para eso, -explicado asi rapido y mal-, para que el motor encuentre los registros que especificas en los WHERE rapidamente, aunque tengas 50 millones de registros, en 10 o 15 pasos encuentra lo que buscas.

Si usas mucho esa consulta que dices, entonces ya sabes, crea un indice secundario para esos campos que indicas en el WHERE (no es asi de sencillo pero bueno)

[iLeaz]

Iniciado por Vun

Eso depende de los indices que crees para dicha tabla, precisamente los indices son para eso, -explicado asi rapido y mal-, para que el motor encuentre los registros que especificas en los WHERE rapidamente, aunque tengas 50 millones de registros, en 10 o 15 pasos encuentra lo que buscas.

Si usas mucho esa consulta que dices, entonces ya sabes, crea un indice secundario para esos campos que indicas en el WHERE (no es asi de sencillo pero bueno)

Pero entocnes si no hago eso tarde o temprano va a demorar mucho la misma consulta que antes hacia rapido??

cual sería el momento en que se haga indispensable el uso de indices, osea en qué numero minimo de registros?

[gnzsoloyo]

Hay muchas consideraciones para hacer respecto de la optimización requerida para una consulta, use o no el WHERE.

Partamos desde el principio:
Una consulta es óptima cuando usa la menor cantidad de accesos a disco para leer la mayor cantidad de datos en la menor cantidad de bloques de memoria necesarios.

Esto se basa en que un DBMS no lee los registros secuencialmente, sino que lee bloques de datos de hasta 64 Kb. Entonces se considera que una consulta es óptima cuando requiere la menos cantidad de bloques a leer.

Entonces mientras menor sea el registro, más registros entrarán en cada bloque y por tanto, en tu ejemplo, si cada registro puede tener 500 bytes de longitud, pueden entrar 128 registros por bloque, y se necesitarán 3 bloques de memoria y 3 accesos a disco para leer los 300 registros mencionados, sin importar mucho si los buscas entre 10.000 registros o 10.000.000.
En lugar de eso, si la longitud del registro es de 100 bytes, pueden entrar 640 registros por bloque y es 1 acceso a disco...

El problema empieza a aparecer con los condicionales usados, y los índices que existan.

Sitéticamente:
1) Una búsqueda sobre un índice agrupado (clúster o PK) o un índice no agrupado (INDEX) no usan la misma cantidad de lecturas.
2) Una búsqueda sobre índices no agrupados tales que la condición sea >, <, >=, <= o <>, pueden requerir la lectura de toda la tabla para ser respondida.

Como verás, la cosa no es tan simple como si el WHERE usa más o menos recursos. Depende de cómo sea esa tabla, qué índices existan y qué es lo que tenga ese WHERE.

Respondiendo la última pregunta, los índices empiezan a ser necesarios cuando la consulta tiene una baja selectividad. Esto significa que cada clave o dato comparativo puede abarcar demasiados registros de la tabla.

[iLeaz]

a ver.... entonces...

si tengo 300.000 registros y con el where solamente obtendría 6 registros con 6 columnas pero esos registros como mucho serán de 100 bytes en total...

si hay 300.000 registros y yo solo saco 6 de poca longitud... en que punto esta práctica se volvría muy lenta como para recurrir a index? o no serían necesarios? con mysql podría trabajar siempre ??

[gnzsoloyo]

si hay 300.000 registros y yo solo saco 6 de poca longitud... en que punto esta práctica se volvría muy lenta como para recurrir a index?

En el punto en que la selectividad de las claves de ese índice se vuelva demasiado baja...

Eso se debe establecer en el caso específico usando la información estadística que provee el DBMS. Hay fórmulas matemáticas que te permiten saber si una consulta determinada es o no óptima para un caso, pero no se extiende a todas las consultas, ni se hace de la forma simple en que lo estás planteando.

Esta sería la primera página de un apunte sobre costo de consultas:

OPTIMIZACION DE CONSULTAS SIMPLES – COSTOS
DATOS ESTADÍSTICOS
Tr = cantidad de tuplas de la relación
Br = cantidad de bloques que ocupa R
V(A,r) = cantidad de valores distintos del atributo A en la relación R.
Lr = Longitud de una tupla
SUPUESTO : R tiene una distribución UNIFORME.

Select *
From R
Where A θ "a"

Donde θ es { = , < , > , >= , <=, <>}

Costos de lectura: (CL)

a) Si Existe Indice agrupado (cluster) en A = "a" entonces CL = Br / V(A,r)
b) Si existe Indice no agrupado (no cluster) en A = "a" entonces CL = Tr / V(A,r)
c) Si Existe Indice agrupado (cluster) en A ψ "a" entonces CL = Br / 2
donde ψ es { < , > , <= , >= }
d) Si existe Indice no agrupado (no cluster) en A ψ "a" entonces CL = Tr / 2
donde ψ es { < , > , <= , >= }
e) Si no existe ningún índice entonces CL = Br

A) ESTIMACIÓN DEL TAMAÑO DEL OUTPUT

PRODUCTO CARTESIANO (JOIN)
R X S = Tr . Ts

JUNTA NATURAL (INNER JOIN)
R |X| S
Si R ∩ S = ∅ entonces Tr . Ts
Si R ∩ S = { clave de R } entonces <= Ts
Si R ∩ S = { clave de S } entonces <= Tr
Si R ∩ S = { atributo no clave } entonces Tr . Ts / V(A, r ) ó Tr .Ts / V(A,s)

Sobre esta base hay al menos seis pasos para establecer el costo optimo de la consulta...

Eso si quieres hacerlo con todos los detalles, claro, sino, siempre te queda la prueba/error.