Пусть у нас есть таблица платежей, имеющая 35 столбцов с первичным ключом (autoinc bigint )и 3 не -кластерных, не -уникальных индексов (каждый по одному столбцу int ).
Среди столбцов таблицы есть два поля datetime:
платеж _датаdatetime NOT NULL
изменить _датуdatetime NULL
В таблице около 1 200 000 строк. Только ~1000 строк имеют столбец даты редактирования _= null. 9000 строк имеют дату редактирования _не нуль и не равной дате платежа _У других правка _дата=платеж _дата
Когда мы запускаем следующий запрос 1:
select top 1 *
from payments
where edit_date is not null and (payment_date=edit_date or payment_date<>edit_date)
order by payment_date desc
серверу требуется пара секунд, чтобы сделать это.Но если мы запустим запрос 2:
select top 1 *
from payments
where edit_date is not null
order by payment_date desc
выполнение завершается с Файл журнала для базы данных «tempdb» заполнен. Создайте резервную копию журнала транзакций для базы данных, чтобы освободить место в журнале.
Если мы заменим *на какой-то определенный столбец, см. запрос 3
select top 1 payment_date
from payments
where edit_date is not null
order by payment_date desc
он также заканчивается через пару секунд.
Где магия?
РЕДАКТИРОВАТЬ Я изменил запрос 1, чтобы он работал с тем же количеством строк, что и второй запрос. И все равно через секунду возвращается, а запрос 2 заполняет tempdb.
ОТВЕТ Я последовал совету добавить индекс, сделал это для обоих полей даты -все заработало быстро, как и ожидалось. Тем не менее, вопрос был -, почему именно в этой конкретной ситуации сервер sql ведет себя по-разному при похожих запросах (запрос 1 и запрос 2 ); Я хотел понять логику оптимизации сервера. Я бы согласился, если бы оба запроса одинаково использовали базу данных tempdb, но это не так....
В итоге отмечаю как ответ первый, где я увидел должны -быть симптомы моей проблемы а так же первые мысли как этого избежать (т.е. индексы)