多条件查询需求：获取指定比赛日赛事及指定用户投注记录

现有表结构包含：

• match表：存储赛事信息，包含matchId、matchday等核心字段
• bet表：存储用户投注记录，通过matchId关联赛事、userId关联用户，包含投注相关字段
• user表：存储用户基础信息，包含userId等字段

需求：获取某一指定matchday的全部赛事，同时关联显示某一指定userId用户对这些赛事的投注记录（需排除其他用户的投注数据）。

此前使用如下查询语句：

SELECT * FROM match
JOIN bet ON match.matchId = bet.matchId
JOIN user ON bet.userId = user.userId
WHERE match.matchday = 1 AND user.userId = 1

仅能返回既有指定matchday又有该用户投注的赛事，缺少该用户未投注的赛事。期望结果为：指定matchday的所有赛事都被完整列出，该用户有投注的赛事显示对应的投注信息，未投注的赛事对应的投注字段填充为NULL，不会被过滤。

使用**左连接（LEFT JOIN）**实现，将match表作为主表，把userId的过滤条件放在连接逻辑中而非WHERE子句，就能保留所有指定matchday的赛事：

SELECT m.*, b.*
FROM `match` m
LEFT JOIN bet b ON m.matchId = b.matchId AND b.userId = 1
WHERE m.matchday = 1;

如果需要关联用户表信息，由于已经指定了固定userId，可以直接左连接并添加对应条件，或者单独查询该用户的固定信息即可，避免冗余关联。

• 单SQL查询方案：这种方式是合理的，数据库层面的关联查询效率通常比应用层多次请求拼接更高，尤其是数据量较大时，能减少网络IO和应用层的处理逻辑，同时保证数据一致性（避免两次请求之间数据发生变更）。
• 应用层处理方案：如果业务逻辑复杂，或者后续需要对数据做大量个性化处理，也可以分两次请求：先获取指定matchday的所有赛事，再获取该用户在这些赛事上的投注记录，最后在应用层完成数据关联。但这种方式会增加一次数据库请求，且需要额外处理数据关联逻辑，仅适合数据量较小或业务场景特殊的情况。

一般推荐优先使用数据库左连接的方式实现，更高效简洁。

内容的提问来源于stack exchange，提问作者Vasil Emilov