| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Проблема со скоростью запроса [D7, MSSQL]
Barmutik © (2004-11-19 10:10:00)Появилась следющего рода проблема в 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 оперативки
Подскажите в чём грабли ...
Barmutik (2004-11-19 15:28:00) [1]Нет .. значения сбсолютно не упорядочены .. разрывы могут быть большими... 1,2 и т.д... чисто для примера...
Список ИД может быть абсолютно любым...
sniknik (2004-11-19 14:20:00) [2]> ID = 1 OR ID = 2 OR ID = ... и т.д.
самое интересное как всегда в точках ... ;о))
если прогрессия по первым двум значениям аналогична следующим то почему самому не пересоставить запрос? даже десяток(на случай разрывов в значениях) BETWEEN будет быстрее чем in или даже временная таблица.
Barmutik (2004-11-19 14:07:00) [3]План выполнения запроса смотрел:
Состоит из двух состовляющих:
Селект (0%) <- Выбор по индексу (100%).
Посмотрел что приходит непосредственно на выполнение после оптимизатора: ID = 1 OR ID = 2 OR ID = ... и т.д.
Я просто думал что такая операция по индексу должна быть мгновенной.. но тут поступила информация что при такой конструкции он делает столько пробегов по индексу сколько у меня значений в IN а не один сквозной проход по индексу.
Тут наверно и тормозит... да буду постораться пробовать с временной таблицей... главное что бы затраты на создание таблицы + вставка в неё ключей + потом объединение оказались меньшими по времени.
Anatoly Podgoretsky (2004-11-19 14:00:00) [4]Может пофиг, а может нет, но планы наверняка разные будут.
LEFT INNER JOIN где слева список, на мой взгляд самое то, не проводя анализа плана или измерения времени.
Fay (2004-11-19 13:56:00) [5]2 Anatoly Podgoretsky © (19.11.04 13:35) [19]
> только правильно выбери что справа, что слева поставить.
А в INNER JOIN не пофинг?
Sergey13 (2004-11-19 13:53:00) [6]2[14] Barmutik (19.11.04 12:29)
>Утилита сторонняя.. я обладаю информацией только о мехнизме её вызова и получения результатов. Никакой больше информации...
Я не имел в виду ничего такого противозаконного. 8-) Просто мониторчиком каким нить посмотреть какие запросы выполняются при работе утили, и если не шибко наворочено - повторить у себя.
Anatoly Podgoretsky (2004-11-19 13:35:00) [7]при IN индексы не используются, происходит перебор всех записей с проверкой на вхождение в список.
Ты план выполнения смотрел?.
Прислушайся к советам по объединению, реальный путь повышения скорости, только правильно выбери что справа, что слева поставить.
Barmutik (2004-11-19 13:30:00) [8]Да выделенный сервер... нет ..это уже проверялось...
sniknik (2004-11-19 13:19:00) [9]> иногда
?
комп действительно сервер? не выставил ли кто случаем sleep для дисков при простое?
Barmutik (2004-11-19 12:58:00) [10]Нет .. очень даже хорошо если всё будет работать как надо.
Вот ещё что меня смущает. На нашем сервере (дохлый комп) стоит SQL Server Developer Edition и время реакции никогда не бывает больше 3 секунд.
У заказчика на мощном 2-х процессором компе с 2 Гб оперативки и Enterprise Edition пауза иногда бывает и 20 секунд...
Как это можно объяснить ?
sniknik (2004-11-19 12:49:00) [11]решение уже сказали, посчитаем
получение параметров из внещней утилиты - 0.1 секунды
временная таблица, создание, заполнение - меньше сек. (предположительно)
запрос с обьеденением, получением значений из таблицы - для 500 записей меньше сек (предположительно)
итого 2.1 сек. (а скорее меньше) против 8-10 секунд, разве плохо?
Barmutik (2004-11-19 12:29:00) [12]Утилита сторонняя.. я обладаю информацией только о мехнизме её вызова и получения результатов. Никакой больше информации...
Sergey13 (2004-11-19 12:07:00) [13]А "подсмотреть" что делает утилита нельзя? Ну и бросить ее потом. 8-)
Barmutik (2004-11-19 12:03:00) [14]Внешняя утилита работает быстро и время реакции на любые комбинации внешних параметров в запросе не превышает 0.1 секунды.
Barmutik (2004-11-19 11:51:00) [15]Так .. подробнее:
Пользователь осуществляет ввод спец параметров, которые затем передаются на оценку ВНЕШНЕЙ программе, которая по своим бизнес правилам оценивает их и возвращает список ИД записей которые требуется показать пользователю. По этом усписку потому и делается запрос через IN (список ИД).
Реально ткой запрос может быть и каждые 5 секунд. Пользователь что-то поменял в параметрах и произвёл новое обращение за результатами...
sniknik (2004-11-19 11:51:00) [16]еще интересно
время за которое утилита возвращает "не большое" количество и 500 значений.
повторный запрос он происходит тоже с вызовом этой утилиты? или просто перезапрос уже готового sql запроса?
ЮЮ (2004-11-19 11:40:00) [17]Утилита это что? отдает список - это как? Почему эта утилита отдает список каждые 5 секунд, когда пользователь успевает сформулировать новые требования к утилите?
Barmutik (2004-11-19 11:37:00) [18]Формируются следующим образом:
Внешняя НЕ МОЯ утилита по запросу к ней отдаёт список ID которые я должен показать польщователю. Список строится той утилитой и я никак не моуг повлиять на его построение. После получения данного списка мне надо отобразить пользователю записи которые входят в тот список ID которые вернула мне утилита.
Мне не важно приятность.. важна только скорость!!! Подойдёт любой способ.
Система многопользовательская .. т.е одновременнго может быть несколько запросов ...
sniknik (2004-11-19 11:30:00) [19]можно еще подобный запрос на обьеденении таблиц построить, не так быстро как с временной но быстрее чем с in (если индексы есть) будет.
(хотя это надо еще проверить что быстрее ;о))
ЮЮ (2004-11-19 11:08:00) [20]ты так и не ответил, "как формируются эти 2000-3000 значений", да еще кадые 5 секунд. Не в гриде же с мультиселектом :)
| |
Страницы: 