powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Про оптимизацию запроса и +0
10 сообщений из 10, страница 1 из 1
Про оптимизацию запроса и +0
    #39915294
dimmon.ua
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Есть запрос, например товары + остатки, но надо выбрать еще одну таблицу, которая не связана с первыми двумя, как справочник/параметр, но отдельным столбцом чтобы была.

Добился результата, но не могу понять правильно ли так делать.
Обычный fetch, не полный. Был основной запрос:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
SELECT
  c.num,
  c.kurs AS main_kurs,
  t.*
FROM
  tovar_name t
    JOIN tovar_zal z ON (t.num  = z.tovar_id AND z.firma_id = 547 AND z.sklad_id = 106)
    --JOIN currency c ON (c.num = t.num*0+2)
    JOIN currency c ON (c.num = 2)
WHERE
  t.visible = 1
ORDER BY
  t.name



Выполняется:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Plan
PLAN SORT (JOIN (C INDEX (IDX_CURRENCY_NUM), JOIN (T NATURAL, Z INDEX (IDX_TOVAR_ZAL_TOVAR_ID))))
------ Performance info ------
 Prepare time = 15ms
Execute time = 688ms 
Avg fetch time = 24,57 ms
Current memory = 79 961 472
Max memory = 80 170 864
Memory buffers = 2 048
Reads from disk to cache = 3 086
Writes from cache to disk = 1
Fetches from cache = 569 429

Делаю так:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
SELECT
  c.num,
  c.kurs AS main_kurs,
  t.*
FROM
  tovar_name t
    JOIN tovar_zal z ON (t.num  = z.tovar_id AND z.firma_id = 547 AND z.sklad_id = 106)
    JOIN currency c ON (c.num = t.num*0+2)
    --JOIN currency c ON (c.num = 2)
WHERE
  t.visible = 1
ORDER BY
  t.name


Выполняется:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Plan
PLAN JOIN (T ORDER TMP_IDX_TOVAR_NAME_NAME, C INDEX (IDX_CURRENCY_NUM), Z INDEX (IDX_TOVAR_ZAL_TOVAR_ID))
------ Performance info ------
 Prepare time = 16ms
Execute time = 0ms 
Avg fetch time = 0,00 ms
Current memory = 19 146 496
Max memory = 80 170 864
Memory buffers = 2 048
Reads from disk to cache = 18
Writes from cache to disk = 0
Fetches from cache = 690

Забираю WHERE, выполняется оба варианта за примерно 600ms, план:
Код: plaintext
PLAN SORT (JOIN (Z NATURAL, T INDEX (IDX_TOVAR_NAME_NUM), C INDEX (IDX_CURRENCY_NUM)))

Я так понимаю что вместо +0 можно использовать любое вычисление?
...
Рейтинг: 0 / 0
Про оптимизацию запроса и +0
    #39915299
dimmon.ua
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
забыл указать, версия 3.0.5
...
Рейтинг: 0 / 0
Про оптимизацию запроса и +0
    #39915310
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimmon.ua,

у тебя выполняет CROSS JOIN если что, но для того чтобы просто зафиксировать порядок "соединения" можно использовать LEFT JOIN

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
SELECT
  c.num,
  c.kurs AS main_kurs,
  t.*
FROM
  tovar_name t
    JOIN tovar_zal z ON (t.num  = z.tovar_id AND z.firma_id = 547 AND z.sklad_id = 106)
    LEFT JOIN currency c ON (c.num = 2)
WHERE
  t.visible = 1
ORDER BY
  t.name
...
Рейтинг: 0 / 0
Про оптимизацию запроса и +0
    #39915313
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimmon.ua
забыл указать, версия 3.0.5


если ещё и суперсервер, то поднимай страничный кеш раз в 20 для начала
...
Рейтинг: 0 / 0
Про оптимизацию запроса и +0
    #39915327
dimmon.ua
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Симонов Денис, спасибо, LEFT JOIN отрабатывает норм, старюсь максимально их избегать т.к. уже раз бился что в 2.5 работает, а в 3.0 нет и наоборот, а был момент что надо было чтобы работало в двух версиях одинаково красиво, сейчас все полностью уже на 3.0, вот и пытался выйти из ситуации, либо не умею готовить LEFT JOIN :)

По поводу кеша, прикрепил отличие от стандартных (вы мне кстати пару лет назад очень помогли насчет этого дела :) спасиб ), но думаю переборщил для обычных баз до 1 гб, часто сообщают об ошибке "Operating system directive MapViewOfFile failed.", но это уже другая тема будет если не разберусь.
...
Рейтинг: 0 / 0
Про оптимизацию запроса и +0
    #39915330
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimmon.uaстарюсь максимально их избегать

не надо их избегать. Надо разобраться когда оно нужно, а когда нет.
В данном случае LEFT JOIN только задаёт явный порядок соединения.

dimmon.uaПо поводу кеша, прикрепил отличие от стандартных

что-то я не вижу что ваш конфиг действует

Код: plaintext
1.
2.
3.
4.
 Memory buffers = 2 048 
Reads from disk to cache = 3 086
Writes from cache to disk = 1
Fetches from cache = 569 429

в хидер базы случайно не прописано?

dimmon.uaно думаю переборщил для обычных баз до 1 гб

вообще-то для каждой БД можно задавать индивидуально в databases.conf
...
Рейтинг: 0 / 0
Про оптимизацию запроса и +0
    #39915350
dimmon.ua
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Блин точно "Memory buffers = 2048" пошел за filemon интересно откуда он его взял
...
Рейтинг: 0 / 0
Про оптимизацию запроса и +0
    #39915410
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimmon.ua,

какой filemon??? проверяй gstat -h база.
...
Рейтинг: 0 / 0
Про оптимизацию запроса и +0
    #39915434
dimmon.ua
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kdv, в базе
авторPage buffers 0
...
Рейтинг: 0 / 0
Про оптимизацию запроса и +0
    #39915437
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimmon.ua,

тогда проверять, откуда запущен ФБ, и какой там конфиг лежит.
...
Рейтинг: 0 / 0
10 сообщений из 10, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Про оптимизацию запроса и +0
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]