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

← →
galexis (2006-06-22 10:28) [0]

Используется запрос типа select * from Table Where (Fld1 LIKE "%" || "Text" || "%")

Данные Fld1 (тип VarChar длина 1000) состоят из нескольких слов (наименовние предприятий).
Так вот. Ищу, например, "Горьковский автомобильный завод" по одному слову "автомобильный". Запрос выполняется меньше секунды. Пытаюсь провести поиск по неполному слову, например, "горьковск" - и тут все, поиск идет минут 20.
Чего бы это?

← →
Sergey13 © (2006-06-22 10:35) [1]

>Медленно работает LIKE
Это нормально.

>и тут все, поиск идет минут 20.
Велика ли таблица? Б/Р нормально проходят?

← →
galexis (2006-06-22 10:43) [2]

Таблица по которой LIKE - 80 тыс. записей.
Запрос я конечно упростил до некуда, на самом деле выборка идет из порядка 50 таблиц. Но в данном случае меняется только одно слово поиска.
Б/Р - это что?

← →
sniknik © (2006-06-22 10:46) [3]

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

← →
galexis (2006-06-22 10:53) [4]

> sniknik ©

Я в курсе про справочник. Сначала база была небольшая, теперь руки не доходят, но сделаю обязательно.
Совсем недавно такие запросы выполнялись быстро, около 30 секунд и это устраивало пользователей. Ничего в программе не менял, в базе тоже и вот такая фигня. Чем отличается поиск по целому слову от поиска по части слова? Поле то одно и тоже.

← →
Sergey13 © (2006-06-22 10:54) [5]

2 [2] galexis (22.06.06 10:43)
> Таблица по которой LIKE - 80 тыс. записей.
Не так и много, в принципе.

> Запрос я конечно упростил до некуда, на самом деле выборка
> идет из порядка 50 таблиц.
И без LIKE он не тормозит? 50 таблиц - что-то многовато, ИМХО. Это надо умудриться такой написать. 8-) У меня больше 10-15 редко-редко встречается. Не слишком ли занормализована БД?
Конкретно приведенный запрос тормозит при смене слова поиска?

> Б/Р - это что?
Бекап/рестор.

2 [3] sniknik © (22.06.06 10:46)
>по правильному это строковое название не должно присутствовать в основной таблице в куче записей... надо делать отдельный справочник названий

Не факт. Зависит от задачи. Может это и есть справочник. 8-)

← →
sniknik © (2006-06-22 11:08) [6]

> Не факт. Зависит от задачи. Может это и есть справочник. 8-)
ага, и где это у нас 80 тыс различных автомобильных заводов? или вообще заводов?
думал про это, но не похоже. (у нас справочники товаров меньше бывают... а тут заводы которые их производят...)

по вопросу
а "Горьковский" также быстро ищется, или только "автомобильный"? и потом проверки делались на том запросе который показан или "оригинале"?

← →
galexis (2006-06-22 11:09) [7]

> Sergey13 ©

Да, один и тот же запрос, меняется только фраза поиска. Чем она длинее, тем быстрее поиск, чем короче, тем медленнее. В принципе так и должно, но разница у слишком большая. Структура базы навязана свыше :)

Бэкап делаю раз в месяц, после обновления базы. Ресторе не делал, попробовать?

← →
galexis (2006-06-22 11:13) [8]

> sniknik ©

> а "Горьковский" также быстро ищется, или только "автомобильный"?
> и потом проверки делались на том запросе который показан
> или "оригинале"?

Любое предприятие по целому слову ищется быстро, по двум и более тоже, а вот по неполному резко время поиска увеличивается. Если поиск отменить (поиск в фоне идет), то требуемое предприятие тоже находится.

← →
Sergey13 © (2006-06-22 11:16) [9]

2[7] galexis (22.06.06 11:09)
>Ресторе не делал, попробовать?
Обязательно!!! Это надо делать с каждым бекапом. Только это дает уверенность, что бекап работоспособный. Только восстанавливать надо не в рабочую БД, а в отдельную.

2 [6] sniknik © (22.06.06 11:08)
>ага, и где это у нас 80 тыс различных автомобильных заводов? или вообще заводов?
Там могут быть не только автозаводы и не только заводы вообще.

← →
Desdechado © (2006-06-22 12:00) [10]

Поиски по Like "%..." не используют индексов.

> "Горьковский автомобильный завод" по неполному слову "горьковск"
C текстом запроса, который приведен в [0], ты вообще не найдешь. Значит, делаешь UPPER для поля и искомой строки, а это очень долго.

Поэтому предлагаю как вариант: завести таблицу псевдонимов для каждой строки справочника и искать по ней строгое соответствие, а если нет, тогда уже по основной нестрогое. 1 завод - несколько псевдонимов.
Например, для "Горьковский автомобильный завод" могут быть псевдонимы "ГАЗ", "авто", "автомобиль" ...

← →
Sergey13 © (2006-06-22 12:04) [11]

> [10] Desdechado © (22.06.06 12:00)
> Например, для "Горьковский автомобильный завод" могут быть
> псевдонимы "ГАЗ", "авто", "автомобиль" ...

