2011-08-18 14 views
6

Hola tengo una tabla db de 7milion records para probar la velocidad de consultas.QUERY velocidad con límite y milion records

He probado mis 2 consultas que son la misma consulta con diferentes parámetros de límite:

consulta 1 -

SELECT * 
FROM  table 
LIMIT  20, 50; 

consulta 2 -

SELECT * 
FROM  table 
LIMIT  6000000, 6000030; 

tiempos de consulta Exec son:

  1. consulta 1 - 0.006 seg
  2. Consulta 2 - 5.500 seg

En ambas consultas, estoy ir a buscar mismo número de registros, pero en el segundo caso se trata de tomar más tiempo. ¿Alguien puede explicar las razones detrás de esto?

+0

¿Tiene algún índice? ¿Tienes una clave principal? Si no tienes ninguno, entonces esto tiene sentido para mí. –

+0

@amir si no hay indización para ambas consultas debe ser la misma prueba, ¿no? ¿o si pongo la segunda consulta del índice tomará la misma hora de la primera consulta? – sbaaaang

+0

si no tiene ningún índice, entonces no creo que MySQL pueda omitir las primeras 6000000 filas. Debe tener al menos algún índice principal para omitir las filas. Tal vez alguien más puede confirmar esto? También podríamos probar esto. –

Respuesta

8

Sin examinarlo demasiado de cerca, mi suposición es que esto ocurre porque la primera consulta solo tiene que leerse en el registro número 50 para devolver los resultados, mientras que la segunda consulta debe leer seis millones antes de devolver los resultados. Básicamente, la primera consulta se corta más rápido.

yo supongo que esto tiene una increíble cantidad que ver con la composición de la mesa - tipos de campo y llaves, etc.

Si un registro se compone de campos de longitud fija (por ejemplo, CHAR VARCHAR vs.), entonces el DBMS puede calcular dónde comienza el n-ésimo registro y salta allí. Si su longitud variable, entonces tendría que leer los registros para determinar dónde comienza el n-ésimo registro. De forma similar, supondría además que las tablas que tienen claves primarias apropiadas serían más rápidas de consultar que aquellas sin tales claves.

+0

eso es lo que pienso con certeza :(y creo que no hay soluciones para eso, ¿no? Caché de consultas :( – sbaaaang

+1

@user No puedo pensar en una solución fuera de lo común. Lo único que podría pensar, y esto es un ** pirateo total **, sería agregar un campo de fecha y hora para marcar la creación del registro, luego agregue un índice en ese campo y luego ordene ese campo en la consulta. No lo he probado, pero ** podría ** engañar a la base de datos para que se limite en función de esa clave, lo que podría hacer que la consulta se ejecute en O (1) vez, pero no contaría con eso. Además, no es exactamente la consulta que tienes arriba, porque el orden de clasificación predeterminado no está definido por la especificación: estarías emulando una convención común en lugar de una especificación: YMMV. – AgentConundrum

+0

gracias por hack intentaré smethings de todos modos solo estaba preguntando las diferencias a comprenda mejor cómo mysql procesa registros db;) – sbaaaang

6

Creo que la ralentización está ligada al hecho de que está utilizando límites con compensaciones y está consultando la tabla sin contexto adicional para la indexación. Es posible que el primero sea más rápido porque puede llegar al offset más rápido.

+1

algunos googlean sugieren que mysql cuenta cada fila hasta que llegue al offset ... así que adivinar que lleva más tiempo llegar a xxxxx en comparación con la 20a fila. –

+0

esa es la verdadera indexación, no existe, pero no es un problema de velocidad, solo preguntaba sobre la diferencia;) – sbaaaang

4

Es la diferencia entre devolver 50 filas y 6000030 filas (o ~ 1 millón de filas, ya que dijo que solo había 7 millones de filas).

con dos argumentos, el primer argumento especifica el desplazamiento de la primera fila volver, y el segundo especifica el número máximo de filas para volver. El desplazamiento de la fila inicial es 0 (no 1):

SELECCIONE * FROM tbl LÍMITE 5,10; # Recuperar filas 6-15

http://dev.mysql.com/doc/refman/5.0/en/select.html

Además, creo que usted está buscando 30 páginas fila para que sus consultas deben estar usando 30 como el segundo parámetro en la cláusula de límite.

SELECT * 
FROM  table 
LIMIT  20, 30; 

SELECT * 
FROM  table 
LIMIT  6000000, 30; 
+0

El 2do parámetro podría ser un factor contribuyente porque la consulta de hecho devuelve muchas filas más ... No creo que sea justo decir que esto no proporciona una respuesta ... su respuesta es que devolver un bajillón de filas lleva más tiempo ... y es probablemente parcialmente correcto. –

+0

ok ... ¿así que los registros en ese rango también se analizan o se saltan? Creo que se analizaron o no habrá diferencia, mientras que la diferencia existe, ¿verdad? – sbaaaang

+0

el desplazamiento es mínimo en comparación con el recuento de filas. \t Estaba desenterrando la referencia – dotjoe

Cuestiones relacionadas