Es una de esas cosas que parece tener una curva extraña en la que cuanto más lo pienso, más sentido tiene. Hasta cierto punto, por supuesto. Y luego no tiene sentido para mí en absoluto.¿Por qué la paginación es tan cara a los recursos?
¿Me iluminas?
Porque en la mayoría de los casos debe ordenar primero los resultados. Por ejemplo, cuando busca en Google, you can view only up to 100 pages of results. No se molestan en ordenar por rango de página más allá de 1000 sitios web para la palabra clave dada (o combinación de palabras clave).
La paginación es rápida. La clasificación es lenta.
Esta es una pregunta muy vaga. Necesitaríamos un ejemplo concreto para tener una mejor idea del problema.
Lubos es correcto, el problema no es el hecho de que está paginación (que tiene una cantidad enorme de datos por el cable), sino que tiene que averiguar lo que realmente está sucediendo en la página ..
El hecho de que necesite una página implica que hay una gran cantidad de datos. Una gran cantidad de datos toma mucho tiempo para ordenar :)
Pensé que querías decir pagination of the printed page - ahí es donde me corté los dientes. Iba a entrar en un gran monólogo sobre la recopilación de todo el contenido de la página, el posicionamiento (un gran número de reglas aquí, los motores de restricción son bastante útiles) y la justificación ... pero al parecer hablabas sobre el proceso de organizar la información en páginas web .
Para eso, supongo que acierta en la base de datos. El acceso al disco es lento. Una vez que lo tienes en la memoria, la clasificación es barata.
Por supuesto, ordenar una consulta aleatoria lleva tiempo, pero si tiene problemas con la misma consulta paginada que se usa regularmente, hay algún problema con la configuración de la base de datos (indexación incorrecta/ninguna, poca memoria etc. No soy un administrador de base de datos) o está haciendo paginación seriamente incorrecta:
Terriblemente incorrecto: por ejemplo haciendo select * from hugetable where somecondition; en una matriz obteniendo el recuento de páginas con el array.length eligen los índices relevantes y dicard la matriz, y luego repiten esto para cada página ... Eso es lo que llamo seriamente incorrecto.
La mejor solución dos consultas: una obteniendo solo el conteo y luego otra obteniendo resultados usando limit y offset. (Algunos servidores patentados no estándar-sql pueden tener una opción de consulta, no lo sé)
La mala solución podría funcionar muy bien en las tablas pequeñas (de hecho, no es impensable que sea más rápida en tablas muy pequeñas, porque el sobrecargar dos consultas es más grande que obtener todas las filas en una consulta. No digo que es así que ...) pero tan pronto como la base de datos comienza a crecer, los problemas se vuelven obvios.
La combinación de LIMIT con una compensación grande, y ORDER BY GROUP BY, puede seguir requiriendo muchos recursos, por lo que Google no obtiene una cuenta completa (nada más de 1000 resultados y es una 'estimación') ni paginate más allá de los primeros 1000 resultados. – thomasrutter
Esta pregunta parece bastante bien cubierto, pero voy a añadir un poco de algo específico de MySQL, ya que atrapa a cabo una gran cantidad de personas:
Evitar el uso de SQL_CALC_FOUND_ROWS. A menos que el conjunto de datos sea trivial, contar las coincidencias y recuperar x cantidad de coincidencias en dos consultas por separado será mucho más rápido. (Si es es trivial, apenas notará una diferencia en ambos sentidos.)
Una búsqueda casual a través de SO después de la cena, un consejo intrigante, una prueba de 10 minutos y luego un ajuste de 10 minutos, ¡y listo, la carga de mi base de datos se reduce a la mitad en mi sitio más pesado! ¡Gracias! – jTresidder
Es un buen consejo. Hacer el conteo en otra consulta puede contar sin obtener datos de fila y puede usar solo índices. Sin embargo, ¿funciona tan bien en InnoDb como en MyIsam? Tengo la extraña sensación de que es diferente, pero podría estar equivocado. – thomasrutter
Si mira el título, la pregunta tiene sentido, cuando lee la pregunta en sí, deja de tener sentido. –