"Волга" забыл. 8-)

← →
galexis (2006-06-22 12:13) [12]

Сделал бэкап/ресторе. База уменьшилась на 12 Мб.

И вот еще чего странно. Так как поиск в фоне, то для отмены выполнения запроса устанавливаю значение генератора в 0. Выполнение прерывается только спустя пять минут или больше. То что значение скинулось в ноль проверяю IBExpert.

← →
sniknik © (2006-06-22 12:17) [13]

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

а сколько из этих 80 тыс. уникальных названий?

← →
Sergey13 © (2006-06-22 12:20) [14]

2 [12] galexis (22.06.06 12:13)
> Сделал бэкап/ресторе. База уменьшилась на 12 Мб.
Это нормально.

> И вот еще чего странно. Так как поиск в фоне, то для отмены
> выполнения запроса устанавливаю значение генератора в 0.

Это как?

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

> sniknik ©

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

из 80 тыс уникальны 80 тыс. Это база данных предприятий всех форм собственности

← →
alexeis © (2006-06-22 12:23) [16]

а индексы есть по этому полю?

← →
galexis (2006-06-22 12:26) [17]

> Sergey13 ©

А вы как запрос прерываете? Запрос выполняется в фоне. Структура такая select ... where .... and GEN_ID(GEN_TH, 0) = 1

Из основного потока (по нажатию кнопки Отмена) ставлю генератор в 0. Запрос прерывается, так как не выполняется условие

← →
galexis (2006-06-22 12:28) [18]

> alexeis ©

индексы можно сделать на поле длиной по моему не более 40 символов, а у меня 1000

← →
alexeis © (2006-06-22 12:31) [19]

не более 82 при win1251 по моему :-)
ну да все одно не 1000
8-)

← →
sniknik © (2006-06-22 12:31) [20]

> Запрос прерывается, так как не выполняется условие
скорее всего нет, т.к. условие вычисляется только один раз, при старте запроса. (надо проверить)

← →
Sergey13 © (2006-06-22 12:33) [21]

> [17] galexis (22.06.06 12:26)

Никогда такого не видел. 8-)
А если не один человек что-то ищет?
Запрос не прервется, ИМХО. Просто записи перестанут отбираться.

← →
Desdechado © (2006-06-22 12:34) [22]

> select ... where .... and GEN_ID(GEN_TH, 0) = 1
Строго однопользоывательский вариант.

> при загрузке из xml файла разбивать длинные названия по словам, но пока времени нет.
На нет и суда нет. Мучься дальше.

> индексы можно сделать на поле длиной не более 40 символов
Зависит от COLLATION и числа байтов в нем. Подробности на ibase.ru

← →
Desdechado © (2006-06-22 12:35) [23]

> Запрос не прервется, ИМХО. Просто записи перестанут отбираться.
Именно. Перебор продолжится, только в результат уже ничего не попадет.

← →
galexis (2006-06-22 12:50) [24]

> Desdechado © (22.06.06 12:35) [23]

Может и так. Но тогда почему запросы мгновенно возвращают то, что уже успели отобрать? А не висят дальше, как еслибы запрос выполнялся полностью?

← →
galexis (2006-06-22 12:51) [25]

Да и как еще можно по другому прервать выпонение запроса?

← →
Johnmen © (2006-06-22 12:56) [26]

Прервать выполнение запроса можно, как уже ты говорил, с использованием генератора (с приведёнными Sergey13 © и Desdechado © оговорками), использую ХП, в которой цикл FOR SELECT с отслеживанием генератора, и уже обращаться SELECT"ом к этой процедуре.

← →
galexis (2006-06-22 12:59) [27]

> Johnmen ©

А для многопользовательского варианта?

← →
Johnmen © (2006-06-22 13:06) [28]

http://www.sql.ru/forum/actualthread.aspx?tid=244770

← →
galexis (2006-06-22 13:23) [29]

С восстановленной базой работать стало еще хуже.
1. Ввожу "Нижегородская электрическая компания". Запрос выпоняется 390 мс. Находится одно предприятие с полным названием Закрытое акционерное общество "Нижегородская электрическая компания".
2. Ввожу "электрическая компания". И вот уже 20 минут выполняется.
Чего случилось то? Все понимаю, UPPER, LIKE, все долго, но не настолько же!

← →
galexis (2006-06-22 14:00) [30]

Дождался. Выполнился запрос. Смотрю в IBExpert Perfomance Analysis, а там большая часть времени потрачена на индексный поиск!
Т.е. если я ввожу Нижегородская электрическая компания, то идет неиндексный поиск со временем 80045, а если просто "электрическая компания", то неиндексный поиск все те же 80045, но появляется еще индексный с временем 349 784 353. Чего за хрень то? Может индексы перестроить?

← →
Johnmen © (2006-06-22 14:01) [31]

> galexis (22.06.06 13:23) [29]

