SQL Server Indexing Strategy -
i'm building web application using sql server 2008 , having difficulty coming best indexing strategy given our use-case. example, of tables structured similar following:
create table jobs ( id int identity(0, 1) not null, cmpyid int not null default (0), statusid int not null default (0), name nvarchar(100) null, isdeleted bit not null default (0), constraint [pk_dbo.jobs] primary key nonclustered (id asc)) create clustered index ix_jobs_cmpyidandid on jobs (cmpyid, id) create index ix_jobs_cmpyidandstatusid on jobs (cmpyid, statusid) in our application, users separated different companies results in queries looking similar following:
select * jobs cmpyid = @cmpyid , ... additionally, jobs accessed statusid (canceled = -1, pending = 0, open = 1, assigned = 2, closed = 3), similar following:
select * jobs cmpyid = @cmpyid , statusid >= 0 , statusid < 3 would better off using composite clustered index shown above, or should use default clustered index on id field , create separate index cmpyid?
for statusid column, correct in assuming filtered index way go?
i'm considering partitioning table cmpyid or statusid, not sure best (or if no partition best).
this kinda premature optimization. can spend lot of time worrying 1 net faster database, when live in production, when have best chance of optimizing indexes.
sql server has traces see queries being ran , taking longest. can test out different indexing strategies when live in production no risk. @ worst can slow application down.
i typically setup clustered indexes on primary key. , non clustered on important columns. works jvm stack used sql server. don't know bottle necks going without having data see it.
Comments
Post a Comment