У меня была похожая проблема: запрос, который возвращает 4000 строк и сам по себе выполняется за 1 секунду, занимал в SSRS так много времени, что время его ожидания истекло.
Оказалось, что проблема была вызвана тем, как SSRS обрабатывал многозначный параметр. Интересно, что если пользователь выбрал несколько значений, отчет формировался быстро (~ 1 секунда), но если было выбрано только одно значение, отчету потребовалось несколько минут.
Вот исходный запрос, который рендерится более чем в 100 раз дольше, чем следует:
SELECT ...
FROM ...
WHERE filename IN (@file);
-- @file is an SSRS multi-value parameter passed directly to the query
Я подозреваю, что проблема заключалась в том, что SSRS вводил всю исходную таблицу (более 1 миллиона строк) и затем выполнял фильтр на стороне клиента.
Чтобы исправить это, я передал параметр в запрос через выражение, чтобы я мог сам управлять фильтром. То есть в окне «Свойства набора данных» на экране «Параметры» я заменил значение параметра следующим выражением:
=JOIN(Parameters!file.Value,",")
... (я также дал результату новое имя: filelist), а затем обновил запрос, чтобы он выглядел так:
SELECT ...
FROM ...
WHERE ',' + @filelist + ',' LIKE '%,' + FILENAME + ',%';
-- @filelist is passed to the query as the following expression:
-- =JOIN(Parameters!file.Value,",")
Я бы предположил, что перемещение запроса к хранимой процедуре также будет эффективным способом решения проблемы (поскольку SSRS в основном делает то же самое JOIN перед передачей многозначного параметра в хранимую процедуру). Но в моем случае было немного проще справиться со всем этим в отчете.
Наконец, я должен отметить, что оператор LIKE, возможно, не самый эффективный способ фильтрации по списку элементов, но его код, конечно, намного проще, чем подход с разделением строк, и отчет теперь выполняется примерно за секунду. так что расщепление струны не стоило дополнительных усилий.