> > H - What is the best way to link tables if foreign keys slow thinks down?
A JOIN merely needs an INDEX on one side or the other; it does not need a FOREIGN KEY. The cost of a FOREIGN KEY is the check on every INSERT -- a check to verify that there is an appropriate row in the other table.
QC...
Nearly as many inserts as hits -- hot a good "hit" ration.
Lots of prunes (costly). Every INSERT leads to removing (pruning) all entries in the QC for the table being INSERTed into.
NULL is an 'extra' possible value. In many (but not all) cases, you always have a value for a column, hence you don't need the possibility of NULL. Indexing, etc, has to do extra effort to compare for NULL as well as 'real' values.
Use NULL when you need it; otherwise make columns "NOT NULL". (In the big picture, this is only a minor issue.)
INSERT speed:
http://forums.mysql.com/read.php?24,603112,603214
In particular,
> innodb_buffer_pool_size should be about 70% of available RAM.
The 3 SELECTs and EXPLAINs you mention are about as efficient as they can be.
Are those typical queries? Or just the "slow" ones?