主查询使用LIMIT是否影响子查询？执行次数与性能咨询

嘿，这个问题问到点子上了——尤其是当表数据量很大时，不同的查询写法性能差异会非常显著！

子查询的执行逻辑 #

你的子查询是关联子查询（因为它引用了主查询中的River.id），它的执行流程是这样的：

1. 主查询先筛选出所有user_id IN (1,2,3)的River记录；
2. 对筛选后的结果集应用LIMIT 10，只保留前10条数据；
3. 仅针对这10条记录，每条执行一次子查询，计算对应的likeCounts。

简单说：它不会对River表的每一行都执行子查询，只会对最终返回的10条数据执行。

性能更优的查询写法 #

虽然当前写法在LIMIT 10时性能不会太差，但如果后续调整LIMIT值，或者riverLikes表数据量极大，关联子查询的多次调用还是会有性能损耗。推荐用JOIN + 预聚合的方式，只需要扫描一次riverLikes表就能完成统计：

SELECT r.*, COALESCE(l.likeCounts, 0) AS likeCounts
FROM River r
LEFT JOIN (
    -- 先预聚合所有河流的点赞数，只执行一次
    SELECT river_id, COUNT(id) AS likeCounts
    FROM riverLikes
    GROUP BY river_id
) l ON r.id = l.river_id
WHERE r.user_id IN (1,2,3)
LIMIT 10;

为什么这个写法更好？

• 预聚合子查询只需要扫描riverLikes表一次，把所有河流的点赞数统计出来，而不是每条目标河流单独查询一次；
• 使用LEFT JOIN可以保留所有符合条件的River记录，哪怕这条河流没有点赞；
• COALESCE(l.likeCounts, 0)是为了把没有点赞的河流的likeCounts显示为0，而不是NULL，更符合业务逻辑。

额外的性能优化建议 #

为了让查询速度再上一个台阶，建议添加以下索引：

• 给River.user_id创建索引：加速主查询的筛选过程；
• 给riverLikes.river_id创建索引：加速预聚合子查询的分组统计。

内容的提问来源于stack exchange，提问作者Hamid Salari