Медленно работает LIKE

← →
galexis (2006-06-22 15:03) [40]

все остальные запросы уходят за 2 минуты и я их отменяю

← →
Johnmen © (2006-06-22 15:07) [41]

А такие сколько
"%лектрическая компания%"
"%ектрическая компания%"
"%ктрическая компания%"

"%компания%"
?

← →
galexis (2006-06-22 15:08) [42]

> Johnmen © (22.06.06 15:07) [41]
> А такие сколько
> "%лектрическая компания%"
> "%ектрическая компания%"
> "%ктрическая компания%"
>
> "%компания%"
> ?

Запросы длятмся больше 2 минут и я отменяю

← →
Johnmen © (2006-06-22 15:10) [43]

А много ли записей, в поле которых встречаются слова "электрическая" и "компания"?

← →
Danilka © (2006-06-22 15:11) [44]

[31] Johnmen © (22.06.06 14:01)
> Есть кое-какие соображения.

Ты не томи, говори соображения, а то аж интересно стало, что за странности :)

← →
galexis (2006-06-22 15:16) [45]

> Johnmen © (22.06.06 15:10) [43]

Ну этого сказать я не могу. Но на запрос по "Электрическая компания" находилось (и находится в старой базе) две записи:
Нижегородская электрическая компания и электрическая компания

отдельно по электрическим и компаниям много, точно не знаю скрлько но порядка тысячи

← →
Johnmen © (2006-06-22 15:19) [46]

> Danilka © (22.06.06 15:11) [44]

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

← →
Johnmen © (2006-06-22 15:21) [47]

Да, и ещё они зависят от языка в части встречаемости тех или иных букв...

← →
galexis (2006-06-22 15:25) [48]

Упростил запрос дальше не куда (почти)
select NAMEP from Tbl Where ( UPPER(NAMEP) LIKE "%" || "НИЖЕГОРОДСКАЯ ЭЛЕКТРИЧЕСКАЯ КОМПАНИЯ" || "%")

39 секунд :(
Чего делать то? Все это произошло по моему после очередной закачки данных. Таблица что ли по количеству записей какой порог перешагнула? Или файл базы по размеру?

← →
galexis (2006-06-22 15:29) [49]

Из старой базы (апрель месяц)
поиск по "компания" - 2 445 записей, время поиска 63 мс
"электрическая" - 3 записи, время поиска 1 с. 733мс

← →
Sergey13 © (2006-06-22 15:33) [50]

Попробуй спросить на
http://www.sql.ru/forum/actualtopics.aspx?bid=2
Там птицеводы вроде часто встречаются.

← →
Johnmen © (2006-06-22 15:37) [51]

Общая корреляция такая
- чем реже "попадания", тем дольше поиск
- чем короче подстрока, тем дольше поиск

← →
roottim © (2006-06-22 15:40) [52]

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

Отсюда вопрос: если запрос составить с параметром like :p_org и препарировать его заранее, подставляя ваши значения, результат тотже?

← →
Desdechado © (2006-06-22 15:41) [53]

> но появляется еще индексный с временем 349 784 353. Чего за хрень то?
Вот это уже интересно.
Если база не секретная, поделись. Хочу у себя погонять.
Если секретная, то выгрузи в скрипт структуру таблицы и данные в ней.
И линк сюда дай.

← →
galexis (2006-06-22 15:42) [54]

Будете смеяться, но я знаю что теперь значит цифра 80 045 в IBExpert в Perfomance Analysis. select count from tbl = 80 045
А я то думаю, почему при любом поиске эта цифра от времени не зависит :)

← →
galexis (2006-06-22 15:44) [55]

roottim © (22.06.06 15:40) [52]
в данный момент запрос вообще пишу вручную в IBExpert

> Desdechado © (22.06.06 15:41) [53]

