No indexes on small tables?

Question

\"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.\" (Donald Knuth). My SQL tables are unlikely to conta

Answer 1

As a general rule of thumb, it's good to avoid smaller indexes as they typically won't be used.

But sometimes they can provide a huge boost as I outlined here.

Answer 2

Even if you have an index, SQL Server might not even use it, depending on the statistics for that table. And if you plan to put in an index for a report that will run at most a couple times a year, bear in mind that the INSERT/UPDATE penalties for adding the index will be in effect ALL THE TIME. Before adding an index, ask yourself if it is worth the performance penalty.

Answer 3

You have to understand that based upon the query two lookups may be done, one into the index to get the pointer to the row, the next to the row itself. If the data that is being queried is in the index columns that extra step may not be necessary.

It is entirely possible that double dipping for data may be slower even if the optimizer goes after the index. Whether or not we care is up to application profiling and eventual explain plans.

Answer 4

Primary key columns will be indexed for the unique constraint. I would still index all foreign key columns. The optimizer can choose to ignore your index if it is irrelevant.

If you only have a little bit of data then the extra cost for insert/update should not be significant either.

Answer 5

I suggest that you follow the usual rules about indexing, which approximately means "create indexes on those columns that you use in your queries".

This might sound unnecessary with such a small database. As others have already said: as long as your database stays as small as you have described, the queries will be fast enough anyway, and the indexes aren't really needed. They can even slow down insertions and updates, but unless you have very specific requirements there, it doesn't matter with such a small database.

But, if the database grows (which databases sometimes have a tendency to do) you don't have to remember to add indexes to that old database that you've probably forgotten about by then. Maybe it has even been installed at one your customers, and you can't modify it!

I guess what I'm saying is this: indexes should be such a natural part of your database design, that it is the lack of indexes that is the optimization, premature or not.

Answer 6

Indexes are often created implicitly when using UNIQUE constraints. I wouldn't try to avoid their use in that case!