sql性能-从多个表中获取时的查询设计

Question

Ok, premise. Three tables, simple enough for this exercise:

table first:
id, name

table second:
id, firstId, secondName

table third
id, thirdName, secondId

I want to take all rows in third that have a foreignkey to a row in the second that have a relation to a certain "first" row id.

Typical sql:

select t.id, s.id as secondId, t.thirdName, s.secondName from third t 
inner join second s on t.secondId=s.id where s.firstId = X

So here is my question:

Would it be faster performance wise, to have a column in third instead that is a foreign key directly to first?

ie

table third:
id, secondId, firstId, name

So that i instead could make the query:

select t.id, s.id as secondId, t.thirdName, s.secondName from third t 
inner join second s on t.secondId=s.id where t.firstId = X 

There are no less joins since i need the data from "second" too, but i'd make the lookup on "firstId" from third rather than second.

Just curious if anybody has any input :)

Answer 1

Suppose the second way is faster, if you re-write your first query as:

select t.id, s.id as secondId, t.thirdName, s.secondName from second s
inner join third t on t.id=s.id where s.firstId = X

Note the swapped placements of second and third . With this you will see the exact same performance as your second example, but the third table will be smaller because it doesn't have the extra redundant field.

To point out the benefits of not having this field, it's easier to point out what adding an extra redundant field will do to performance:

• consume more disk space
• slow down any table scans because rows will now be slightly longer
• update performance will also be slightly slower
• among others...

While theoretical, it this overall sounds an awful lot like a premature optimization, you should only be doing this IF your existing query is slow (even when doing my above re-write of it), at which point you will get a much better bang for your buck by just improving your indexes.

Answer 2

The surest way to find out is to try it and see.

However, given that you need to join to the second table anyway, I would actually expect it to be a bit slower, since you would have to fetch all records from the table third first, and then link each of them to the appropriate record on second , rather than fetching the second records first and then linking to the third records - so you would be retrieving 2*m*n records in the first scenario, and only (m+1)*n records in the second.

Of course, if you didn't need to link to the second table, the query would run much faster if it only accessed the third table.

Answer 3

Your proposed design would be incorrect. There is nothing to guarantee that third.firstId matches the second.firstId of the parent row.

Correctness is more important than performance!

---

That said, you might be able to use identifying relationships and natural keys (as opposed to non-identifying relationships and surrogate keys):

This is appropriate if thirdName does not need to be unique on its own, but only in the context of the parent row from the second table, and secondName does not need to be unique on its own, but only in the context of the parent row from the first table.

In this scenario, you could avoid JOINs altogether and still get firstId , secondName and thirdName :

SELECT *
FROM third
WHERE firstId = X

Even if there are other fields, not shown above, that you need to read from second , the JOIN will still be faster because InnoDB clusters the data and you'd more naturally follow this clustering. And by avoiding surrogate keys, you'd avoid expensive secondary indexes (see "Disadvantages of clustering" in this article ).

The price you pay is in each successive child table growing progressively "fatter". Whether this is a price worth paying, only you can determine by performing measurements on representative amounts of data.