1

I'm working on a system backed up by a rather large SQL Server 2008 database, about 250 tables. After doing some performance optimization, I discovered that in many of the tables there were missing indexes on the foreign keys. After going through all the tables in more details, I identified about 150 foreign keys with potential missing indexes.

I know that it is generally good practice to put an index on every foreign key, and I also know that indexes aren't automatically created for foreign keys. I suspect that people not thinking about (or being aware of...) the latter is the reason why the database has ended up in its current condition.

But since I'm not even close to an expert on database optimization, I thought I'd fire away a control question before starting to add all those indexes:

Question:
Are there any special considerations to keep in mind when adding such a large number of indexes to an existing database?

The only thing I can think of myself, is that for every index you can get a potential performance penalty for inserts and updates. But for indexes strictly on foreign key columns, I picture that that's not a major problem. Also, our database isn't really insert/update intensive, another reason for that not being an issue.

I could perhaps also mention that we use NHibernate as our ORM layer, which I guess is yet another reason for having good indexes on foreign keys (since we're accessing lots of objects through foreign key properties).

Community
  • 1
  • 1
Julian
  • 20,008
  • 17
  • 77
  • 108

2 Answers2

3

I don't think there's anything special apart from the obvious points to consider:

  • More disk space required for the indexes
  • Performance impact, but this is something that should be measured rather than guessed (even a database that is insert/update intensive usually has more reads than writes; the engine has to find a row before it can be updated)
  • Extend your DDL generation and management process to ensure that all FK indexes are scripted by default from now on

If the constraints already exist and only the indexes are missing, then you don't have to worry about the biggest potential issue, which is invalid data that you need to review and fix. But I understand from your question that the FKs themselves are already there.

Pondlife
  • 15,992
  • 6
  • 37
  • 51
  • Thanks for the input. You're definitely right regarding improving our process around DDL generation and management. And yes, you are correct: the FKs themselves are already there, so luckily _that's_ not gonna be an issue. Will keep the question open for a while longer before accepting though, to see what other answers might come. – Julian Dec 07 '11 at 12:39
3

New plans (whilst hopefully faster due to the new indexes) might offer new opportunities for deadlocks to occur - where previously, all of the activity for a statement/transaction was only against the clustered index, it can now fulfil part of the query using a lock against a new index instead.

Just make sure you test with realistic data volumes and workloads.

Damien_The_Unbeliever
  • 234,701
  • 27
  • 340
  • 448