Погане виконання запитів

У нас є велика (10 000+ рядків) процедура, яка зазвичай працює за 0,5-6,0 секунди, залежно від того, скільки даних вона має працювати. За останній місяць або близько того він почав займати 30+ секунд після того, як ми зробимо оновлення статистики з FULLSCAN. Коли вона сповільнюється, sp_recompile "виправляє" проблему, доки нічна робота зі статистикою не запуститься знову.

Порівнюючи плани повільного та швидкого виконання, я звузив його до конкретної таблиці / індексу. Коли вона працює повільно, підрахунок ~ 300 рядків буде повернуто з певного індексу, коли він працює швидко, він оцінює 1 рядок. Коли він працює повільно, він використовує табличну котушку після пошуку за індексом, коли вона працює швидко, вона не робить катушку таблиці.

Використовуючи DBSS SHOW_STATISTICS, я зрозумів гістограму індексу в excel. Зазвичай я очікував би, що графік буде більш «горілим пагорбом», але натомість він виглядає як гора, найвища точка на 2–3 рази вище, ніж у більшості інших значень на графіку.

Якщо я оновлюю статистику на ньому, без FULLSCAN, це виглядає нормальніше. Якщо я запускаю його знову з FULLSCAN, це виглядає так, як я описав вище.

Це відчувається як проблема нюхання параметрів, і конкретно пов'язана з (здавалося б) дивним розподілом індексу вище.

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

EDIT: Proc також приймає 12 інших параметрів, деякі з яких необов’язкові, два з яких - дата початку та закінчення.

Чи гістограма непарна, чи я гавкаю неправильне дерево?

Мені, звичайно, зручно намагатися коригувати запит та / або намагатися коригувати свою індексацію. Якщо це найкраще виправлення, тоді моє питання стосується скоріше гістограми.

Слід зазначити, що це кластерний індекс PK IDENTITY. У нас є дві системи, які розмовляють між собою, одна успадкована система, одна - нова домашня система. Обидві системи зберігають схожі дані. Щоб синхронізувати їх, ПК у цій таблиці в новій системі збільшується, коли речі додаються до старої системи, навіть якщо дані не надходять (виконано RESEED). Тож у цій колонці можуть бути деякі прогалини в нумерації. Записи рідко, якщо взагалі, видаляються.

Будь-які думки були б дуже вдячні. Я більш ніж радий зібрати / включити більше інформації.

Це в результаті пов'язано з обнюхуванням параметрів. Так сталося, що деякі дивно сформовані версії цього запиту виконувались ПРАВИЛЬНО ПІСЛЯ СТАТТЯ, яка була відновлена. Таким чином, кешований план не був репрезентативним для більшості дзвінків. Я використав хитрість копіювання параметрів дати до локальних змінних, і це працює чудово, мало впливаючи на продуктивність. Це не відповідає чому гістограма виглядає настільки «вимкненою», але це пояснює мої проблеми з продуктивністю.