Не секретная, но ДСП. Меня посодют. И структура тоже. Госслужащий я :(((

← →
Desdechado © (2006-06-22 15:45) [56]

roottim © (22.06.06 15:40) [52]
Если индекса нет, то, боюсь, разницы не будет.

← →
Sergey13 © (2006-06-22 15:46) [57]

2 galexis
А у тебя там вьюхи не учавствуют? Вообще - план запости.

← →
galexis (2006-06-22 15:50) [58]

> Sergey13 © (22.06.06 15:46) [57]

нет, нету. А чего на план то смотреть, запрос то простецкий
Plan
PLAN (UL_NAME NATURAL)

Adapted Plan
PLAN (UL_NAME NATURAL)

------ Performance info ------
Prepare time = 94ms
Execute time = 42s 813ms
Avg fetch time = 42 813,00 ms
Current memory = 1 497 248
Max memory = 2 228 452
Memory buffers = 2 048
Reads from disk to cache = 17 204
Writes from cache to disk = 6
Fetches from cache = 37 429 227

← →
roottim © (2006-06-22 15:52) [59]

> боюсь, разницы не будет.

Мое ощущение, что не в индексе этой таблице дело, а в индексах соединени ее с остальными 50-ю таблицами. И ежели запрос собирается образом
"like %" + tbox.text + "%" план запроса выводится каждый раз и при определенной длинне видими оптимизатор неврубается и подсовывает не оптимальный способ.

Ну а если он все же делает так(о чем я спросил, но так и неполучил ответ)
like :p_org q1.Prepare; q1.Param... := "%" + tbox.text + "%"; .. q1.Open;

то план запроса по идее должен быть стабильным.

← →
galexis (2006-06-22 15:56) [60]

> roottim © (22.06.06 15:52) [59]

Сейчас то я запрос из одной таблицы делаю, это копать я начинал с общего запроса. Дошел вот до того, что разницы нет, из 50 таблиц или из одной :(

Старая база (апрельская) работает без проблем и шустро. Разница в них только в количестве данных. В апрельской в данной таблице 75 тыс. в июньской 80 045 тыс.

← →
roottim © (2006-06-22 16:02) [61]

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

Ты ведь говорил [30] что при тормозном запросе план меняется, появляется какой-то индексный поиск ? Копай в эту сторону дальше!

← →
Sergey13 © (2006-06-22 16:03) [62]

> [60] galexis (22.06.06 15:56)

А размеры страниц не поменялись? Шаманство конечно, но может тут что?

← →
galexis (2006-06-22 16:06) [63]

> roottim © (22.06.06 16:02) [61]

Сейчас я запросы гоняю не в делфи, а в IBExpert

Запрос сейчас такой
select NAMEP from UL_NAME Where ( UPPER(NAMEP) LIKE "%" || "НИЖЕГОРОДСКАЯ ЭЛЕКТРИЧЕСКАЯ КОМПАНИЯ" || "%")

Plan
PLAN (UL_NAME NATURAL)

Adapted Plan
PLAN (UL_NAME NATURAL)

------ Performance info ------
Prepare time = 94ms
Execute time = 42s 813ms
Avg fetch time = 42 813,00 ms
Current memory = 1 497 248
Max memory = 2 228 452
Memory buffers = 2 048
Reads from disk to cache = 17 204
Writes from cache to disk = 6
Fetches from cache = 37 429 227

← →
Sergey13 © (2006-06-22 16:08) [64]

[63] galexis (22.06.06 16:06)
> Запрос сейчас такой
select NAMEP from UL_NAME Where ( UPPER(NAMEP) LIKE "%" || "НИЖЕГОРОДСКАЯ ЭЛЕКТРИЧЕСКАЯ КОМПАНИЯ" || "%")

А почему не просто
select NAMEP from UL_NAME Where ( UPPER(NAMEP) LIKE "%НИЖЕГОРОДСКАЯ ЭЛЕКТРИЧЕСКАЯ КОМПАНИЯ%")
? Нафига конкатенация то?

← →
galexis (2006-06-22 16:11) [65]

> Sergey13 © (22.06.06 16:08) [64]

Ну как из делфи взял так и оставил :)

← →
sniknik © (2006-06-22 16:33) [66]

> Не секретная, но ДСП. Меня посодют. И структура тоже. Госслужащий я :(((
а ты только часть, которая ничего не будет значить... интересует же только одна вот эта большая проблемная таблица, остальные можно и даже нужно удалить (чего зря трафик гонять), и все данные в этой таблице кроме интересующего поля обнулить...
и вот эту итоговую (если глюк все еше останется на чистой без внешних связей таблице) и дать на тест.

← →
galexis (2006-06-22 16:41) [67]

Так! Чем дальше тем хуже. Глюкнул IBExpert, пришлось закрыть насильно его, т.е. в диспетчере задач удалить процесс. Затем снова его загрузил. База пять минут просто летала. Все запросы выполнялись за доли секунд. А потом снова тоже самое. Что это?

← →
Sergey13 © (2006-06-22 16:45) [68]

> [67] galexis (22.06.06 16:41)
> Глюкнул IBExpert, пришлось закрыть
> насильно его, т.е. в диспетчере задач удалить процесс. Затем
> снова его загрузил.

Эксперт или сервер?

← →
galexis (2006-06-22 16:48) [69]

Эксперт. Сервер на сервере. Даже на двух. И на том и на другом база себя одинаково ведет. Уж и антивирусник вырубил.

> galexis (22.06.06 16:41) [67]

Как вариант - скачай ibanalyst http://www.ibase.ru/download/ibanalyst_r.zip
И посмотри анализ бд. Скорее всего ненужные индексы есть
и время от времени оптимизатор пропускает их в план.

И анализ бд сюда по возможности выложи.

← →
galexis (2006-06-22 17:29) [72]

Проанализировал. Врекомендация было восстановить базу из бэкапа с большим размером страницы. Восстановил с 2096. Вроде бы работает. Вот только и народ компы повыключал. Думаю может это сеть у нас перегружена?

> Восстановил с 2096.

А почему такой размер? Обычно рекомендуют 4096 или 8192

← →
Виталий Панасенко (2006-06-22 18:00) [74]

У ЖарПтицы есть и 16384

http://www.codenet.ru/db/interbase/Interbase-Not-Do.php
совет 6 (2кб мало)

← →
galexis (2006-06-23 09:51) [76]

← →
galexis (2006-06-23 09:53) [77]

Вообщем опять ничего не работает. Сейчас поставлю на локальный комп и потестирую.

← →
galexis (2006-06-23 10:18) [78]

Локально тоже не работает :(. Все же в базе проблема.
На что влияет размер страницы?

В firebird.log случайно ничего подозрительного не написано?

← →
galexis (2006-06-23 10:26) [80]

> unknown © (23.06.06 10:23) [79]

ALEXIS_GR (Client) Fri Jun 16 14:31:00 2006
Guardian starting: C:\Program Files\Firebird\Firebird_1_5\bin\fbserver.exe

Медленно работает LIKE Найти похожие ветки