I have a table, 'ct' which has around 4 million rows in it.
I have a clustered index on one of the date columns, 'ct_date', inside this table.
I have a stored procedure I use to delete 'ct' entries from a particular date or todays date if non supplied.
Here is the sp.
Code:
create proc del_ct
@from_date datetime = '1/1/1900'
as
begin
declare @error int,
@deleted int
if @from_date = '1/1/1900'
begin
select @from_date = convert( char( 10 ), getdate(), 101 )
end
begin transaction
delete from ct where ct_date > @from_date
select @error = @@error, @deleted = @@rowcount
if @error = 0
begin
commit transaction
print "%1! trades deleted", @deleted
end
else
begin
print "Error %1!", @error
rollback transaction
end
end
go
For some reason the clustered index is not chosen when I examine the query plan. This is borne out by the fact that this sp takes ages to run, i.e. it is table scanning 4 million rows....
I modified it to this
Code:
create proc del_ct
@from_date datetime = '1/1/1900'
as
begin
declare @error int,
@deleted int,
@actual_date datetime
if @from_date = '1/1/1900'
begin
select @actual_date = convert( char( 10 ), getdate(), 101 )
end
else
begin
select @actual_date = @from_date
end
begin transaction
delete from ct where created_date > @actual_date
select @error = @@error, @deleted = @@rowcount
if @error = 0
begin
commit transaction
print "%1! trades deleted", @deleted
end
else
begin
print "Error %1!", @error
rollback transaction
end
end
go
And the clustered index is now being used...
Can anyone shed any light on this. It appears that the use of parameters, or the possible change of a parameter, precludes use of an index.
