Я потратил много времени на оптимизацию запроса для нашего администратора БД. Когда я запускаю его на нашем тестовом сервере и на нашем живом сервере, я получаю аналогичные результаты. Тем не менее, когда он действительно запущен в производство с большим количеством запросов, он работает очень плохо.
Я могу опубликовать код, но запрос содержит более 1400 строк, и потребуется много времени, чтобы его запутать. Все типы данных совпадают, и я использую индексы в своих запросах. Он разбит на 58 временных таблиц. Когда я тестирую его с помощью SQL Sentry, я получаю его с использованием 707 циклов ЦП и 90 0007 операций чтения и временем 1,2 секунды для запуска определенного оператора exec. Те же самые параметры в работе на прошлой неделе использовали 10 831 такт процессора, 2,9 млн операций чтения и 33,9 секунды для запуска.
Мой вопрос заключается в том, что может заставить оптимизатор выполнять больше циклов и операций чтения, чем мои однократные тесты. ? Как я уже упоминал, я мог бы при необходимости опубликовать код, но я ищу ответы, которые указывают мне направление для устранения такого расхождения. Эта конкретная процедура часто запускается в течение нашего цикла выставления счетов, поэтому она попадает на сервер сотни раз в день, а к 15 числам этого месяца она станет равной тысячам.
Спасибо
ДОБАВЛЕНИЕ: Я знаю, как оптимизировать запросы, так как это обычная часть моих рабочих обязанностей. Как я отмечал в комментарии, мои тестовые запросы не имеют таких больших отличий, как обычно, от реального производства. Я не знаю, что такое SQL Server, и подумал, есть ли что-то, о чем я должен знать, что может повлиять на мой запрос, когда сервер находится под более высокой нагрузкой. Возможно, это выходит за рамки этого форума, но я подумал, что смогу обратиться к идеям сообщества.
ОБНОВЛЕНИЕ: Я все еще решаю эту проблему, просто отвечая на некоторые комментарии.
Планы выполнения одинаковы между моими разовыми тестами и выполнением на уровне производства. Я тестирую в той же среде, на том же сервере, что и производство. Это процедура для данных отчета. Возвращенные данные, записи и совпадения таблиц одинаковы. Я тестирую с использованием тех же параметров, которые во время производства занимали астрономические промежутки времени, разница между тем, что я делаю, и тем, что происходило во время производственного цикла, заключается в нагрузке на сервер. Не все производственные исполнения занимают много времени, подавляющее большинство находится в пределах допустимых значений ЦП и считываний, когда выбросы имеют такое большое расхождение, что в 500 раз превышает ЦП и в 150 раз превышают средние показатели выполнения (даже прите же параметры).
У меня нулевой контроль над серверной стороной вещей. Я только могу контролировать, как кодировать процесс. Я понимаю, что мой процесс большой, и без него, вероятно, невозможно получить хороший ответ на этом форуме. Я также понимаю, что даже с кодом, размещенным здесь, я вряд ли получу хороший ответ из-за размера процедуры.
Я искал / искал только идеи, указания на вещи, используя неподтвержденную информацию о проблемах, которые другие разработчики преодолели при решении подобных проблем. Комментарии, в которых говорится о размере моего кода, являются причиной того, что производительность находится в унитазе, и тот код, размер которого необходим редко, не полезен и, откровенно говоря, невежественен. Я работаю с устаревшим кодом C # и базой данных, которая имеет дело с миллионами транзакций для выставления счетов. Тысячи таблиц в десятках взаимосвязанных баз данных с ERD, которые поразят вас, я оптимизирую кошмар. Тем не менее, я очень хорош в этом, и когда я и администраторы баз данных оказались в тупике относительно того, почему мы видим такие резкие цифры, я подумал, что смогу расширить свою сеть и посмотреть, есть ли у этого более крупного сообщества какие-либо идеи.
Ниже приведено изображение, показывающее отчет о 32 лучших исполнениях этой процедуры в 15-минутном окне. Даже среди топ-32 цифры не совпадают. Изображение ниже показывает все временные таблицы и основной запрос, который я только что выполнил на том же сервере для # 1 ресурсной свиньи первого изображения. Строки - это разные временные таблицы с суммой внизу. Сумма показывает 1,5 (1,492) секунды для запуска с 534 процессорами и 92 045 чтениями. Сравните это с 33,9 секундами, 10 831 процессором и 2,9 миллионами чтений вчера:
