Почему SQL оптимизатор так поступает?

Kon
Новичок
Posts: 84
Joined: 24 Jul 2002 20:42
Location: Chicago

Почему SQL оптимизатор так поступает?

Post by Kon »

Имеем процедуру которая обращается к таблице (student) находящейся в другой базе (testdb). Student содержит 12 миллионов records и не имеет полезного индекса.


create proc dbo.proc1
@id int,
@firstname varchar(50),
@lastname varchar(50)
as
select top 1 id from testdb.dbo.student where id=@id and firstname=@firstname and lastname=@lastname
go

Execution time: 8 sec.

Один девелопер додумался зачем то написать другую процедуру:

create proc dbo.proc2
@id int,
@firstname varchar(50),
@lastname varchar(50)
as
declare @kaka table ( id int, firstname varchar (50), lastname varchar (50))
insert @kaka values (@id, @firstname, @lastname)

select top 1 student.id from testdb.dbo.student student join @kaka kaka on
student.id=kaka.id and student.firstname=kaka.firstname and student.lastname=kaka.lastname
go

Execution time: 2 sec

Почему такая разница во времени? По идее создание temp table наоборот должно увеличить время.
Когда я смотрю в Profiler, то вижу SP:CacheMiss когда гоняется proc1.
User avatar
Dmitry67
Уже с Приветом
Posts: 28294
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

Post by Dmitry67 »

1. Вы каждую процедуру запускали два раза подряд и писали время второго выполнения ?

2. А что Вы вообще имеете ввиду когда делаете top 1 не указав order by ?
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
Kon
Новичок
Posts: 84
Joined: 24 Jul 2002 20:42
Location: Chicago

Post by Kon »

Каждая из процедур запускалась и по несколько раз, и с dbcc freeproccache.

На время это влияло незначительно.

top 1 использовалось для того что бы определить существование в таблице.
можно конечно же было добавить if exists, но вопрос сейчас не в этом.
User avatar
Dmitry67
Уже с Приветом
Posts: 28294
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

Post by Dmitry67 »

А у меня наоборот второй запрос дольше
Потому что он использует hash join, тогда как тупой запрос просто фильтрует

А почему индекс не создать ?
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
Kon
Новичок
Posts: 84
Joined: 24 Jul 2002 20:42
Location: Chicago

Post by Kon »

трогать testdb я не имею права вообще, разрешены только selects.

Когда ко мне пришли с этим вопросом я тоже сразу сказал не тестируя что proc1 конечно же быстрее чем hash join.

На этом сервере у меня не хватает памяти, cache hit ratio 60%. Разделена ли cache на к примеру cache для joins и cache для простых selects?
User avatar
YellowMan
Уже с Приветом
Posts: 1099
Joined: 30 Sep 1999 09:01
Location: Bryansk,RUSSIA >> Dublin, Ireland

Post by YellowMan »

А индексов там на сервере точно нет ? Проверьте еще раз. А там во второй процедуре обычный или remote join ? В смысле хинт ?
Удачи@С.Смирнов

Return to “Вопросы и новости IT”