Під час дослідження повільного запиту з'ясувалося, що план виконання був виключно неоптимальний (вкладений цикл, який виконував 9 мільйонів страт пошуку, де орієнтовна кількість страт становила 1). Підтвердивши, що деякі відповідні статистичні дані, де справді застаріли, я відновив статистику, і проблема ефективності ефективно вирішена.
У цій базі даних включено статистику автоматичного оновлення (увімкнено за замовчуванням). Я розумію, що існує поріг для оновлення автоматичної статистики на основі 20% + 500 рядкових модифікацій (оновлення / вставлення / видалення). Схоже, цей поріг значно перевищений у кількох індексах, тому такий, мабуть, є (A) проблема з автоматичними оновленнями, або (B) Існує більше стратегії оновлення, ніж мені вдалося знайти в Інтернеті документація.
Я розумію, що заплановане завдання може бути встановлено для оновлення статистики, і це, ймовірно, такий підхід, який ми застосовуємо, якщо не знайдемо іншого рішення, але це не бентежить, чому така велика кількість модифікацій не призведе до запуску автоматичне оновлення для деяких статистичних даних - розуміння того, чому може допомогти нам вирішити, яку статистику потрібно оновлювати плановим завданням.
Деякі додаткові примітки:
1) Проблема була помічена в базі даних, де дані створюються за допомогою тесту навантаження і тому така велика кількість даних додається за короткий проміжок часу, таким чином, якщо автоматичне оновлення відбувалося періодично (наприклад, раз на день у більшість) тоді це може пояснити деяку спостережувану поведінку. Також наші тести навантаження, як правило, сильно навантажують базу даних, тому мені цікаво, чи SQL відкладає оновлення статистики, коли є велике навантаження (а згодом не оновлюється статистика чомусь).
2) При спробі відтворити цю проблему за допомогою тестового сценарію, що містить послідовні заяви INSERT, SELECT і DELETE, проблеми не виникло. Мені цікаво, чи є тут відмінність у тому, що ці твердження впливають на багато рядків у SQL-операторі, тоді як наш сценарій тестування навантаження буде схильний вставляти рядки окремо.
3) Розглянута БД встановлена в 'Простій' моделі відновлення.
Деякі відповідні посилання:
- Контрольний список для аналізу повільних запитів
- Використання статистики для підвищення ефективності запитів
Я також порушив цю проблему через підключення microsoft:
ОНОВЛЕННЯ 2011-06-30:
При подальшому дослідженні я вважаю, що статистика, яка застаріла за пороговими рівнями (наприклад, 500 рядків + 20%), - це статистика, яка не використовується проблемним запитом, отже, ймовірно, вони будуть оновлені при запуску запиту. що вимагає від них. Для статистики , які є використовуваної в запиті, вони регулярно оновлюються. Залишилося питання в тому, що ці статистичні дані грубо вводять в оману оптимізатора плану запитів після лише порівняно небагато вставок (наприклад, спричинення вищезгаданих 9 мільйонів або близько шукає, де оціночне число було 1).
Моя думка в цей час полягає в тому, що проблема пов'язана з поганим вибором первинного ключа, ключ - це унікальний ідентифікатор, створений за допомогою NEWID (), і тому дуже швидко створюється дуже фрагментований індекс - особливо як фактор заповнення за замовчуванням у SQL Сервер - 100%. Моя думка полягає в тому, що це якимось чином призводить до оманливих статистичних даних після відносно мало вставлених рядків - менше, ніж поріг для перерахунку статистики. Це все, можливо, не проблема, оскільки я створив багато даних, не будуючи індекси частково, через що погана статистика може бути наслідком дуже великої фрагментації індексу. Я думаю, що мені потрібно додати цикли обслуговування SQL Server до мого тесту навантаження, щоб краще розуміти продуктивність у реальній системі протягом тривалих періодів часу.
ОНОВЛЕННЯ 2012-01-10:
Ще один фактор, який слід врахувати. До SQL Server 2005 були додані два прапори слідів (і, здається, вони все ще присутні у 2008 році) для усунення конкретних недоліків, пов’язаних із виникненням застарілої та / або оманливої статистики. Прапорці, про які йдеться, такі:
DBCC TRACEON(2389)
DBCC TRACEON(2390)
MSDN: Веб-журнал Ієна Хосе: висхідні ключі та автоматична швидка виправлена статистика статистики щодо висхідних стовпців, Фабіано Аморім
Звичайно, ви повинні бути дуже обережними, вирішуючи включити ці прапори, оскільки вони можуть мати згубний вплив.