sql server — быстрый запрос на MSSQL, но медленнее с переполнением стека
Мы решили перенести базу данных MS SQL Server 2014 на другой сервер, работающий в 2016 году. Теперь приложение PHP, использующее эту базу данных, значительно снизило производительность (количество запросов увеличилось с 1 или 2 секунд до 20), хотя база данных идентичны с точки зрения схемы, структуры и данных. Новый сервер имеет более высокие параметры ЦП, дисков и памяти, и рабочая нагрузка просто нормальная, поэтому такое снижение производительности вначале не имело смысла.
Затем я проанализировал некоторые запросы с помощью Profiler и с удивлением увидел, что план запроса отличается, когда он выполняется в Management Studio (быстро, от 1 до 3 секунд) или во внешнем интерфейсе приложения (медленно, от 15 до 25 секунд).
я нашел это ссылка на сайт, а также этот другие тоже, но после прочтения и пробуя разные вещи, я не могу решить проблему. Кто-нибудь имел дело с этим раньше? Любые намеки на быстрые вещи, чтобы проверить, прежде чем погрузиться глубоко?
Спасибо!
============
РЕДАКТИРОВАТЬ 1
Запрос возвращает только несколько записей, в зависимости от значений фильтров, но что-то 10 и 1000 (никогда больше, чем это, потому что он превысил 1000).
Основная запрашиваемая таблица содержит не один миллион записей и весит целую БД около 4 ГБ.
Индексы были успешно перенесены, затем перестроены и статистика обновлена.
РЕДАКТИРОВАТЬ 2
Среди всего, что я пробовал, — перестроить все индексы БД и обновить статистику всех таблиц БД. Я тоже заставлял RECOMPILE несколько раз (только из Management Studio). Я использовал подсказки по индексам, чтобы принудительно использовать некоторые индексы (только из Management Studio).
Ничто из этого не помогло мне решить проблему.
Что касается планов запросов, их очень очень трудно проанализировать, потому что мои запросы объединяют около 20 таблиц и имеют несколько подзапросов.
РЕДАКТИРОВАТЬ 3
Просто чтобы уточнить, запрос, который выдает разные планы выполнения, идентичен даже с параметрами. Я имею в виду, что я запускаю запрос из внешнего интерфейса, когда трассировка профилировщика активна, запрос захватывается (занимает около 20 секунд), и я копирую текст и вставляю его в Management Studio, выполняю тот же запрос и получаю результаты в всего 2 секунды, плюс другой план выполнения. Может ли проблема такого рода быть связана с анализом параметров?
Решение
Это может быть связано с тем, что свойство ArithAbort в вашей базе данных отключено. Смотрите также http://www.sommarskog.se/query-plan-mysteries.html
Вы можете проверить это и исправить с помощью этого небольшого скрипта
declare @value sql_variant
select @value = SESSIONPROPERTY('ARITHABORT')
if @value <> 1
begin
USE master
ALTER DATABASE [your_database] SET ARITHABORT ON WITH NO_WAIT
use your_database
end
Другие решения
Вам нужно извлечь оба плана выполнения: быстрый и медленный и сравнить их, вы должны проверить параметры, для которых были построены эти планы;
если вы найдете разные планы для одних и тех же запросов с разными параметрами, вы можете использовать опцию (перекомпилировать) или рассмотреть возможность переписать код, как описано в статье Соммарскога.
Не следует изменять atirhabort или другие параметры сеанса, потому что причиной разных планов в этом случае являются разные параметры, для которых был оптимизирован запрос; различные параметры сеанса просто заставляют сервер анализировать различные параметры, потому что новый план был построен