Ironically, I have seen mysql installs up to at least 2012 produce faster results for multiple round trips than trying to get them to do the same thing using a JOIN.
Certainly I've seen code where
SELECT x.*, y.* FROM x LEFT JOIN y ON y.x_id = x.id
was actually slower than
SELECT x.* FROM x
then collecting the x.id values on the client side and running
SELECT y.* FROM y WHERE y.x_id IN (<list of x.id values>)
then putting the two sets of results together with a for loop.
(and all the y rows were per-x, this isn't about getting fewer results, just about query planning fun and mysql being -extremely- good at selecting things by a specific unique key but less so at anything even slightly more complicated - in some cases using a semantically pointless subselect in FROM to force the initial results to be materialised as a temp table worked out rather well too)
So far as I'm aware this has long since ceased to be an issue, but the world of performance optimisation can be a fun place sometimes.
The lesson here is learn about SQL and the database separately from the way you're using it--I'm looking at you ActiveRecord. These are not the same things.
Why bother with "SQL" and "databases" etc anyway? that's no route to performant code! Make yourself a kernel module that keeps this data in hash tables and only ever passes the "OK" connections up the stack to an application anyway.
"Cluster" you say? no problem! just use DHTs! that's a solved porblem and there's libraries and everything
...not only can displaying one's ignorance be fun, but there's a chance others might learn from it. So "dumpster fire" might be appropriate for the original discussion, but hey, maybe we can hope for some enlightenment to result.
Enlightenment, not sure. More like, take the time to read the whole article before jumping into the discussion, don't assume that you are the only one that just reads the headline and skims the first few paragraphs (obviously not you you).
Sufficiently many come mostly for adding and reading comments, the article is just an arbitrary starting point, it would seem.
Certainly I've seen code where
was actually slower than then collecting the x.id values on the client side and running then putting the two sets of results together with a for loop.(and all the y rows were per-x, this isn't about getting fewer results, just about query planning fun and mysql being -extremely- good at selecting things by a specific unique key but less so at anything even slightly more complicated - in some cases using a semantically pointless subselect in FROM to force the initial results to be materialised as a temp table worked out rather well too)
So far as I'm aware this has long since ceased to be an issue, but the world of performance optimisation can be a fun place sometimes.