Запрос умирает при сравнении двух дат

22 Февраля 2012 Программирование
10 0

Писал запрос для банковской базы с классическими транзакциями кредита – дебита. Прибыл кредит, его можно потратить. Дебитовая транзакция связывается с кредитовой, чтобы было видно, какая кредитовая транзакция была потрачена. Запрос выглядит примерно так:

select credit.TxnID, credit.Expiry, debit.Transacted, debit.Amount
from credit
   inner join creditdebit on . . .
   inner join debit on . . .
where debit.Transacred > '2012.01.01' 
   and debit.Transacted < ''2012.01.02

Это образная копия того запроса, над которым я работал. Все имена таблиц изменены, но смысл примерно сохранен. Смысл в том, что запрос возвращает две даты – дата Expiry для кредитной транзакции и дата, когда были потрачены деньги. Все это выбирается за один день и запрос выполняется одну секунду и возвращал 50 строк.

И тут я решил сделать одно дополнительное условие:

select credit.TxnID, credit.Expiry, debit.Transacted, debit.Amount
from credit
   inner join creditdebit on . . .
   inner join debit on . . .
where debit.Transacred > '2012.01.01' 
   and debit.Transacted < ''2012.01.02
   and credit.Expiry < debit.Transacted

Я добавил всего одну дополнительную проверку credit.Expiry < debit.Transacted на поля, которые уже были в результате запроса, они выбирались без проблем, потому что были в индексе. Но это небольшое условие убило запрос наповал. Я ждал 10 минут, когда он завершит выполнение, но безуспешно. Вот честно, не понял логики SQL Server, а точнее его оптимизатора запросов.

Я пробился над этим запросом весь день, пытался делать вложенные запросы типа:

seelct * from
(
select credit.TxnID, credit.Expiry, debit.Transacted, debit.Amount
from credit
   inner join creditdebit on . . .
   inner join debit on . . .
where debit.Transacred > '2012.01.01' 
   and debit.Transacted < ''2012.01.02
) ttt
where ttt.Expiry < ttt.Transacted

Но SQL Server все равно выбирал какой-то идиотский план выполнения и запрос умирал. Единственный выход, который я нашел – выбирать все данные во временную таблицу, а потом уже выбирать из временной таблицы данные, где Expiry < Transacted. Только такой вариант выполнялся одну секунду.

Никогда с подобным не сталкивался. Если SQL Server выбирал где0то неправильный план выполнения, то просто перестраиваешь запрос, делаешь какое-то изменение, чтобы сервер понял, что он идиот и всегда работало. Но тут я просто сдался.

К чему я это? Я просто ненавижу временные таблицы и считаю их злом. Они приносят реальную пользу очень и очень редко.

Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым