none
Tabla 60.000 registros lenta RRS feed

  • Pregunta

  • Buenos días,

    tengo un problema con una tabla, tiene apenas 60.000 registros y al hacer un simpre select de la tabla tarda demasiado, entre 4-7 segundos, cuando otras con más registros tardan menos.

    Tiene clave primaria numérica.

    ¿Alguna idea?

    Gracias!

    martes, 23 de enero de 2018 9:32

Respuestas

  • 60.000 registros no son muchos, sobre todo si no son muy grandes. Pero si nos ponemos en el peor caso, de registros que midan 8KB, entonces estaríamos hablando de casi medio gigabyte de datos. En un disco normalito, que lea unos 100 MB por segundo, esto supondría ya 5 segundos, que es consistente con los tiempos que estas viendo. Cierto que puede ser que tus registros sean mas pequeños, pero también el archivo puede estar fragmentado en disco y habría que sumar los tiempos de búsqueda de los distintos fragmentos. Aparte de que si tienes BLOBs en el registro, el hacer el select * se tienen que recuperar desde los bloques donde estén almacenados y serían "seeks" adicionales en el disco.

    Prueba a ejecutar la sentencia con SET STATISTICS IO ON, a ver cuántas páginas está leyendo (y si están cachesdas o en disco). Pide también el plan de ejecución en SSMS, a ver si se ve algo inusual (en principio debería hacer solo un clustered index scan).

    Mira a ver si el clustered index está fragmentado, y en ese caso defragméntalo (pero ten en cuenta que esto es solo una defragmentación lógica, no defragmentará el .mdf en disco).

    Si lo que más te importa es la velocidad de lectura (y no la de escritura) puedes aplicarle a la tabla una compresión de página, que típicamente triplicará la velocidad de lectura.

    martes, 23 de enero de 2018 13:04

Todas las respuestas

  • Hola:

    Se tan amable de poner la instrucción sql que tienes.

    Un saludo.

    Gemma

    martes, 23 de enero de 2018 10:01
  • Hola,

    es un simple select: select * from TABLA

    Gracias!

    martes, 23 de enero de 2018 10:45
  • La velocidad del select va directametne relacionada con los indices de la tabla, en tu caso esto es un poco "absurdo" debido a que seleccionas toda la tabla o todos los registros por loq que te tarda lo qeu te tarda por el volumen que pides.

    La solución a tu problema está en afinar la select con un where y establecer idnices para que sea eficiente.

    por ejemplo en lugar ed pedir toda la tabla muestra los primeros 1000 registros con un order by y crea indices por los campos del order by.

    martes, 23 de enero de 2018 12:34
  • 60.000 registros no son muchos, sobre todo si no son muy grandes. Pero si nos ponemos en el peor caso, de registros que midan 8KB, entonces estaríamos hablando de casi medio gigabyte de datos. En un disco normalito, que lea unos 100 MB por segundo, esto supondría ya 5 segundos, que es consistente con los tiempos que estas viendo. Cierto que puede ser que tus registros sean mas pequeños, pero también el archivo puede estar fragmentado en disco y habría que sumar los tiempos de búsqueda de los distintos fragmentos. Aparte de que si tienes BLOBs en el registro, el hacer el select * se tienen que recuperar desde los bloques donde estén almacenados y serían "seeks" adicionales en el disco.

    Prueba a ejecutar la sentencia con SET STATISTICS IO ON, a ver cuántas páginas está leyendo (y si están cachesdas o en disco). Pide también el plan de ejecución en SSMS, a ver si se ve algo inusual (en principio debería hacer solo un clustered index scan).

    Mira a ver si el clustered index está fragmentado, y en ese caso defragméntalo (pero ten en cuenta que esto es solo una defragmentación lógica, no defragmentará el .mdf en disco).

    Si lo que más te importa es la velocidad de lectura (y no la de escritura) puedes aplicarle a la tabla una compresión de página, que típicamente triplicará la velocidad de lectura.

    martes, 23 de enero de 2018 13:04