![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Медленно работает LIKE [D7, FireBird 1.5]
galexis © (2006-06-22 10:28:00)Используется запрос типа select * from Table Where (Fld1 LIKE '%' || 'Text' || '%')
Данные Fld1 (тип VarChar длина 1000) состоят из нескольких слов (наименовние предприятий).
Так вот. Ищу, например, "Горьковский автомобильный завод" по одному слову "автомобильный". Запрос выполняется меньше секунды. Пытаюсь провести поиск по неполному слову, например, "горьковск" - и тут все, поиск идет минут 20.
Чего бы это?
Sergey13 (2006-06-22 16:45:00) [21]> [67] galexis (22.06.06 16:41)
> Глюкнул IBExpert, пришлось закрыть
> насильно его, т.е. в диспетчере задач удалить процесс. Затем
> снова его загрузил.
Эксперт или сервер?
galexis (2006-06-22 16:41:00) [22]Так! Чем дальше тем хуже. Глюкнул IBExpert, пришлось закрыть насильно его, т.е. в диспетчере задач удалить процесс. Затем снова его загрузил. База пять минут просто летала. Все запросы выполнялись за доли секунд. А потом снова тоже самое. Что это?
sniknik (2006-06-22 16:33:00) [23]> Не секретная, но ДСП. Меня посодют. И структура тоже. Госслужащий я :(((
а ты только часть, которая ничего не будет значить... интересует же только одна вот эта большая проблемная таблица, остальные можно и даже нужно удалить (чего зря трафик гонять), и все данные в этой таблице кроме интересующего поля обнулить...
и вот эту итоговую (если глюк все еше останется на чистой без внешних связей таблице) и дать на тест.
galexis (2006-06-22 16:11:00) [24]
> Sergey13 © (22.06.06 16:08) [64]
Ну как из делфи взял так и оставил :)
Sergey13 (2006-06-22 16:08:00) [25][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:06:00) [26]
> 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:03:00) [27]> [60] galexis (22.06.06 15:56)
А размеры страниц не поменялись? Шаманство конечно, но может тут что?
roottim (2006-06-22 16:02:00) [28]Ну дык и приведи результаты простецкого запроса при подаче подготовленного параметрического запроса для тех случаев, которые были приведены в списке(для быстрого и медленного вариантов).
Ты ведь говорил [30] что при тормозном запросе план меняется, появляется какой-то индексный поиск ? Копай в эту сторону дальше!
galexis (2006-06-22 15:56:00) [29]
> roottim © (22.06.06 15:52) [59]
Сейчас то я запрос из одной таблицы делаю, это копать я начинал с общего запроса. Дошел вот до того, что разницы нет, из 50 таблиц или из одной :(
Старая база (апрельская) работает без проблем и шустро. Разница в них только в количестве данных. В апрельской в данной таблице 75 тыс. в июньской 80 045 тыс.
roottim (2006-06-22 15:52:00) [30]
> боюсь, разницы не будет.
Мое ощущение, что не в индексе этой таблице дело, а в индексах соединени ее с остальными 50-ю таблицами. И ежели запрос собирается образом
'like %' + tbox.text + '%'план запроса выводится каждый раз и при определенной длинне видими оптимизатор неврубается и подсовывает не оптимальный способ.
Ну а если он все же делает так(о чем я спросил, но так и неполучил ответ)
like :p_org
q1.Prepare;
q1.Param... := '%' + tbox.text + '%';
..
q1.Open;
то план запроса по идее должен быть стабильным.
galexis (2006-06-22 15:50:00) [31]
> 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
Sergey13 (2006-06-22 15:46:00) [32]2 galexis
А у тебя там вьюхи не учавствуют? Вообще - план запости.
Desdechado (2006-06-22 15:45:00) [33]roottim © (22.06.06 15:40) [52]
Если индекса нет, то, боюсь, разницы не будет.
galexis (2006-06-22 15:44:00) [34]roottim © (22.06.06 15:40) [52]
в данный момент запрос вообще пишу вручную в IBExpert
> Desdechado © (22.06.06 15:41) [53]
Не секретная, но ДСП. Меня посодют. И структура тоже. Госслужащий я :(((
galexis (2006-06-22 15:42:00) [35]Будете смеяться, но я знаю что теперь значит цифра 80 045 в IBExpert в Perfomance Analysis. select count from tbl = 80 045
А я то думаю, почему при любом поиске эта цифра от времени не зависит :)
Desdechado (2006-06-22 15:41:00) [36]> но появляется еще индексный с временем 349 784 353. Чего за хрень то?
Вот это уже интересно.
Если база не секретная, поделись. Хочу у себя погонять.
Если секретная, то выгрузи в скрипт структуру таблицы и данные в ней.
И линк сюда дай.
roottim (2006-06-22 15:40:00) [37]Дело, имхо, в плане запроса. Если запрос вы составляйте динамически, то такой результат плана более чем возможен, если нет - то фиг знает.
Отсюда вопрос: если запрос составить с параметромlike :p_orgи препарировать его заранее, подставляя ваши значения, результат тотже?
Johnmen (2006-06-22 15:37:00) [38]Общая корреляция такая
- чем реже "попадания", тем дольше поиск
- чем короче подстрока, тем дольше поиск
Sergey13 (2006-06-22 15:33:00) [39]Попробуй спросить на
http://www.sql.ru/forum/actualtopics.aspx?bid=2
Там птицеводы вроде часто встречаются.
galexis (2006-06-22 15:29:00) [40]Из старой базы (апрель месяц)
поиск по "компания" - 2 445 записей, время поиска 63 мс
"электрическая" - 3 записи, время поиска 1 с. 733мс