Table size where putting an index starts making sense

Question

I have a Calendar table with about 2K rows. This is a lookup table, and will be used in many joins.

The columns are

CalendarId (PK, Clustered)
DateTimeValue
IsWeekDay
IsWeekend
IsHoliday

My question is this: I want to have an index on DateTimeValue.

When should I create this index?

In other words, how big does a table have to be before you put an index on it?

Answer 1

You add the index as you create the table, before the first row is inserted. Indexing is part of the data model design, not some afterthought when the data start showing problems.

A missing index on an empty table is still a missing index.

Answer 2

You want to make sure that you have an index on things as you are needed, you don't want to "wait" until it becomes a problem....by that point you have wasted time.

But at the same time, don't create an index just for the sake of creating one, ensure that it makes sense for the application.

For example, depending on your operation, I am thinking you might be "more efficient" to cluster on the DateTimeValue, as I'm guessing you have 1 entry per day.

Answer 3

Always add the index to start. A table is never too small to have an index. An index only becomes a problem when you have a very large table, as inserts/updates/deletes can slow down.

Answer 4

I guess that "DateTimeValue" would be the natural key in this table? It should have a unique index from start.

Regarding the other fields, it is unlikely that indexes on IsWeekDay or IsWeekend will be used by the optimizer since they have low selectivity (IsWeekDay returns 71% of the rows).

Edit Also note that this is basically a read-only table. You can add whatever indexes you like as it will only ever affect write-performance once every few years when you add another years worth of data to it.