如何通过单条SQL查询获取指定客户及其推荐人的订单记录并解决ID冲突问题

当然可以实现这个需求，而且能完美解决你提到的ID冲突隐患。我们先分析你现有SQL的问题，再给出两种可行的方案：

问题根源 #

你的原始SQL用UNION把客户ID和推荐人ID合并成一个集合，这会导致两个核心问题：

1. 无法区分订单的接收方是客户还是推荐人（虽然你的需求暂时不需要这个信息，但更关键的是第二个问题）
2. 未来客户ID和推荐人ID数值重叠时，会错误地把不属于目标客户/推荐人的订单包含进来——因为只匹配ID数值，不验证ID所属的实体类型。

方案1：无需修改表结构的查询（推荐当前使用） #

我们可以直接通过明确的条件判断来区分两种订单，不需要混合同一ID空间的数值：

SELECT o.*
FROM orders o
WHERE 
  -- 条件1：订单的接收方是目标客户本人
  o.receiver_client_id = '15032'
  OR
  -- 条件2：订单的接收方是目标客户名下的推荐人
  o.receiver_client_id IN (
    SELECT r.id 
    FROM referrals r 
    WHERE r.client_id = '15032'
  );

这个查询的逻辑非常清晰：

• 第一部分直接筛选客户自己的订单
• 第二部分通过子查询找到该客户所有推荐人的ID，再筛选这些推荐人作为接收方的订单

即使未来客户ID增长到和现有推荐人ID重复（比如客户ID变成7809123），也不会出错——因为子查询只会返回属于目标客户的推荐人ID，其他同名ID不会被包含进来。

如果你偏好使用JOIN写法，也可以这样写（效果完全一致）：

SELECT DISTINCT o.*
FROM orders o
LEFT JOIN referrals r 
  ON o.receiver_client_id = r.id
WHERE 
  o.receiver_client_id = '15032'
  OR r.client_id = '15032';

加DISTINCT是为了极端情况的保险（比如某个ID同时存在于客户和推荐人表，且恰好属于目标客户，但实际业务中这种情况应该不会发生）。

方案2：长期优化方案（修改表结构） #

从数据模型的健壮性来说，最好的解决办法是给Orders表增加一个receiver_type字段（比如枚举类型，可选值为CLIENT和REFERRAL），用来明确标记receiver_client_id对应的实体类型。

修改表结构后，查询会更清晰，也彻底杜绝了ID冲突的隐患：

SELECT o.*
FROM orders o
LEFT JOIN referrals r 
  ON o.receiver_client_id = r.id 
  AND o.receiver_type = 'REFERRAL'
WHERE 
  -- 客户本人的订单
  (o.receiver_type = 'CLIENT' AND o.receiver_client_id = '15032')
  -- 客户名下推荐人的订单
  OR (o.receiver_type = 'REFERRAL' AND r.client_id = '15032');

这个方案虽然需要修改表结构，但能让数据模型更严谨，避免未来出现更多类似的问题。

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