Преобразование в datetime не выполняется только в предложении WHERE?

Если преобразование находится в предложении WHERE, оно может быть оценено для гораздо большего количества записей (значений), чем было бы, если бы оно появилось в списке проекций. Я уже говорил об этом раньше в другом контексте, см. Функции T-SQL не подразумевают определенный порядок выполнения и При коротком замыкании логического оператора SQL Server. Ваш случай еще проще, но похож, и в конечном итоге основная причина та же: не предполагайте императивный порядок выполнения при работе с декларативным языком, таким как SQL.

Лучшее решение, с большим отрывом, - очистить данные и изменить тип столбца на тип DATETIME или DATETIME2. Все другие обходные пути будут иметь тот или иной недостаток, поэтому вам может быть лучше просто поступить правильно.

Обновить

После более внимательного рассмотрения (извините, я @VLDB и просматриваю SO только между сессиями) я понимаю, что у вас есть хранилище EAV с присущей семантикой без типов (attribute_value может быть строкой, датой, int и т. Д.). Я считаю, что лучше всего использовать sql_variant в хранилище и вплоть до клиента (например, проекта sql_variant). Вы можете согласовать тип в клиенте, все клиентские API имеют методы для извлечения внутреннего типа из sql_variant, см. Использование данных sql_variant (ну, почти все клиентские API ... Использование типа данных sql_variant в среде CLR). С sql_variant вы можете хранить несколько типов без проблем с просмотром строковых представлений, вы можете использовать _ 6_ для проверки таких вещей, как BaseType в сохраненных значениях, и вы даже можете думать, например, о проверке ограничений, чтобы обеспечить правильность типа данных.

Кажется, вы предполагаете какую-то оценку короткого замыкания или гарантированный порядок предикатов в предложении WHERE. Это не гарантируется. Когда вы используете смешанные типы данных в таком столбце, единственный безопасный способ справиться с ними - использовать выражение CASE.

Используйте (например,)

CONVERT(DATETIME, 
      CASE WHEN ISDATE(pa.Attribute_Value) = 1 THEN pa.Attribute_Value END)

Нет

CONVERT(DATETIME, pa.Attribute_Value)

Это связано с порядком обработки SELECT запроса. Предложение WHERE обрабатывается задолго до SELECT. Он должен определить, какие строки включить / исключить. Предложение, использующее имя, должно использовать сканирование, которое исследует все строки, некоторые из которых не содержат действительных данных даты / времени, тогда как ключ, вероятно, ведет к поиску, и ни одна из недопустимых строк не включается в точку. Преобразование в списке SELECT выполняется последним, и очевидно, что к этому времени он не будет пытаться преобразовать недопустимые строки. Поскольку вы смешиваете данные даты и времени с другими данными, вы можете рассмотреть возможность хранения даты или числовых данных в выделенных столбцах с правильными типами данных. А пока отсрочить проверку можно следующим образом:

SELECT /* ... */
FROM
(
  SELECT /* ... */
    FROM ProductAttributes AS pa
    INNER JOIN dbo.Attributes AS a
    ON a.Attribute_ID = pa.Attribute_ID
    WHERE a.Attribute_Name = 'SomeDate'
    AND ISDATE (pa.Attribute_Value) = 1
) AS z
WHERE CONVERT(CHAR(8), AttributeValue, 112) < CONVERT(CHAR(8), GETDATE(), 112);

Но лучшим ответом, вероятно, будет использование клавиши Attribute_ID вместо имени, если это возможно.

Мне кажется, проблема с данными. Взгляните на данные, когда вы выберете их двумя разными способами, попробуйте найти различные длины, а затем выберите элементы в разных наборах и оцените их. Также проверьте наличие нулей? (Я не уверен, что произойдет, если вы попытаетесь преобразовать null в datetime)

Я думаю, проблема в том, что у вас плохая дата в вашей базе данных (очевидно).

В вашем первом примере, где вы не проверяете дату в предложении WHERE, все даты, где a.attribute.Name = 'SomeDate' действительны, поэтому он никогда не пытается преобразовать неправильную дату.

Во втором примере добавление к предложению WHERE приводит к тому, что план запроса фактически преобразует все эти даты и находит неправильную, а затем просматривает имя атрибута.

В вашем третьем примере изменение использования Attribute_Id, вероятно, изменяет план запроса так, что он сначала ищет только те, у которых id = 15, а затем проверяет, имеют ли эти записи действительную дату, что они и делают. (Возможно, Attribute_Id индексируется, а Attribute_name нет)

Итак, у вас где-то плохое свидание, но его нет ни в одной записи с Arttribute_id = 15.

Вы можете проверить планы выполнения. Может случиться так, что при первом запросе второй критерий (CONVERT(DATETIME, pa.Attribute_Value) < GETDATE()) сначала оценивается по всем строкам, включая строки с недопустимыми данными (не с датой), а в случае второго - сначала оценивается a.Attribute_ID = 15. Таким образом, исключая строки со значениями, отличными от даты.

кстати, второй тоже может быть быстрее, и если у вас нет ничего из Attributes в списке выбора, вы можете избавиться от inner join Attributes a on a.Attribute_ID = pa.Attribute_ID.

На этой ноте, было бы желательно избавиться от EAV, пока еще не поздно :)