Есть кое-какие соображения.
Приведи времена для
"%Нижегородская электрическая компания%"
"%ижегородская электрическая компания%"
"%жегородская электрическая компания%"
"%егородская электрическая компания%"
"%городская электрическая компания%"
"%ородская электрическая компания%"
"%родская электрическая компания%"
"%одская электрическая компания%"
"%дская электрическая компания%"
"%ская электрическая компания%"
"%кая электрическая компания%"
"%ая электрическая компания%"
"%я электрическая компания%"
"% электрическая компания%"
"%электрическая компания%"

← →
galexis (2006-06-22 14:21) [32]

"%Нижегородская электрическая компания%"
"%ижегородская электрическая компания%" 25 S 500 MS
"%жегородская электрическая компания%" 27s 125ms
"%егородская электрическая компания%" 27s 406ms
"%городская электрическая компания%" 26s 907ms
"%ородская электрическая компания%" 27s 500ms
"%родская электрическая компания%" 26s 63ms
"%одская электрическая компания%" 27s 281ms
"%дская электрическая компания%" 26s 609ms
"%ская электрическая компания%" 26s 594ms
"%кая электрическая компания%" 26s 657ms
"%ая электрическая компания%" 27s 578ms
"%я электрическая компания%" 27s 953ms
"% электрическая компания%"
"%электрическая компания%"

Пока все, очередной запрос выпоняется уже 2 минуты

← →
Johnmen © (2006-06-22 14:22) [33]

И ещё замерь
"%лектрическая компания%"

← →
galexis (2006-06-22 14:25) [34]

Может сам FireBird конфигурировать надо?

← →
galexis (2006-06-22 14:26) [35]

> Johnmen © (22.06.06 14:22) [33]

не могу, все еще "% электрическая компания%"
выполняется

← →
Johnmen © (2006-06-22 14:28) [36]

Дело не в кофигурации.
Всё-таки тесты проведи...

← →
galexis (2006-06-22 14:31) [37]

вот уже 12 минут выполняется "% электрическая компания%"
Может отменить?

← →
Johnmen © (2006-06-22 14:49) [38]

Конечно отменяй! Давно пора. Если время превышает 2-3 мин, то снимай...

← →
galexis (2006-06-22 14:56) [39]

ну вот, а я 33 прождал

← →
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] что при тормозном запросе план меняется, появляется какой-то индексный поиск ? Копай в эту сторону дальше!

> [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

[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]

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

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

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

> [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

> [78] galexis (23.06.06 10:18)
> На что влияет размер страницы?

Это куски, которыми хранится и читается информация.

← →
galexis (2006-06-23 10:37) [82]

> Sergey13 © (23.06.06 10:28) [81]

Это понятно, что куски, а какие куски? Поле таблицы? Или Строка таблицы?
Т.е., если, например размер страницы 1024 (байт?, Кб?), а строка получилась 1240, то она располагается в двух "кусках" по 1024. Тогда если увеличить размер страницы до 2048, строка поместится целиком, отсюда быстрее чтение и соответственно поиск. Так что ли?

http://www.ibase.ru/devinfo/pagesize.htm

более доступным языком
http://www.ibase.ru/ibfaq.htm#pagesize
http://www.ibase.ru/devinfo/ibfaq.htm#1.41

> [82] galexis (23.06.06 10:37)

Сервер читает не строками и не столбцами. Он читает кусками - кластерами (на физическом уровне - это относится к ОС) и страницами на логическом уровне. Поэтому желательно, что бы логический кусок (страница) был равен или кратен физическому (кластеру диска).

не понимаю, как размер страницы, так сильно может влиять на разницу в скорости выполнения запросов "%я электрическая компания%" и "% электрическая компания%"?

для исключения варианта [46], может имеет смысл поискать абракадабру, например "% вапмавпиыапьорвапп%", будет отрабатывать минуты или секунды?

← →
Виталий Панасенко (2006-06-23 11:32) [87]

select * from tester
where dataf1 like "%^_1_" escape "^" - первый раз 2 минуты. остальные разы 3-5 секунд. даже замена маски поиска производительность не ухудшала.
В таблице более 200000 записей. длина поля - 100, кодировка БД - NONE. Значение в поле типа
"11111111111111111111111111111_1",
"11111111111111111111111111111_2"
...
"11111111111111111111111111111_200000"
но встречаются и другие типа Right, Left, ib_odbc, Проба.
План
PLAN (TESTER NATURAL)

Адаптированный план
PLAN (TESTER NATURAL)

------ Performance info ------
Prepare time = 16ms
Execute time = 4s 125ms
Avg fetch time = 179,35 ms
Current memory = 744 120
Max memory = 944 368
Memory buffers = 2 048
Reads from disk to cache = 33 320
Writes from cache to disk = 6
Fetches from cache = 467 034

Размер страницы - 8194, машина - Пень-3/700(да, да !:-)) 256 ОЗУ. SCSI.
FireBird 1.5

← →
galexis (2006-06-23 11:40) [88]

select NAMEP from UL_NAME Where ( UPPER(NAMEP) LIKE "%" || "ЭЛЕКТРИЧЕСКАЯ" || "%")

Точно не уверен, но по моему все же || виноваты. Без них по моему работает.

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