Если вы не разобрались в тонкостях работы базы данных, то использование новых средств языка T-SQL может привести к неожиданным результатам в плане производительности.
Я уже писал о том, как подходить к работе с датами в WHERE: Where To Do Date Math In Your Where Clause.
Но оказалось, что все то же самое справедливо для обработки часовых поясов.
Для начала создадим индекс:
CREATE INDEX c ON dbo.Comments(CreationDate);
Теперь представим, что нам нужно сделать запрос к таблице Comments с учетом часового пояса:
DECLARE @d datetime = '20131201';
SELECT
COUNT_BIG(*) AS records
FROM dbo.Comments AS c
WHERE c.CreationDate AT TIME ZONE 'UTC+12' >= @d
OPTION(RECOMPILE);
GO
Ждать мы будем долго. Я полагаю, что минута для вас — это долго. Для меня это так, потому что каждая минута ожидания — это время, когда я не занимаюсь чем-то более полезным.

Мы написали плохой запрос. Проблема здесь в том, что мы пытаемся преобразовать значение в каждой строке таблицы в новый часовой пояс, а затем сравнить со значением, которое мы могли бы очень легко вычислить один раз и сравнить с CreationDate
.
DECLARE @d datetime = '20131201';
SELECT
COUNT_BIG(*) AS records
FROM dbo.Comments AS c
WHERE c.CreationDate >= DATEADD(HOUR, 1, @d) AT TIME ZONE 'UTC-11'
OPTION(RECOMPILE);
GO
Теперь запрос выполняется гораздо быстрее.

Кто-то может сказать, что мы обманули время, если посмотреть, насколько быстрее все стало работать, даже без помощи параллелизма.
На эту тему есть довольно много постов не так ли? Но важно помнить — вопрос не в том, что в условии находится слева, а что справа. Главное — что мы вычисляем:
Если данные (то, что мы храним физически) — их преобразование превращается в цирк.
Если значение (то, что мы вычисляем один раз через параметр, переменную или иным способом) — это гораздо меньшая нагрузка.
Завтра состоится открытое занятие, на котором поговорим о том, что нового появилось в SQL Server 2022. Обсудим, как новые фичи упростят жизнь разработчикам и DBA. Регистрация открыта по ссылке для всех желающих.