Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Firebird, Interbase > Firebird 2.5 выборка идет медленно

Автор: Radekk 24.9.2015, 10:00

На локальной машине Firebird 2.5 Charset UTF+8 collate UNICODE_CI_AI , page size 16384
Колэйшн выбрал, чтобы искал и диакритику. Добавил индексы на поля по которым идет выборка и нет никакого движения, таблица небольшая 14.5К записей.
field_name Varchar(500) charset UTF-8 collate UNICODE_CI_AI
запрос типа (тот же результат дает и containing)

Код


select nume from table_name where  table_field like '%sometext%'

Выдает

Prepare time = 15ms
Execute time = 3s 963ms
Avg fetch time = 188,71 ms

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

Код


/* Affected rows: 0  Найденные строки: 33  Предупреждения: 0  Длительность  1 query: 0,015 sec. */

разница просто бешенная.
никак не могу понять что я делаю не так??? smile

Автор: Akina 24.9.2015, 11:04

Конструкция

Код


where table_field like '%sometext%'

не может использовать индекс по table_field для отбора. Зря старался.

Быстрое выполнение в MySQL скорее всего определяется тем, что вся таблица (или покрывающий индекс, если имеется) была загружена в кэш (или уже лежала в нём) и обрабатывалась чисто в памяти. А Firebird явно возил носом по диску.

Автор: Radekk 24.9.2015, 13:26

Akina,
а не подскажете тогда как можно это дело ускорить? ну или хоть в какую сторону копать?

я уже и в mssql проверил - тоже быстро отрабатывает

попробовал создать пустую базу с одной таблицей в фаерберде и картина никак не изменилась.

Автор: Akina 24.9.2015, 13:55

Для конкретно этого запроса единственное видимое ускорение - это создание индекса по (nume, table_field) или наоборот (для покрывающего индекса неважно, скорее всего). Но главное - это обеспечить попадание индекса или таблицы в кэш и не-вымывание его оттуда, чтобы не было обращений к диску. Как - не подскажу.

Автор: tzirechnoy 25.9.2015, 10:08

3s на full scan 15к записей -- это можэт быть что угодно, только не проблемы с неправильными индэксами. Ну, там, база забита незакоммиченными транзакцыями или винт подыхает или всё в первый раз достаётся с диска, включая весь сервер firebird. В общем, ищите проблемы не в вашэм запросе.

Автор: Radekk 1.10.2015, 12:55

путем долгого долбления головой в стену нашел в чем проблема была.
на этой же машине стояла еще версия 2.1 на 3021 порту, 2.5 стояла на стандартном 3050, после того как снес все к х..ам собачьим и переустановил последнюю версию фаерберда заработало

Prepare time = 16ms
Execute time = 93ms

хотя две базы устанавливали по инструкции от IBExpertise. Но видимо мешали они друг дружке.

Цитата(Akina @ 24.9.2015, 11:04

)

не может использовать индекс по table_field для отбора. Зря старался.

фаерберд текстовые поля не индексирует или вы к тому что запрос типа '%string_i_want_to_find%' полюбому через всю таблицу будет пробегать и индексы пофигу???

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

Автор: Akina 1.10.2015, 13:00

Цитата(Radekk @ 1.10.2015, 13:55

)

или вы к тому что запрос типа '%string_i_want_to_find%' полюбому через всю таблицу будет пробегать и индексы пофигу???

Конечно, пофиг... Представь, что у тебя телефонный справочник. По алфавиту. Найти всех Ивановых - да элементарно, открываем на букву И... А попробуй найти всех, скажем, Маргарит...

Добавлено через 1 минуту и 34 секунды

Цитата(Radekk @ 1.10.2015, 13:55

)

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

Индексирование будет выполнено в момент создания, если не установлено какое-нить IGNORE_INDEX.

Добавлено через 3 минуты и 28 секунд

Цитата(Radekk @ 1.10.2015, 13:55

)

на этой же машине стояла еще версия 2.1 на 3021 порту, 2.5 стояла на стандартном 3050,

Если это делалось штатным инсталлером и правкой конфигов - то у тебя тупо была проблема пересечения регистрации одноимённых модулей. Установка на одной машине двух и более инстансов FB - задача ни фига не тривиальная...

Автор: Radekk 1.10.2015, 13:25

Еще один вопрос по поводу индекса, в IBExpert создаю индекс по полю таблицы, после компиляции он показывает что индекс активен и статистику, а когда делаешь выборку по индексам то напротив индекса в столбце RDB$INDEX_INACTIVE висит значение NULL вместо нуля(единица как я полнял если индекс не активен).
Это нормально или надо запросом активировать индекс????

