Форум "DataBase и SQL"

Язык запросов баз даных

#0 Vlad © 14.05.07 16:58:15 - 21.05.07 18:13:18

Помогите оптимизировать

SELECT distinct
 AS_WEEK
FROM
 AIRSEASON
WHERE
AS_CHKey in
    (
    SELECT
      TS_CODE
    FROM
     TP_SERVICES
    WHERE
     TS_Key IN (
                SELECT
                  TL_TSKEY
                FROM
                  TP_SERVICELISTS
                WHERE
                  TL_TIKEY in (SELECT
                                 TP_TIKEY
                               FROM
                                 TP_PRICES
                               WHERE
                                 TP_KEY = 7359238)
               )
    and TS_SVKEY=1
    )
AND :p1 >= AS_DateFrom
AND :p2 <= AS_DateTo
AND AS_Week LIKE :p3

#1 Deep © 14.05.07 18:38:52

ну.... мне кажется, что в этом случае - разве что созданием индексов по полям участвующим в подзапросах (если их еще нет)...

#2 Mystic © 15.05.07 02:10:41

А если так?

SELECT DISTINCT
 AS_WEEK
FROM
 AIRSEASON, TP_SERVICES S, TP_SERVICELISTS SL, TP_TIKEY T
WHERE 1=1
  AND AS_CHKey = S.TS_CODE
  AND S.TS_Key = SL.TL_TSKEY
  AND SL.TL_TIKEY = T.TP_TIKEY
  AND T.TP_KEY = 7359238
  AND S.TS_SVKEY = 1
  AND :p1 >= AS_DateFrom
  AND :p2 <= AS_DateTo
  AND AS_Week LIKE :p3

#3 Deep © 15.05.07 17:15:22

>#2 Mystic ©
гм... а разве через подзапросы не будет быстрее? если через них - так ведь вроде как "шаг за шагом" отрезаются ненужные части данных, а в случае с

FROM
 AIRSEASON, TP_SERVICES S, TP_SERVICELISTS SL, TP_TIKEY T

по идее сначала идет полное объеденение, а потом уже фильтрация...

Хотя без плана запросов тут наверное можно только гадать, как сервер сам будет оптимизировать их выполнение. Ну, или делать контрольные замеры на больших массивах. Которые кстати тоже на дадут нормальной гарантии оптиимизации. Тот же MS SQL настолько умен, что отслеживает статистику запросов и если видит, что время запроса значительно возросло (например, из-за того что значительно увеличилось количество в одной из таблиц) --- так он "умница" (практически на лету!) сам меняет план запросов. Попробуй такому навязать свою оптимизацию. Он лучше тебя знает.

#4 Mystic © 15.05.07 22:28:02

Нет, через подзапросы всегда не быстрее. Обычно подзапрос преобразуется к нормальной форме без подзапроса, а затем выполняется. Если этого не делать, то SQL сервер имеет мало возможностей для оптимизации выполнения запроса, т. е. он выполняет действия "шаг за шагом", в то время как в общем случае он работает с большими массивами данных, в состоянии сам решать, какие ограничения наиболее отсекают результат и т. п.

#5 Kortez © 15.05.07 23:03:57

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

отправлено с мобилки

#6 Mystic © 16.05.07 11:48:08

>#3 Deep © 15.05.07 19:15:22

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

>#5 Kortez © 16.05.07 01:03:57

Не совсем согласен насчет JOIN. Тем более в Oracle до 9-й версии такого ключелого слова вообще нет, да и в MS SQL я предпочитаю вместо LEFT JOIN использовать *=. Так что тут, имхо, многое зависит от реализации сервера БД.

#7 Kortez © 16.05.07 12:22:56

> Так что тут, имхо, многое зависит от реализации сервера
> БД.

это - ДА!
но, поскольку Влад не стал указывать СУБД, я тоже не уточнял, что говорю об интербейсоподобных

в любом случае использование такого "сложносочиненного" запроса на "толстой" базе в любой СУБД ни к чему хорошему не приведет

#8 Mystic © 16.05.07 12:39:12

Ну... если говорить об Oracle, то он вначале приведет исходный запрос к тому виду, что написал я, и только тогда начнет его выполнять.

#9 Vlad © 21.05.07 12:50:29

спасибо.
Что-то я и забыл что сюда писал :)
Попробовал вариант Андрея - скорость не особо изменилась. Вернее, я не заметил

PS
у меня MSSQL

#10 Mystic © 21.05.07 12:59:10

А размер таблиц какой?

#11 Deep © 21.05.07 13:55:29

> Vlad ©
это точно -- заметить результаты оптимизации можно только при достаточно больших объемах таблиц.

вернее при достаточно большом количестве операций над их данными (а их ведь можно "условно" подсчитать, зная размеры таблиц).


                SELECT
                  TL_TSKEY
                FROM
                  TP_SERVICELISTS
                WHERE
                  TL_TIKEY in (SELECT
                                 TP_TIKEY
                               FROM
                                 TP_PRICES
                               WHERE
                                 TP_KEY = 7359238)

#15 Vlad © 21.05.07 16:47:08

AS_DateFrom и AS_DataTo из AIRSEASON
> SELECT
> TL_TSKEY
> FROM
> TP_SERVICELISTS
> WHERE
> TL_TIKEY in (SELECT
> TP_TIKEY
> FROM
> TP_PRICES
> WHERE
> TP_KEY = 7359238)

выполняется где-то 0.5 секунды

#18 Vlad © 21.05.07 17:06:09

весь запрос чуть дольше, практически не заметно.
Просто он повторяется часто. Для каждого
TP_KEY = , коих много.
вот и получается что долго в сумме.

Спасибо еще раз, но по моему, тут ничем не поможешь.
все равно для каждого придется вычислять. Обидно, что значений на выходе всего 7 в комбинациях по 2

#19 Deep © 21.05.07 18:13:18

если результат запроса и есть результирующие переменные, то может стоит сделать выборку для всех нужных ID, а потом уже в локальном датасете работать с нужными значениями?

Написать ответ