Проблема со скоростью запроса

← →
Barmutik (2004-11-19 10:10) [0]

Появилась следющего рода проблема в MS SQL Server 2000:

Есть таблица с некоторым набором полей. В таблице есть IDxx (типа int)- Primary key. Встала необходимость делать запросы следующего вида:
SELECT IDxx, MyField FROM MyTAble WHERE IDxx IN (.....)

Проблема заключается во времени реации сервера на запрос.

Если количество значений в IN не большое то запрос работает мгновенно... Но если она ставновится больше 500 ... то время реакции увеличивается до 8-10 секунд.... что не приемлимо...

Проблема абсолютно непонятна учитывая что в данной таблице порядка 4000 (4 тысячи всего) записей...

По данному полю построен индекс.... во время использования данной таблице в других запросах проблем со скоростью не возникает.

Повторный запрос происходит мгновенно .. что в принципе и понятно он находится в кэше сервера.

Серверный компьютер: 2-х процессорный на Intel Pentium 4 2.8 Gh c 2 Gb оперативки

Подскажите в чём грабли ...

← →
Sergey13 © (2004-11-19 10:14) [1]

IN он такой. А как формируются эти 500 значений? Может их в какую нить табличку писать и подсовывать потом.

← →
Johnmen © (2004-11-19 10:19) [2]

Да. Индекс не поможет, т.к. идёт тупой перебор набора в IN.
Стандартное решение при большом наборе в IN - писать их во временную табл. и соединять её с основной.
О чём уже сказал Sergey13 ©.

← →
Barmutik (2004-11-19 10:44) [3]

Спасибо .. просто мне достаточно часто нужен этот запрос...

И в этом IN может быть 2000-3000 элементов... просто если мне такой запрос надо делать раз в 5 секунд... то как-то перед этим запихивать их в базу... вариант не самый приятный.. а если несколько таких запросов одновременно...

← →
Johnmen © (2004-11-19 10:47) [4]

> вариант не самый приятный..

А что надо, приятность или скорость ?
:)

← →
Sergey13 © (2004-11-19 10:48) [5]

2[3] Barmutik (19.11.04 10:44)
Значит ты возможно не доработал структуру БД.

← →
ЮЮ © (2004-11-19 11:08) [6]

ты так и не ответил, "как формируются эти 2000-3000 значений", да еще кадые 5 секунд. Не в гриде же с мультиселектом :)

← →
sniknik © (2004-11-19 11:30) [7]

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

← →
Barmutik (2004-11-19 11:37) [8]

Формируются следующим образом:

Внешняя НЕ МОЯ утилита по запросу к ней отдаёт список ID которые я должен показать польщователю. Список строится той утилитой и я никак не моуг повлиять на его построение. После получения данного списка мне надо отобразить пользователю записи которые входят в тот список ID которые вернула мне утилита.

Мне не важно приятность.. важна только скорость!!! Подойдёт любой способ.

Система многопользовательская .. т.е одновременнго может быть несколько запросов ...

← →
ЮЮ © (2004-11-19 11:40) [9]

Утилита это что? отдает список - это как? Почему эта утилита отдает список каждые 5 секунд, когда пользователь успевает сформулировать новые требования к утилите?

← →
sniknik © (2004-11-19 11:51) [10]

еще интересно
время за которое утилита возвращает "не большое" количество и 500 значений.

повторный запрос он происходит тоже с вызовом этой утилиты? или просто перезапрос уже готового sql запроса?

← →
Barmutik (2004-11-19 11:51) [11]

Так .. подробнее:

Пользователь осуществляет ввод спец параметров, которые затем передаются на оценку ВНЕШНЕЙ программе, которая по своим бизнес правилам оценивает их и возвращает список ИД записей которые требуется показать пользователю. По этом усписку потому и делается запрос через IN (список ИД).

Реально ткой запрос может быть и каждые 5 секунд. Пользователь что-то поменял в параметрах и произвёл новое обращение за результатами...

← →
Barmutik (2004-11-19 12:03) [12]

Внешняя утилита работает быстро и время реакции на любые комбинации внешних параметров в запросе не превышает 0.1 секунды.

← →
Sergey13 © (2004-11-19 12:07) [13]

А "подсмотреть" что делает утилита нельзя? Ну и бросить ее потом. 8-)

← →
Barmutik (2004-11-19 12:29) [14]

Утилита сторонняя.. я обладаю информацией только о мехнизме её вызова и получения результатов. Никакой больше информации...

← →
sniknik © (2004-11-19 12:49) [15]

решение уже сказали, посчитаем

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

итого 2.1 сек. (а скорее меньше) против 8-10 секунд, разве плохо?

← →
Barmutik (2004-11-19 12:58) [16]

Нет .. очень даже хорошо если всё будет работать как надо.

Вот ещё что меня смущает. На нашем сервере (дохлый комп) стоит SQL Server Developer Edition и время реакции никогда не бывает больше 3 секунд.

У заказчика на мощном 2-х процессором компе с 2 Гб оперативки и Enterprise Edition пауза иногда бывает и 20 секунд...

Как это можно объяснить ?

← →
sniknik © (2004-11-19 13:19) [17]

> иногда
?

комп действительно сервер? не выставил ли кто случаем sleep для дисков при простое?

← →
Barmutik (2004-11-19 13:30) [18]

Да выделенный сервер... нет ..это уже проверялось...

при IN индексы не используются, происходит перебор всех записей с проверкой на вхождение в список.
Ты план выполнения смотрел?.

Прислушайся к советам по объединению, реальный путь повышения скорости, только правильно выбери что справа, что слева поставить.

2[14] Barmutik (19.11.04 12:29)
>Утилита сторонняя.. я обладаю информацией только о мехнизме её вызова и получения результатов. Никакой больше информации...
Я не имел в виду ничего такого противозаконного. 8-) Просто мониторчиком каким нить посмотреть какие запросы выполняются при работе утили, и если не шибко наворочено - повторить у себя.

2 Anatoly Podgoretsky © (19.11.04 13:35) [19]

> только правильно выбери что справа, что слева поставить.

А в INNER JOIN не пофинг?

Может пофиг, а может нет, но планы наверняка разные будут.
LEFT INNER JOIN где слева список, на мой взгляд самое то, не проводя анализа плана или измерения времени.

← →
Barmutik (2004-11-19 14:07) [23]

План выполнения запроса смотрел:

Состоит из двух состовляющих:
Селект (0%) <- Выбор по индексу (100%).

Посмотрел что приходит непосредственно на выполнение после оптимизатора: ID = 1 OR ID = 2 OR ID = ... и т.д.

Я просто думал что такая операция по индексу должна быть мгновенной.. но тут поступила информация что при такой конструкции он делает столько пробегов по индексу сколько у меня значений в IN а не один сквозной проход по индексу.

Тут наверно и тормозит... да буду постораться пробовать с временной таблицей... главное что бы затраты на создание таблицы + вставка в неё ключей + потом объединение оказались меньшими по времени.

> ID = 1 OR ID = 2 OR ID = ... и т.д.
самое интересное как всегда в точках ... ;о))

если прогрессия по первым двум значениям аналогична следующим то почему самому не пересоставить запрос? даже десяток(на случай разрывов в значениях) BETWEEN будет быстрее чем in или даже временная таблица.

← →
Barmutik (2004-11-19 15:28) [25]

Нет .. значения сбсолютно не упорядочены .. разрывы могут быть большими... 1,2 и т.д... чисто для примера...

Список ИД может быть абсолютно любым...

Проблема со скоростью запроса Найти похожие ветки