Mysql Correlated Subquery vs Join performance - mysql

Question

I've always thought that Joins were faster than Subqueries. However for a very simple query in a small dataset the Join is returning in 1.0s whereas the Correlated-Subquery returns in 0.001s. Seems like something is wrong. I note that both queries are using the correct (appallingly named) indexes. Over 1 sec seems excessive for the Join. Any ideas?
Please compare these two queries with their Explain plans:
a) Using a Join
select user.id, user.username,
count(distinct bet_placed.id) as bets_placed,
count(distinct bet_won.id) as bets_won,
count(distinct bets_involved.id) as bets_involved
from user
left join bet as bet_placed on bet_placed.user_placed = user.id
left join bet as bet_won on bet_won.user_won = user.id
left join bet_accepters as bets_involved on bets_involved.user = user.id
group by user.id
Explain plan:
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE user index PRIMARY PRIMARY 4 NULL 86 100.00 NULL
1 SIMPLE bet_placed ref fk_bet_user1_idx fk_bet_user1_idx 4 xxx.user.id 6 100.00 "Using index"
1 SIMPLE bet_won ref user_won_idx user_won_idx 5 xxx.user.id 8 100.00 "Using index"
1 SIMPLE bets_involved ref FK_user_idx FK_user_idx 4 xxx.user.id 8 100.00 "Using index"
Average response time: 1.0 secs
b) Using a Correlated-Subquery
select user.id, user.username,
(select COALESCE(count(bet.id), 0) from bet where bet.user_placed = user.id) as bets_placed,
(select COALESCE(count(bet.id), 0) from bet where bet.user_won = user.id) as bets_won,
(select COALESCE(count(bet_accepters.id), 0) from bet_accepters where bet_accepters.user = user.id) as bets_involved
from user;
Explain plan:
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY user ALL NULL NULL NULL NULL 86 100.00 NULL
4 "DEPENDENT SUBQUERY" bet_accepters ref FK_user_idx FK_user_idx 4 xxx.user.id 8 100.00 "Using index"
3 "DEPENDENT SUBQUERY" bet ref user_won_idx user_won_idx 5 xxx.user.id 8 100.00 "Using index"
2 "DEPENDENT SUBQUERY" bet ref fk_bet_user1_idx fk_bet_user1_idx 4 xxx.user.id 6 100.00 "Using index"
Average response time: 0.001 secs

Answer 1

Please see
which shows a comparison in speed/rows for different types of query.
It may be that there is little/no difference (either way) on 'smaller' datasets (but may ary on way the db has been set up, as well as the DBMS used), but as you can see,
However, in relation to other 'query types', these are much faster than other operations (shown below):
Subquery vs. Join
Both the subquery and join solutions perform reasonably well when very
small partitions are involved (up to several hundred rows per
partition). As partition size grows, the performance of these
solutions degrades in a quadratic (N2) manner, becoming quite poor.
But as long as the partitions are small, performance degradation
caused by an increase in number of partitions is linear. One factor
that might affect your choice between using a subquery-based or
join-based solution is the number of aggregates requested. As I
discussed, the subquery-based approach requires a separate scan of the
data for each aggregate, whereas the join-based approach doesn’t—so
you’ll most likely want to use the join approach when you need to
calculate multiple aggregates.
~SOURCE