В какой-то момент в Вашей карьере с SQL Server сниффинг параметра просто выскакивает и нападает?
Из того, что я могу извлечь из вашего вопроса, похоже, что вы находитесь на правильном пути с вашим запросом left join, однако, поскольку ваш запрос qAllDatesAllEmp содержит основные данные, вы должны вывести данные из этого запроса для записи, для которых соответствующие значения равны нулю в вашем запросе qDailyWorkEmp.
В вашем запросе также есть опечатка в этой строке:
qAllDatesAllEmp.WhatDate = qDailyWorkEmp.DailyDate
Как вы указали в своем вопросе, запрос qAllDatesAllEmp содержит поля:
WhatDate не является одним из этих полей.
Вам также нужно будет присоединиться к полю empID в обоих запросах, чтобы сравнивать поле даты на основе на сотрудника , а не сравнивать каждую дату с даты всех сотрудников - следовательно, ваши критерии объединения должны быть:
qAllDatesAllEmp LEFT JOIN qDailyWorkEmp ON
qAllDatesAllEmp.WorkDate = qDailyWorkEmp.DailyDate AND
qAllDatesAllEmp.empID = qDailyWorkEmp.empID
С учетом предоставленной информации я мог бы предложить следующее:
SELECT
qAllDatesAllEmp.empID,
qAllDatesAllEmp.empName,
qAllDatesAllEmp.CityBased
qAllDatesAllEmp.WorkDate as MissingDate
FROM
qAllDatesAllEmp LEFT JOIN qDailyWorkEmp ON
qAllDatesAllEmp.WorkDate = qDailyWorkEmp.DailyDate AND
qAllDatesAllEmp.empID = qDailyWorkEmp.empID
WHERE
qDailyWorkEmp.DailyDate IS NULL
4 ответа
Не совсем ответ, но я поделюсь своим опытом.
Обнюхивание параметров заняло несколько лет SQL Server, чтобы прийти и укусить меня, когда я вернулся к администратору базы данных разработчика после перехода на в основном продд DBA работает. Я больше разбирался в движке, как работает SQL, что лучше оставить клиенту и т. Д., И я был лучшим кодировщиком SQL.
Например, динамический SQL или CURSOR или просто плохой код SQL, вероятно, никогда не пострадают от параметра нюхать. Но лучше настроить программирование или как избежать динамического SQL или более элегантного SQL, скорее всего.
Я заметил это для сложного кода поиска (много условных операторов) и сложных отчетов, где значения параметров по умолчанию влияли на план. Когда я увижу, как менее опытные разработчики напишут этот код, тогда он не пострадает от обнюхивания параметров.
В любом случае, я предпочитаю маскировку параметров, а не WITH RECOMPILE. Обновление статистики или индексов в любом случае вызывает перекомпиляцию. Но зачем все время перекомпилировать? Я ответил в другом месте на один из ваших вопросов ссылкой, в которой упоминается, что параметры анализируются во время компиляции, поэтому я тоже не верю в это.
Маскирование параметров - это накладные расходы, да, но это позволяет оптимизатору оценить запрос от случая к случаю, а не полная перекомпиляция. Особенно с перекомпиляцией на уровне операторов SQL Server 2005
OPTIMIZE FOR UNKNOWN в SQL Server 2008, похоже, также происходит то же самое, что и маскирование.
Я подозреваю, что Ваша проблема вызывается из статистики данных. Так как у Вас нет доступа DBA к серверу, я поощрил бы Вас спрашивать DBA, когда в прошлый раз статистические данные были обновлены. Это может оказать огромное влияние на производительность. Это также кажется, что Ваши таблицы не индексируются очень хорошо.
В основном это не "чувствует" как проблема сниффинга параметра, но больше "здоровой" проблемы базы данных.
Эта статья описывает, как можно определить в прошлый раз, когда статистические данные были обновлены: Время Обновления Статистики
Я второй комментарий о проверке статистики - я видел несколько экземпляров, где производительность запроса упала с утеса конкретно, потому что статистические данные устарели.
А именно, если у Вас есть дата в Вашем PK, и SQL Server думает, что существует только 10 или 100 записей который после определенной даты когда на самом деле существуют тысячи, это может выбрать ужасно неэффективные планы запросов, потому что это думает, что набор данных намного меньше, чем это действительно.
HTH,
- Andrew
У меня была производственная проблема точно как это. Вкладка в приложении, которое названный сохраненным proc не показал бы. Я выполнил трассировку для определенного proc и видел вызов. Приложение испытывает таймаут в 30 secs, и proc взял бы близко к 40 - 50 secs для завершения (выполнил proc точно, как названо от трассировки).
Следующий шаг должен был выяснить, какой оператор вызывал сканирования, которые я замечаю в осуществлении процедуры. Таким образом, я написал сценарий proc, удалил синтаксис процедуры и объявил переменные и работал в анализаторе запроса. Это РАБОТАЛО в 3 secs!!!
Я пишу это для разрешения любому, кого туда поиск ответов знает, что это может произойти в SQL. Это происходит от проблемы сниффинга параметра. Я был способным t ofind этот поток, потому что я точно определил причину как дефектный кэшируемый план запросов! Я прочитал сообщения, где они сказали, что это происходит с определенными пользователями / значение. Но это может произойти с любым значением и после того как это запускается, это может быть непрерывная вещь.
Решение для меня состояло в том, чтобы написать сценарий proc и выполнить его снова. да. то простое. Изменение хорошо работает. Никакая потребность отбросить и воссоздать. Это заставляет SQL обновлять кэшируемый план, и вещи были прекрасны. Я не выяснил, как отключить это на уровне сервера. Это является слишком громоздким для чистки всего procs.Надеюсь, это поможет