| denis_viktorovich |
3. Теперь уж совсем медленно стало. Я раскопал этот запрос и похоже понял, почему он так тормозит. Нет индекса по полю учавствующему в where in().
Даже смешно - если из приложения запрашиваются все данные то открывается несколько минут (5-7). Если фильтруется по цеху и возвращает раза в три меньше данных - то запрос работает ТРИ-ЧЕТЫРЕ часа и при этом грузит сервер на 100%. Причем грузит хоть тестовый хоть рабочий именно под 100%.
|
Вообще-то такая ситуация наводит на прямо противоположные мысли - использование индекса в условии с in (...). Для каждого значения в списке поднимается свой экземпляр индекса и, начиная с некоторой длины списка, натурал начинает становиться предпочтительным. С какой именно - зависит от очень и очень многих факторов. Хотя возможно и другое - при наложении условия меняется план запроса в принципе, то есть последовательность перебора страниц. В дистрибуте IB меньше 6.0 есть такая утилитка - WISQL, которая умеет показывать планы выполняемых ею запросов. Имхо IBExpert просто обязан уметь коннектиться к 5.х. и он в этом плане предпочтителен - умеет показывать план как запрос выполняться будет, без фетча результатов. На плохом запросе тоже не быстро, но всё не столько, сколько с фетчем. Возвращаемая информация показывает не только какие индексы использованы, но и в каком порядке, что зачастую бывает даже важнее.
| denis_viktorovich |
Я почему спрашиваю именно "что почитать доходчиво в электронном виде". У нас стандартно используется MS SQL или Oracle. IB Никто не знает (в т.ч. и я). |
http://www.ibase.ru/develop.htm - статьи раздела "Оптимизация запросов".