|
![]() |
#1 |
Участник
|
В развитии своей проблемы забрел в эту тему)) Собственно профайлер SQL показал:
1. При FINDSET в SQL при обходе в цикле происходит следующее(запрос целиком не привожу - ясно будет и так, в конце каждого запроса имеется WHERE по наложенным на таблицу фильтрам): SELECT TOP 51 ......... - при первом подходе и SELECT TOP 1 ........ до конца выборки, если в ней больше выбранных за первый подход записей 2. При FIND('-') выявлено: SELECT (*) ....... Итог: Если в таблице после наложения фильтров остается 1-150 записей - FINDSET работает быстрее FIND('-'), причем увеличение записей приводит к их уравниванию. Примерно одинаково отрабатывают оба варианта в диапазоне 200-400 записей Если выборка составляет более 1000 записей FIND('-') выигрывает у FINDSET уже довольно серьезно (на 36000 записей: FINDSET показал результат 258000мс, FIND('-') - 150000мс. Был организован простой проход в цикле по записям выборки с записью в лог разницы во времени между итерациями цикла, таблица "Customer Ledger Entry"). Пост всего лишь описание найденного узкого места по FIND vs FINDSET - необходимо представлять какое количество будет при выборке, и в зависимости от этого плясать...
__________________
Как только вы проиграете, все ваши прошлые победы забудут. |
|
![]() |
#2 |
Участник
|
Уже что-то не так в логике, раз приходится переперать сотни записей.
Есть ещё косяк интересный, если рекурсивно делать FINDSET к одной и той же таблице(вложенно). FINDSET вроде как кеширует набор, но при вложенности кеш слетает, и летят кривые запросы к базе. Жуть как торомозит. |
|
![]() |
#3 |
Участник
|
Нашёл сегодня повод поднять эту старую тему.
Я тут случайно обнаружил, что из NAV2013 и NAV2015 исчез параметр отвечающий за размер кэша для FINDSET. Кроме того, из хелпа пропали описания различий между FIND и FINDSET. Сами же описания данных функций стали до безобразия скудны. Всё это заставляет задуматься, а как теперь всё это работает? И где про это можно почитать? |
|