Оптимизировать консультацию SQL

У меня есть следующая консультация SQL

SELECT
        (SELECT NVL(max(f_mov), '') AS f_mov
        FROM   tmp_vtas_clientes AS b
        WHERE  a.c_linea = b.c_linea
                 AND a.c_almacen = b.c_almacen
                 AND a.c_producto = b.c_referencia
                 AND a.d_producto = b.d_referencia
                 AND a.d_referencia_prov = b.d_referencia_prov
                 AND a.c_barra = b.c_barra
                 AND a.c_plu = b.c_plu
                 AND a.c_talla = b.c_talla
                 AND a.c_color_proveedor = b.c_color_proveedor
                 AND a.c_proveedor = b.c_proveedor
                 AND a.c_clasificacion = b.c_clasificacion
                 AND a.c_categoria = b.c_categoria
                 AND a.c_subcategoria = b.c_subcategoria
                 AND a.c_segmento = b.c_segmento
                 AND a.c_sector = b.c_sector
                 AND a.c_marca = b.c_marca
                 AND a.c_coleccion = b.c_coleccion
                 AND a.d_presentacion = b.d_presentacion
                 AND a.ubicacion = b.ubicacion
                 AND a.f_creacion = b.f_creacion
                 AND a.c_grupo = b.c_grupo
                 AND a.c_ciudad = b.c_ciudad)
    f_mov,
    a.c_linea,
    a.c_almacen,
    a.c_producto,
    a.d_producto,
    a.d_referencia_prov,
    a.c_barra,
    a.c_plu,
    a.c_talla,
    a.c_color_proveedor,
    a.c_proveedor,
    a.c_clasificacion,
    a.c_categoria,
    a.c_subcategoria,
    a.c_segmento,
    a.c_sector,
    a.c_marca,
    a.c_coleccion,
    a.d_presentacion,
    a.ubicacion,
    a.f_creacion,
    a.c_grupo,
    a.c_ciudad

FROM tmp_resumen1 A INTO TEMP tmp_resumen1_ventas_clientes WITH NO LOG;

У этой консультации очень высокое время скрытости есть и в общем с 0 результатами существует какой-то способ или хорошие практики, которые позволяла бы мне оптимизировать консультация?

1
задан 04.11.2016, 09:32
3 ответа

Проблема - субконсультация, это слишком много полей, которые нужно сравнивать.

Первое состояло бы в том, чтобы реализовывать анализ информации, которую ты должен получать. Нормализовать твою таблицу, чтобы иметь правильно чужеземные ключи и мочь объединять два подмостков.

Если идея состоит в том, чтобы получать от двух подмостков максимальную дату реестров, которые совпадают в Вашей информации, ты мог бы получать все реестры, которые эквивалентные с INTERSECT. Получая эту информацию ты получаешь максимальный реестр согласно Вашей дате. Это, чтобы получать дату, которую ты получаешь от субконсультации. Только осталось бы реализовывать JOIN к таблице tmp_resumen1, чтобы получать оставшуюся часть информации

3
ответ дан 24.11.2019, 14:30

Я думаю, что проблема - из-за субконсультации, но не из-за полей (которыми оно также может быть поэтому), а потому что эта субконсультация выполняет ее из-за каждого реестра, у которого есть таблица tmp_resumen1.

То, что я сделал бы, с одной стороны выполнять субконсультацию, чтобы видеть, что он бросает хорошо. Если он бросает хорошо проблему, это тот, что я говорю тебе, которое выполняет ее из-за каждого реестра таблицы. Все же, пересекать из-за стольких полей одновременно не хорошая политика. Ты был бы должен решать это используя единственные ключи и пересекая из-за основных.

В любом случае, чтобы это решать, как ты считаешь это смонтированным, я предлагаю тебе альтернативу:

SELECT
'XXXXXXX' AS fakeField,
Tmp.f_mov,
a.c_linea,
a.c_almacen,
a.c_producto,
a.d_producto,
a.d_referencia_prov,
a.c_barra,
a.c_plu,
a.c_talla,
a.c_color_proveedor,
a.c_proveedor,
a.c_clasificacion,
a.c_categoria,
a.c_subcategoria,
a.c_segmento,
a.c_sector,
a.c_marca,
a.c_coleccion,
a.d_presentacion,
a.ubicacion,
a.f_creacion,
a.c_grupo,
a.c_ciudad
FROM tmp_resumen1 A 
INNER JOIN (
SELECT 
    'XXXXXXX' AS fakeField,
    NVL(max(f_mov), '') AS f_mov        
FROM   tmp_vtas_clientes AS b
WHERE  a.c_linea = b.c_linea
     AND a.c_almacen = b.c_almacen
     AND a.c_producto = b.c_referencia
     AND a.d_producto = b.d_referencia
     AND a.d_referencia_prov = b.d_referencia_prov
     AND a.c_barra = b.c_barra
     AND a.c_plu = b.c_plu
     AND a.c_talla = b.c_talla
     AND a.c_color_proveedor = b.c_color_proveedor
     AND a.c_proveedor = b.c_proveedor
     AND a.c_clasificacion = b.c_clasificacion
     AND a.c_categoria = b.c_categoria
     AND a.c_subcategoria = b.c_subcategoria
     AND a.c_segmento = b.c_segmento
     AND a.c_sector = b.c_sector
     AND a.c_marca = b.c_marca
     AND a.c_coleccion = b.c_coleccion
     AND a.d_presentacion = b.d_presentacion
     AND a.ubicacion = b.ubicacion
     AND a.f_creacion = b.f_creacion
     AND a.c_grupo = b.c_grupo
     AND a.c_ciudad = b.c_ciudad
)Tmp  ON a.fakeField = Tmp.fakeField
INTO TEMP tmp_resumen1_ventas_clientes WITH NO LOG;

Ты увидишь, что то, что я сделал, состоит в том, чтобы решать консультации по отдельности и создавать фиктивное поле, чтобы мочь зацеплять два результата. Я не смог тестировать это, но думаю, что понимают, которое я имею в виду.

1
ответ дан 24.11.2019, 14:30

Давайте видеть, переместив консультацию немного из-за tidy, я вижу, что проблема находится в субконсультации, которая слишком тяжелая.

Прежде всего по вине функций, которые ты применяешь к полю f_mov. Подумай, что прикладные функции таким образом должны применяться во всех результатах консультации. В этом случае, поскольку ты используешь субконсультацию, лучшее состояло бы в том, чтобы применять вышеупомянутые функции к полю f_mov вне субконсультации для того, чтобы я схватил только, они работали единственный раз.

Следующим, которое он было бы нужно оптимизировать, был бы порядок where субконсультации, если только механизмом базы данных, которую ты использовал бы, не был Oracle, как комментирует приятель sstan, что он, как кажется, реорганизует внутри where, чтобы ускорять консультации. Подумай, что вся эта связка чеснока определяющих факторов они, должно быть, сравнивают с каждым из полей таблицы tmp_vtas_clientes, а следовательно его состояло бы в том, чтобы помещать определяющие факторы, которые более точные - это во время отказывания от всего, что больше в начале связки чеснока ANDs. А именно ссылка статьи очевидно более специфическая, чем склад в том, который, потому что в этой консультации у тебя конечно было очень много продуктов в том же складе в c_almacen. Просто реорганизуя AND из-за этого вопроса уже ты был бы должен уберегаться достаточно времени.

-1
ответ дан 24.11.2019, 14:30
  • 1
    Это не является верным. Выполнять функцию не стоит совсем не сравненный, чтобы извлекать данные о таблице в s и # 237;. Проблема другая. И относительно порядка условий, SQL в базах данных они не функционируют как leguajes программирования t и # 237; пики, где условия работают в команде. База данных (и в этом случае он кажется Oracle) - достаточно умное как чтобы реорганизовать условия в самом эффективном порядке автоматически, так что порядок условий не затрагивает ни в чем результат решения. – sstan 20.10.2016, 17:30
  • 2
    Функции в этом случае est и # 225; n в select, поскольку они не являются такими агрессивными как будто они были в where, это я не отказываю в этом тебе, но этом, чего механизм базы данных преобразовывает and не ты sabr и # 237; чтобы говорить. Возможно, что, если какие-то поля имели, и #237; ndices механизм базы данных оказал предпочтение им, но если нет индексов механизм базы данных, я сомневаюсь, что он - предсказатель. – NetVicious 21.10.2016, 02:46
  • 3
    Иногда, s и # 237; покажись предсказателем:), прежде всего, если мы говорим о Oracle, которого он поддерживает, будьте и # 237; sticas на подмостках, как количество реестров, распределении данных в различных колоннах, и т.д.... И целиком, это дает ему количество ценной информации, которая позволяет ему реорганизовать и оптимизировать порядок операций SQL, даже, если нет, и #237; ndices. Конечно, без и #237; ndices, результат не будет быть таким хорошим, и вероятно это была проблема OP. Но порядок условий письменные в SQL они ничего не затрагивают, потому что Oracle меняет их автоматически. – sstan 21.10.2016, 03:16

Теги

Похожие вопросы