September 16, 2010 at 12:55 am
Hi All,
I have around 200+ tables in database and all the tables have column with the name IsDeleted which is of datatype bit. And we are using this for logical deletion, ie; if an record deleted we are updating the value 1 for IsDeleted column
and while fetching we will select only the records with 0 in IsDeleted column and we are using this column in every select statement for each table .
Now my question is whether i have to create index on this column for all tables? If yes how the performance will be gained?
Thanks in Advance
September 16, 2010 at 1:27 am
An index just on that column will probably not be useful. What you'll likely need to do is create indexes for the various queries and ensure that the IsDeleted is part of each index.
If you can post a couple of example queries I can probably help you further.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 15, 2011 at 8:37 am
I've seen instances where an index on boolean field is useful. If there is a large discrepancy between the number of 0's and 1's, and you're searching for the the smaller of the two, an index may work well.
E.g.: If [font="Courier New"]IsDeleted[/font] is set to 1 during online processing and then all entries with IsDeleted=1 are deleted by a script that gets run during off-hours, I'd expect the total number of rows where [font="Courier New"]IsDeleted=1[/font] to be small. In this case, if your [font="Courier New"]WHERE[/font] clause filters on [font="Courier New"]IsDeleted=1[/font], you're likely to get seeks rather than scans. On the other hand, if your [font="Courier New"]WHERE[/font] clause filters on [font="Courier New"]IsDeleted=0[/font], it still has to look through the majority of rows that might otherwise be returned, so you'll get scans.
Like GilaMonster said, though, it's unlikely that an index on a boolean, all by itself, is going to help you in any significant way. It's possible that adding it to existing indexes might help.
February 15, 2011 at 9:32 am
i agree with shian. i've actually had instances where indexing on a bit field was extremely useful - though common wisdom suggests they may be more overhead than they are worth. test both with and without.
😎
February 15, 2011 at 10:44 am
In SQL 2008, a filtered index on one or another of the values in a bit column, can make a HUGE difference in performance.
In 2005 and earlier, just don't make it the leading edge of the index, and it should help, but not quite as much.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
December 31, 2015 at 8:09 am
[p]
Count yourself lucky when your indexing decisions can be based solely on a single column. Like most things in life, context creates more value than content.
[/p]
[p]
Consider the question "Is 300 horsepower good?" It will not put another man on the moon or move 12 railrailcars of freight. Give a Miata that much power and you'll end up with a lot of scrap metal; a Corvette, well...you'll want more.
[/p]
[p]
Do not create an index for the sake of having an index, understand how and why the index creates value, and be very wary of diminishing returns.
[/p]
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply