Can foreign keys hurt query performance

Question

As I understood from this post, there are some scenarios where foreign keys can improve query performance.

I\'ve heard the opposite claim though, that because of refere

Answer 1

I'm assuming that for INSERT queries, constraints - including foreign key constraints - will slow performance somewhat. The database has to check that whatever you've told it to insert is something that your constraints allow it to insert.

For SELECT queries, foreign key constraints shouldn't make any changes to performance.

Since INSERTS are almost always very quick, the small amount of extra time won't be noticeable, except in fringe cases. (Building a several gigabyte database, you might want to disable constraints and then re-enable later, as long as you're sure the data is good.)

Answer 2

if a foreign key is needed for referential integrity then the presence of the foreign key should form the baseline for performance

you might as well ask if a car can go faster if you don't put seats in - a well formed car includes seats as much as a well formed database includes foreign keys

Answer 3

If you're enforcing referential integrity, INSERTs, and UPDATEs that effect the FK field, will be slower. However, it's usually not much to worry about, especially as a lot of DBs are 80% read/20% write. It's also a price worth paying.

Creating an index on a foreign key is often beneficial, though obviously it how much depends on what SELECT statements you're running.

Generally, you need foreign keys due to normalisation (which avoids duplicate data and synchronisation problems). Normalise to the 3rd degree, and then after analysing real world performance can you consider de-normalising.

Answer 4

Foreign keys can cause inserts(or some updates) in child tables or deletes from parent tables to take longer. This is a good thing however as it means that it is making sure that the data integrity remains. There is no reason whatsoever to skip using foriegn keys unless you don't want to have useful data. You wil not normally notice much differnce unless you have many foreign keys realted to the same parent table or if you are inserting or deleting many records in one batch. Further, I have noticed, users are more tolerant of a couple of extra seconds in an insert or delete than they are in a select. Users are also not tolerant at all of unreliable data which is what you have without foreign key constraints.

You will need to index them to improve performance on select queries.

Answer 5

For INSERT/UPDATE/DELETE the short answer is, "Yes". The database will need to check that the referential integrity is intact and the creation/modification is allowed. Or in DELETE's case, there may be some cascading to be done.

For SELECTs, it's actually quite the contrary. Foreign Keys have a secret added benefit of showing you exactly where you're most likely to be doing complex JOINs and have very commonly used fields. This makes the job of indexing much easier, and you can pretty much guarantee that all of your FK fields should be indexed. This makes SELECTs much faster.

Answer 6

Foreign key checking takes more time than most people think. A current test with Oracle 11g and a table with two foreign keys showed that the time for an insert of about 800.000 rows took 60 seconds with enabled foreign keys but only 20 seconds without foreign keys. (The foreign key columns were indexed, of course)

Anyway, I agree with all the other posters, that integrity constraints are not an option, but the only way to keep data consistent. However, for imports, especially into empty tables, it could be an option to disable the foreign key for the time of the import, if time is critical.