¿Cuánto tiempo tarda una consulta que devuelve 5 millones de registros?

Question

Me doy cuenta de que la respuesta debería ser "el menor tiempo posible", pero estoy tratando de aprender a optimizar las bases de datos y no tengo idea de cuál es el tiempo aceptable para mi hardware.

Para empezar, estoy usando mi máquina local con una copia de sql server 2008 express. Tengo un procesador de doble núcleo, 2 GB de ram y un sistema operativo de 64 bits (si eso hace la diferencia). Solo estoy usando una tabla simple con aproximadamente 6 campos varchar.

Al principio he consultado los datos sin ninguna indexación. Esto tomó una cantidad de tiempo ridículamente larga, así que cancelé y agregué un índice agrupado (usando el PK) a la mesa. Esto redujo el tiempo a 1 minuto y 14 segundos. No tengo idea si esto es lo mejor que puedo obtener o si aún puedo reducir esto aún más.

¿Estoy limitado por mi hardware o hay algo más que pueda hacer en mi tabla/base de datos/consultas para obtener resultados más rápidos?

FYI Solo estoy usando un SELECT * FROM estándar para recuperar mis resultados.

Gracias!

EDITAR: Solo para aclarar, solo estoy haciendo esto con fines de prueba. NO NECESITO extraer todos los datos, solo lo uso como una prueba consistente para ver si puedo reducir los tiempos de consulta.

Supongo que lo que estoy preguntando es: ¿hay algo que pueda hacer para acelerar el rendimiento de mis consultas que no sea a) actualizar el hardware yb) agregar índices (suponiendo que el esquema ya es bueno)?

Answer 1

Creo que está haciendo la pregunta incorrecta.

Antes que nada, ¿por qué necesita tantos artículos a la vez en la máquina local? ¿Qué quieres hacer con ellos?

¿Por qué le pregunto? Creo que esta cantidad de datos se transferirá a alguna parte. Y solo en este momento debe medir el tiempo de transferencia de los datos.

E incluso en esta situación quiero hacer consejo para ti:

Sus aplicaciones no deben seleccionar 5 millones de discos en el momento. Intenta dividir tu consulta y obtener datos parcialmente.

ACTUALIZACIÓN:

como usted dice está haciendo esto para las pruebas, te sugieren a:

1. Retire * de la consulta - servidor SQL pasa algún tiempo para resolver esto.
2. Trate de poner sus datos en el almacenamiento de algunos datos temporales. Intente utilizar VIEW o tabla temporal para esto.
3. intenta utilizar algunos cache plan on your server

Pero todavía no entienden - ¿por qué necesita este tipo de pruebas si su aplicación no volvería a utilizar dicha consulta? La prueba solo para las pruebas es un mal momento para gastar.

Answer 2

Mire el plan de ejecución de la consulta. Si su consulta está haciendo un escaneo de tabla, obviamente llevará mucho tiempo.El plan de ejecución de consultas puede ayudarlo a decidir qué tipo de indexación necesitará en la tabla. Además, la creación de particiones de tabla puede ayudar a veces en los casos en que los datos están particionados por una condición (generalmente fecha y hora).

Answer 3

La mejor forma optimizada depende de la estrategia de indexación que elija. Como muchas de las respuestas anteriores, yo también diría que particionar la tabla ayudaría a veces. Y no es la mejor práctica consultar todos los mil millones de registros en un marco de tiempo único. Te dará resultados muy mejorados si pudieras intentar consultar parcialmente con las iteraciones. puede consultar este enlace para despejar las dudas sobre los requisitos mínimos para el servidor Sql 2008 Minimum H/W and S/W Requirements for Sql server 2008

Answer 4

Al procesar 5 millones de filas, casi el 100% va de spool a tempdb. debería intentar optimizar su Db temporal agregando archivos adicionales. si tiene varias unidades en discos separados, debe dividir los datos de la tabla en diferentes archivos ndf ubicados en discos separados. la paritización no ayuda cuando se consultan todos los datos en el disco U también puede usar una sugerencia de consulta para forzar el paralelismo MAXDOP, esto aumentará la utilización de la CPU. Asegúrese de que las columnas contengan pocos nulos como sea posible y reconstruya sus índices y estadísticas.