¿Por qué el desplazamiento de LÍMITE superior MYSQL ralentiza la consulta?

En resumen: una tabla con más de 16 millones de registros [2 GB de tamaño]. Cuanto mayor es el desplazamiento de LIMIT con SELECT, más lenta se vuelve la consulta, cuando se usa ORDER BY * primary_key *

Entonces

SELECT * FROM large ORDER BY `id`  LIMIT 0, 30 

toma mucho menos de

SELECT * FROM large ORDER BY `id` LIMIT 10000, 30 

Eso solo ordena 30 registros y lo mismo de todos modos. Entonces no es la sobrecarga de ORDER BY.
Ahora, al buscar las últimas 30 filas, toma alrededor de 180 segundos. ¿Cómo puedo optimizar esa simple consulta?

Es normal que las compensaciones más altas ralenticen la consulta, ya que la consulta necesita contar los primeros OFFSET + LIMITregistros (y tomar solo LIMITde ellos). Cuanto mayor sea este valor, más tiempo se ejecutará la consulta.

La consulta no puede ir directamente a OFFSET, porque, en primer lugar, los registros pueden tener una longitud diferente y, en segundo lugar, puede haber huecos en los registros eliminados. Necesita verificar y contar cada registro en su camino.

Suponiendo que se idtrata PRIMARY KEYde una MyISAMtabla, puede acelerarla utilizando este truco:

SELECT  t.*
FROM    (
        SELECT  id
        FROM    mytable
        ORDER BY
                id
        LIMIT 10000, 30
        ) q
JOIN    mytable t
ON      t.id = q.id

Ver este artículo:

• Rendimiento de MySQL ORDER BY / LIMIT: búsquedas de filas tardías

Yo tuve exactamente el mismo problema. Dado el hecho de que desea recopilar una gran cantidad de estos datos y no un conjunto específico de 30, probablemente ejecutará un bucle e incrementará el desplazamiento en 30.

Entonces, lo que puedes hacer es:

1. Mantenga la última identificación de un conjunto de datos (30) (por ejemplo, lastId = 530)
2. Agregar la condición WHERE id > lastId limit 0,30

Por lo tanto, siempre puede tener un desplazamiento CERO. Te sorprenderá la mejora del rendimiento.

MySQL no puede ir directamente al registro número 10000 (o al byte 80000 como sugiere) porque no puede asumir que está empaquetado / ordenado de esa manera (o que tiene valores continuos de 1 a 10000). Aunque podría ser así en la actualidad, MySQL no puede asumir que no hay agujeros / huecos / identificadores eliminados.

Entonces, como se señaló en bobs, MySQL tendrá que buscar 10000 filas (o atravesar la entrada número 10000 del índice id) antes de encontrar las 30 para regresar.

EDITAR : para ilustrar mi punto

Tenga en cuenta que aunque

SELECT * FROM large ORDER BY id LIMIT 10000, 30 

sería lento (er) ,

SELECT * FROM large WHERE id >  10000 ORDER BY id LIMIT 30 

sería rápido (er) y devolvería los mismos resultados siempre que no falten ids (es decir, huecos).

Encontré un ejemplo interesante para optimizar las consultas SELECT ORDER BY id LIMIT X, Y. Tengo 35 millones de filas, por lo que me tomó como 2 minutos encontrar un rango de filas.

Aquí está el truco:

select id, name, address, phone
FROM customers
WHERE id > 990
ORDER BY id LIMIT 1000;

Simplemente ponga el DONDE con la última identificación que obtuvo para aumentar mucho el rendimiento. Para mí fue de 2 minutos a 1 segundo :)

Otros trucos interesantes aquí: http://www.iheavy.com/2013/06/19/3-ways-to-optimize-for-paging-in-mysql/

Funciona también con cuerdas.

La parte que lleva mucho tiempo de las dos consultas es recuperar las filas de la tabla. Lógicamente hablando, en la LIMIT 0, 30versión, solo se necesitan recuperar 30 filas. En la LIMIT 10000, 30versión, se evalúan 10000 filas y se devuelven 30 filas. Puede haber alguna optimización en el proceso de lectura de datos, pero considere lo siguiente:

¿Qué pasaría si tuviera una cláusula WHERE en las consultas? El motor debe devolver todas las filas que califican, y luego ordenar los datos, y finalmente obtener las 30 filas.

Considere también el caso en el que las filas no se procesan en la secuencia ORDER BY. Todas las filas que califican deben clasificarse para determinar qué filas devolver.

Para aquellos que estén interesados ​​en una comparación y cifras :)

Experimento 1: el conjunto de datos contiene aproximadamente 100 millones de filas. Cada fila contiene varios BIGINT, TINYINT, así como dos campos TEXT (deliberadamente) que contienen aproximadamente 1k caracteres.

• Azul: = SELECT * FROM post ORDER BY id LIMIT {offset}, 5
• Naranja: = Método @ Quassnoi. SELECT t.* FROM (SELECT id FROM post ORDER BY id LIMIT {offset}, 5) AS q JOIN post t ON t.id = q.id
• Por supuesto, el tercer método ... WHERE id>xxx LIMIT 0,5no aparece aquí, ya que debería ser un tiempo constante.

Experimento 2: algo similar, excepto que una fila solo tiene 3 BIGINT.

• verde: = el azul antes
• rojo: = la naranja antes