In many cases, there are more than one way to join two tables; See the other answers for lots of examples. Of course, one could say that it would be an error to use the 'automatic join' in those cases. Then only a handfull of simple cases where it can be used would be left.
However, there is a severe drawback! Queries that are correct today, might become an error tomorrow just by adding a second FK to the same table!
Let me say that again: by adding columns, queries that do not use those columns could turn from 'correct' into 'error'!
That is such a maintenance nightmare, that any sane style guide would prohibit to use this feature. Most already prohibit select *
for the same reason!
All this would be acceptable, if performance would be enhanced. However, that's not the case.
Summarizing, this feature could be used in only a limited set of simple cases, does not increase performance, and most style guides would prohibit its usage anyway.
Therefor it is not supprising that most database vendors choose to spend their time on more important things.
Very quick answer: MyISAM
does not support FOREIGN KEY
s at all... Any FOREIGN KEY
you define on a MYISAM
table is silenty thrown away.
When you later switch to InnoDB
(i.e. ALTER TABLE my_table ENGINE=InnoDB
) the FOREIGN KEY
is not there either; it was thrown away when the table used to be MyISAM
.
Best Answer
I might be wrong, but I don't think that the MySQL optimizer takes foreign keys into consideration. An index, on the other hand, may be very useful as a support for a foreign key.
However, the main purpose of a foreign key is completely different than what you are asking for. The purpose is to keep the database consistent and maintain referential integrity. When deciding for or against foreign keys, I think this what you should be concidering.