Comments on: Database indexes are your friend

By: Ray

Ray — Tue, 31 Aug 2010 08:40:28 +0000

There is a simple reason why foreign keys should not get the index built automatically – they aren’t unique (usually). Imagine if there are only few possible values for the foreign key and one of them is used 90% of time on multi-million table. The index not only won’t improve the search, it will also create an overhead.

By: Arnis L.

Arnis L. — Sat, 28 Aug 2010 08:58:25 +0000

I’ve been there too. Only I had little experience back then and it took awhile to figure it out. Query that couldn’t finish in minutes started to work in milliseconds.

By: Bill R.

Bill R. — Sat, 28 Aug 2010 01:16:32 +0000

One can in fact imagine a scenario in which a foreign key might exist but no query will ever be executed against the table either selecting or sorting by that foreign key, thus excusing its absence.

However, not to do so begs so many questions balanced ONLY against the “cost” or “storage” of building that index that one has to wonder about whether the database engine has been updated in any meaningful way since the 1980′s, when disk storage was thousands of dollars per Megabyte.

Today, a 5 Terabyte RAID DASD server can be had for < $1,000. You have to be lazy, ignorant, severely thick-headed, or have some incredibly esoteric reason NOT to build the obvious indexes on a table.

By: Noel

Noel — Fri, 27 Aug 2010 13:50:48 +0000

In SQL Server , by default the primary key is created as the clustered index. It doesn’t have to be however and you can cluster by any field you like, even non-unique fields. You can take advantage of this if you are often doing scans on a foreign key (ie all order items for an order). You can cluster dbo.OrderItem on [OrderItem].[OrderID] to keep all the order items together which will optimise this particular lookup.

By: Diego F.

Diego F. — Fri, 27 Aug 2010 13:29:50 +0000

“I mean, a primary key is a clustered index, why wouldn’t a foreign key also create an index?”

Simply because they serve different purposes. A primary key defines the identity of a row, so it’s very likely it’ll be used for searches, updates and deletes.

Foreign key is a normal field with a constraint that creates a reference to a foreign primary key. The foreign primary key is indexed. So if you have a select of A inner join B you will be searching B’s primary key for the value of the foreign key. Why would you need to search A? You don’t, by default.

Indexes are costly, use it carefuly, they will become your enemies very fast if you don’t use it wisely.

By: Steve

Steve — Fri, 27 Aug 2010 13:25:56 +0000

Paul,

Even on a foreign key? I mean, I believe in YAGNI as much as the next guy, but key’s should in all but the most extreme situation be indexed.

By: Paul S

Paul S — Fri, 27 Aug 2010 07:30:38 +0000

Despite your bad experience here, I believe this is still the right way to go about doing things: Indexes should be added only when it’s observed that they are needed. Adding them before is just premature optimisation.

Good post, thanks.