Cita:
Iniciado por kiko's 
Además PHP no se diseñó para tratar grandes volúmenes de información. Sigo manteniendo que si tuviera que hacer una consulta de 10000 registros sería un poco burro cargar en una variable toda la información para SÓLO contar el número de registros que devolvería esa consulta.
Por cierto, nadie ha dicho que en esa web no hicieran la comprobación desde el propio ordenador, así que ahí poco tiene que ver la capacidad de la red.
Una vez más te agradezco tu aporte, pero finalmente has terminado dándome la razón. Para contar mejor COUNT que mysql_num_rows()
PS: Perdón por el doble post.
Tengo la impresión que no estás entendiendo mucho lo que te estoy diciendo, así que lo aclararé:
1) Usa un mejor lenguaje. La gentileza en los foros es muy apreciada, especialmente porque no podemos vernos el rostro, y el lenguaje escrito a veces no nos permite comprender humoradas entre costumbres de países distintos. Esto lo digo porque tus posts se sienten "ásperos"; nadie aquí califica de "burradas"; cuando usas ese término parece que asumieses una postura de superioridad que resulta molesta a los demás. A mí, al menos, me causa mala impresión.
2) Mis notas sobre lo afirmado en esa web se referían exclusivamente a que no podías usar eso como referencia de lo bueno o malo de los métodos, porque los planteos de los
case eran
incompatibles. Al no tratarse de procesos que usan los mismos tipos de recursos, no puede hacerse una prueba de benchmarking. Es lo mismo que estar comparando la performance de un avión con la de un barco... Son cosas y entornos distintos,
lo que no implica que una de ellas esté bien o mal hecha.
Si la comparación se hubiese hecho entre un SP que invocara la función FOUND_ROWS() para devolver el valor, contra una consulta con COUNT(), tendría algún sentido porque ambas se resuelven en MySQL, y con el mismo server. Pero comparar el resultado de una consulta
en MySQL contra una función afectada por el
tráfico de red,
en un lenguaje de programación no se puede hacer. Hay "ruido" en la información.
En esencia, esa prueba no te está diciendo nada. Es absolutamente imprecisa y no nos está informando si las consultas en sí tienen una diferencia real en tiempo de ejecución.
3) Respecto a si la prueba se hizo o no en la misma PC, eso tiene cierta irrelevancia, porque
en cualquiera de los dos casos habría una diferencia dada por la performance del hardware y de la conexión.
En primer lugar, porque los datos son enviados por el servicio de MySQL a través de un buffer de datos, que tiene un límite.
En segundo lugar, si la consulta genera más de 64 Kb de datos, requiere más de un bloque de datos en memoria para almacenarse, y luego de cierta cantidad de uso de memoria el sistema operativo empeiza a hacer swapping al disco, lo que le agrega overhead.
En tercer lugar, los datos, aún en localhost, son enviados a través del protocolo TCP/IP, ya que la conexión entre la aplicación y el servicio se realiza solamente a través de este; el uso de localhost sólo imprime rapidez al proceso, pero no evita la fragmentación en datagramas, sino la de IP.
En cuarto lugar, luego de esto, PHP tiene que localizar en memoria todo, por lo que en cierta forma
estás usando el doble de recursos de RAM necesarios: Los que usa la aplicación para los datos, y los que usó MySQL para generarlos (y que representan memoria no usable por PHP)...
Como puedes apreciar, los considerandos son algo más complejos.
Resumiendo:
- Si quieres hacer benchmarking entre consultas, asegúrate de que el
escenario de las consultas es similar. No alcanza con
parecerlo.
- Hacer la prueba planteada con la función mysql_num_rows() puede incluso ser una buena idea,
dependiendo de lo que estés tratando de averiguar. Obviamente no es óptima para saber la performance de una consulta desde la óptica de MySQL.
- Si quieres calcular la
cantidad de registros afectados por una consulta INSERT/UPDATE/DELETE, se usa
ROW_COUNT().
- Si sólo quieres
contar los registros, con o sin condiciones, se usa
COUNT(). Esto no lee la tabla, y por eso es más rápida.
- Si le pones condiciones obligarás a MySQL a leer la tabla (eso sería una prueba interesante).
- Una consulta SELECT
puede usar SQL_CALC_FOUND_ROWS para obtener la cantidad de registros que produce la consulta.
- Si la consulta efectivamente tendrá demasiados registros, y usa DISTINGT o GROUP BY, puede de todos modos optimizarse usando
SQL_BIG_RESULT, para decirle a MySQL que procese con tablas temporales en disco y no en memoria. Eso afectará la performance de todos modos.
- La
misma consulta (y esto es muy importante), en la
misma PC, con los
mismos datos, pero en
momentos diferentes (consecutivos o no) pueden tener una performance distinta porque los DBMS no trabajan con métodos constantes, sino estadísticos. Esto hace que el parser pueda usar alternativas diferentes para ejecutar las mismas consultas dependiendo de los resultados anteriores, de los índices, de las condiciones y también del hardware usado.
Hay mucha tela para cortar en estos temas...