SELECT (consulta) ¿pesada?

[humanista]

Hola, tengo una tabla con miles de registros, el tema es que quiero hacer una SELECT con 3 condiciones, la tercera de ellas son varios OR, la consulta es algo así:

Código MySQL:

$result = mysql_query("select distinct * from foro where puntuacion>1 and date >= '$dateoneweekago' and (campo1='$ratio1' or campo1='$ratio2' or campo1='$ratio3' or campo2='$ratio1' or campo2='$ratio2' or campo2='$ratio3'....) order by puntuacion desc limit 25", $link);
 

realmente el campo1, el campo2 y el campo3 comparo cada uno con 10 ratios, es decir 3x10 = 30 comparaciones.

mi pregunta es:

1º puestas así las condiciones, se ejecutan en orden?, es decir si es así debería poner primero la más restrictiva (entiendo)

2º es eficiente? es decir si tengo 20.000 registros o 100.000 registros, puede colapsar el servidor o no?

deciros también q esta consulta se hará cada vez q el usuario se loguee, pongamos 3 veces al día, multiplicado por... miles de usuarios.

no sé si es mucho pedir al apache y al mysql... qué decís? gracias

[humanista]

alguien sabe cómo podría hacerlo? me imagino que será una consulta relativamente común...

[gnzsoloyo]

Tu consulta es así:

Código MySQL:

SELECT DISTINCT * 
FROM foro 
WHERE 
    puntuacion>1 AND 
    date >= '$dateoneweekago' AND 
    (campo1='$ratio1' OR 
    campo1='$ratio2' OR 
    campo1='$ratio3' OR 
    campo2='$ratio1' OR 
    campo2='$ratio2' OR
    campo2='$ratio3') 
ORDER BY puntuacion DESC 
LIMIT 25;
 

Respondiendo tus preguntas:
1) El orden de resolución de los AND es el mismo de aparición, normalmente, con algunas excepciones, como las subconsultas en el WHERE. Pero de todos modos la cadena de ANDs debe dar TRUE completa para que haya resultados.
Los OR anidados, por su parte, puede que se ejecuten todos o no. Como sólo se necesita uno TRUE, con el primero que se da el resto de la condición no necesita evaluarse.
2) Las eficiencia de las condiciones es relativa. Condiciones de tipo ">", "<", ">=", "<=", no suelen ser eficientes porque pueden implicar revisar la mayoría de la tabla, con lo que puede dar lugar a que descarte índices posibles y lea todo... con la consiguiente recarga de recursos.
En este tipo de casos suele ser práctico establecer índices sobre los campos del WHERE. En ocasiones la diferencia de performance es enorme.

Tips finales:
- Cuidado con el uso de palabras reservadas como nombres de campo, como es el caso de "date". No uses palabras que puedas ser nombres de función, cláusulas o tipos de dato. Te pueden generar errores indetectables.
- Cuidado con los ID: Si la tabla foros tiene un ID autonumérico, la cláusula DISTINCT no producirá ningún efecto.
- Si los campos son numéricos, no pongas los valores de las variables entre apóstrofes, eso sólo es válido para las cadenas de texto, fechas y horas. En los valores numéricos obligas al sistema a hacer una conversión implícita, que en consultas masivas afecta la performance.

Otra sintaxis:

Código MySQL:

SELECT DISTINCT * 
FROM foro 
WHERE 
    puntuacion>1 AND 
    `date` >= '$dateoneweekago' AND 
    (campo1 IN ('$ratio1', '$ratio2', '$ratio3') OR campo2 IN('$ratio1', '$ratio2',  '$ratio3')) 
ORDER BY puntuacion DESC 
LIMIT 25;
 

[humanista]

grandísima aportación gnzsoloyo, de verdad. ya sólo me queda preguntarte si crees que con miles de registros será eficiente esta consulta (en un servidor en internet, claro, no en local).

es decir varios usuarios ejecutando esta consulta varias veces al día (no te puedo hacer una estimación pero pongamos 1.000 consultas al día sobre una tabla de 10.000 mensajes por ejemplo).

mil gracias.

[gnzsoloyo]

Depende mucho del contexto, la carga total de los usuarios, conexiones, recursos de servidor... En fin.
A veces la mejor consulta, planeada con cuidado, resulta ineficiente llegado el caso, pero siempre se puede mejorar. El uso de IN(valores), es una idea muy eficiente, por eso te la puse, pero también se puede mejorar con uso de índices sobre los campos críticos de búsqueda.
Hay mucha tela para cortar.

A priori, trata de probar con cantidades masivas lo antes que puedas. Mientras mejor rea el escenario de prueba, mejor podrás pulir.

[humanista]

hay un idopinion autonumérico y clave, con lo cual -siguiendo tus indicaciones- he quitado el distinct.

también he puesto el IN y he ordenado de mayor a menor restricción las condiciones.

lo que no sé es hasta dónde (más o menos) puede estar el límite (de eficiencia) del Apache y SQL para tablas de miles de registros...

gracias!!!