всем спасибо за помощь.

Автор: Akina 1.10.2015, 13:51

Цитата(Radekk @ 1.10.2015, 14:25

)

когда делаешь выборку по индексам то напротив индекса в столбце RDB$INDEX_INACTIVE висит значение NULL вместо нуля(единица как я полнял если индекс не активен).
Это нормально или надо запросом активировать индекс????

А какая разница? ты проверь, что индекс используется при выполнении запросов, когда он по уму использоваться обязан. Если да - то не пофиг ли, чего там в таблице, которая не влияет на работу, а только даёт некие сведения?

Автор: Radekk 1.10.2015, 15:48

Цитата(Akina @ 1.10.2015, 13:51

)

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

а есть у фаерберда тогда что-то на подобии explain в mysql, например?
ну чтоб видно было использовался ли индекс при выборке из таблицы???
или это можно где в самом IBExpert посмотреть???

Автор: Akina 1.10.2015, 16:41

А набрать "show execution plan" в строке поиска на сайте документации firebird религия не позволила?
http://www.firebirdsql.org/manual/isql-set.html#isql-set-plan

Автор: Radekk 2.10.2015, 08:25

Цитата(Akina @ 1.10.2015, 16:41

)

А набрать "show execution plan" в строке поиска на сайте документации firebird религия не позволила?

я конечно RTFM всегда, но у Борри больше 800 страниц, все за один присест не осилишь.... И про "show execution plan" первый раз от вас услышал.
Спасибо за объяснение и линк, буду читать.

Автор: Akina 2.10.2015, 09:36

Цитата(Radekk @ 2.10.2015, 09:25

)

про "show execution plan" первый раз от вас услышал.

Ну ты ж сам ссылаешься на MySQL - а какими, спрашивается, словами там в документации описывается назначение explain? Это только у Microsoft есть такая порочная практика - придумывать свои уникальные термины и определения, порой вопреки всякой логике...

Автор: Radekk 2.10.2015, 10:51

Цитата(Akina @ 2.10.2015, 09:36

)

Это только у Microsoft есть такая порочная практика

ну мало-ли, всякое бывает... ну и да иногда лучше спросить напрямую у знающего человека чем у гугла))))
спасибо за информацию и терпение.

Автор: tzirechnoy 2.10.2015, 11:39

Цитата

запрос типа '%string_i_want_to_find%' полюбому через всю таблицу будет пробегать и индексы пофигу???

Не по любому -- во многих базах есть full text search indexes, которые помогают в некоторых таких случаях (там всё достаточно сложно, на самом деле), но создаваемый по умолчанию btree здесь действительно ничем не поможэт.

Автор: Akina 2.10.2015, 11:47

tzirechnoy, по-моему, полнотекстовый индекс НЕ используется в запросах типа LIKE. Впрочем, не исключаю, что это зависит от СУБД.

Автор: tzirechnoy 2.10.2015, 15:04

Полнотекстовые индэксы бывают очень разные. В постгрессе, например, есть полнотекстовые индэксы, которые используются в LIKE -- из модуля pg_trgm. И есть отдельная (и более древняя вроде) фишка под названием "полнотекстовый поиск", для которого тожэ есть свои индэксы (на тип ts_vector), которые не могут использоваться в LIKE (зато этот поиск обладает развитым лексическим анализатором и нетривиальным ранжырованием).

Автор: Akina 2.10.2015, 15:18

Цитата(tzirechnoy @ 2.10.2015, 16:04

)

Полнотекстовые индэксы бывают очень разные. В постгрессе, например, есть полнотекстовые индэксы, которые используются в LIKE -- из модуля pg_trgm.

Я помню свой ещё очень давний и, есссно, уже заброшенный, интерес - понять, каковы должны быть индексы для эффективного поиска по подстроке (вот тот самый LIKE "%substring%"). Даже как-то попытался прикинуть, каким может получиться индекс на основе суффиксного дерева - и, надо сказать, впечатлился объёмами.

Автор: tzirechnoy 2.10.2015, 15:43

Ну, pg_trgm -- это триграммы. Объём не очень большой, а селективность не то чтобы всегда плохая.

Кроме того, советую посмотреть на реализацыю в glimpse. Я её так и не понял до конца, но индэкс у неё довольно эффективный и умеренного размера (меньшэ чем текст, типично).