Низкая производительность запросов

У нас есть большая (более 10000 строк) процедура, которая обычно выполняется за 0,5-6,0 секунд в зависимости от объема данных, с которыми она должна работать. За последний месяц или около того прошло более 30 секунд после того, как мы обновили статистику с помощью FULLSCAN. Когда он замедляется, sp_recompile «исправляет» проблему, пока задание ночной статистики не запустится снова.

Сравнивая медленные и быстрые планы выполнения, я сузил их до конкретной таблицы / индекса. Когда он работает медленно, он оценивает ~ 300 строк, которые будут возвращены из определенного индекса, когда он работает быстро, он оценивает 1 строку. Когда он работает медленно, он использует Table Spool после выполнения поиска по индексу, когда он работает быстро, он не выполняет Table Spool.

Используя DBSS SHOW_STATISTICS, я построил гистограмму индекса в Excel. Я обычно ожидал бы, что график будет более «скользящим», но вместо этого он выглядит как гора, самая высокая точка которой в 2–3 раза выше, чем большинство других значений на графике.

Если я обновлю статистику по нему, без FULLSCAN, это выглядит более нормально. Если я снова запустил его с FULLSCAN, это выглядит так, как я описал выше.

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

Процедура принимает параметр с табличным значением, может ли сниффинг параметра происходить с параметром с табличным значением?

РЕДАКТИРОВАТЬ: процедура также принимает 12 других параметров, некоторые из которых являются необязательными, два из которых являются начальной и конечной датой.

Гистограмма странная или я лаю не на том дереве?

Я, конечно, чувствую себя комфортно, пытаясь настроить запрос и / или попытаться настроить индексирование. Если это исправление, которое отлично, тогда мой вопрос больше касается искаженной гистограммы.

Следует отметить, что это кластерный индекс PK IDENTITY. У нас есть две системы, которые общаются друг с другом, одна унаследованная система, одна новая доморощенная система. Обе системы хранят одинаковые данные. Чтобы синхронизировать их, PK в этой таблице в новой системе увеличивается при добавлении вещей в старую систему, даже если данные не возвращаются (выполняется RESEED). Таким образом, в этой колонке могут быть некоторые пробелы. Записи редко, если вообще удаляются.

Любые мысли будут с благодарностью. Я более чем счастлив собрать / включить больше информации.

Это в конечном итоге связано с анализом параметров. Так уж сложилось, что некоторые странно сформированные версии этого запроса выполнялись ПРЯМО ПОСЛЕ того, как статистика была перестроена. Таким образом, кэшированный план не был репрезентативным для большинства звонков. Я использовал способ копирования параметров даты в локальные переменные, и это работает просто отлично, практически не влияя на производительность. Это не объясняет, почему гистограмма выглядит так «выключено», но объясняет мои проблемы с производительностью.