sql - repetidos - Agrupar haciendo consultas astronómicamente más largas
sql agrupar por rangos (2)
* Como primera nota, solo tengo acceso de lectura a mi servidor. Solo, FYI, ya que parece surgir mucho ...
Servidor: DB2 (6.1) para i (IBM)
Tengo una consulta que estoy ejecutando en una tabla que tiene 19 mil filas (no las diseño, solo las consulto). He estado limitando mis datos de devolución a 10 filas (*) hasta que soluciono esta consulta, por lo que los tiempos de devolución son un poco más razonables.
El diseño básico es que necesito obtener datos sobre las categorías de productos que vendemos semana por semana, utilizando columnas: WEEK_ID y CATEGORY. Aquí está el código de ejemplo (con algunos bits importantes #### out)
SELECT WEEK_ID, CATEGORY
FROM DWQ####.SLSCATW
INNER JOIN DW####.CATEGORY
ON DWQ####.SLSCATW.CATEGORY_NUMBER = DW####.CATEGORY.CATEGORY_NUMBER
WHERE WEEK_ID
BETWEEN 200952 AND 201230 --Format is year/week
GROUP BY WEEK_ID, CATEGORY
Si hago un comentario sobre la última línea, puedo recuperar 100 filas en 254 ms. Si vuelvo a poner esa línea en mi retorno, tomará más tiempo del que he tenido paciencia para esperar :-). (El tiempo más largo que he esperado es de 10 minutos).
Esta pregunta tiene dos partes. La primera pregunta es bastante rudimentaria: ¿Es esto normal? Hay 50 categorías (más o menos) y 140 semanas (más o menos) a las que estoy tratando de condensar. Me doy cuenta de que hay mucha información para condensar fuera de las filas de 19mil, pero esperaba limitar mi consulta a 10 filas devueltas, ¿minimizaría la cantidad de tiempo?
Y, si no soy solo un n00b completo, y esto de hecho no debería tomar varios minutos, ¿qué ocurre exactamente con mi SQL?
He buscado en Google WHERE la optimización de las declaraciones y parece que no puedo encontrar nada. Todos los enlaces y explicaciones son más que bienvenidos.
Disculpas por la publicación de un novato ... todos tenemos que empezar en algún lado, ¿verdad?
(*) usando SQLExplorer, mi IDE, una implementación de Eclipse de Squirrel SQL.
Los índices en WEEK_ID, CATEGORY (y posiblemente CATEGORY_NUMBER) son la única manera de hacerlo realmente rápido, por lo que debe convencer al DBO para que los introduzca.
No estoy seguro de cómo el servidor maneja el group by cuando no hay funciones de agregación en la consulta. En función de sus respuestas en los comentarios, solo trataría de agregarlas:
SELECT
...,
SUM(SalesCost) as SalesCost,
SUM(SalesDollars) as SalesDollars
FROM
...
Deje el resto de la consulta tal como está.
Si eso no resuelve el problema, es posible que tenga índices faltantes. Intentaré averiguar si hay un índice donde WEEK_ID es la única columna o dónde está la primera columna. También podría verificar si tiene otra columna temporal (es decir, fecha de transacción o algo similar) en la misma tabla que ya está indexada. Si es así, podrías usar eso en su lugar en la cláusula where .
Sin índices correctos, el servidor de la base de datos se ve obligado a hacer un escaneo completo de la tabla, y eso podría explicar sus problemas de rendimiento. 39 millones de filas requieren una cantidad no despreciable de tiempo para leer desde el disco.
También verifique que el tipo de datos de WEEK_ID sea int o similar, solo para evitar la conversión innecesaria en su consulta.
Para evitar una exploración de tabla en la tabla Categoría, debe asegurarse de que Category_Number también esté indexado. (Probablemente ya lo sea, ya que supongo que es la clave de esa mesa).