left join右表无匹配行会补null，inner join则丢弃整行；业务代码未做null检查将导致运行时错误，测试需覆盖右表为空场景并对null字段加断言，数值聚合空集返回null需coalesce处理，join后行数放大需通过count(distinct)验证。
JOIN空结果集时下游逻辑是否崩溃
LEFT JOIN右表无匹配行，会补NULL；INNER JOIN则直接丢掉整行。业务代码若没做NULL检查（比如直接取order.amount计算、或用status == 'paid'判断），运行时就抛错。这不是SQL问题，是调用方没兜住。
- 测试必须覆盖右表完全无数据的场景：清空关联表、或用
WHERE 1=0构造空子查询模拟 - 对所有可能为NULL的字段加断言：
SELECT COUNT(*) FROM result WHERE amount IS NULL应等于预期空匹配行数（比如LEFT JOIN中左表有100行、右表0匹配，则amount为NULL的行数应为100） - 特别注意数值聚合字段（如
SUM()）：空集合返回NULL而非0，下游若未用COALESCE(SUM(), 0)会中断
一对多导致的数据放大是否被察觉
JOIN后行数暴增，常被当成“查得全”，实则是重复。比如用户表100行，每人平均3个订单，users JOIN orders后变成300行——但若后续再GROUP BY users.id却忘了去重，COUNT(*)就会翻倍。
- 执行前先估算：查
SELECT COUNT(*) FROM users和SELECT COUNT(*) FROM orders，比值超过1.5就预警 - 执行后立刻验证：
SELECT COUNT(DISTINCT user_id) FROM (your_join_query)必须等于左表原始行数（对LEFT/INNER JOIN） - 避免在JOIN后直接
SELECT *导出——字段多、重复行多，容易掩盖放大问题；改用SELECT user_id, COUNT(*) AS order_cnt聚合后再查
边界时间点匹配是否漏行或多行
用BETWEEN或start_date 做时间区间JOIN时，边界值（如<code>'2026-07-01 00:00:00'）极易因时区、精度、闭开区间不一致而漏或重。
- 统一用开区间写法：
t1.event_time >= t2.start_date AND t1.event_time ，并确保<code>end_date语义为“失效时刻” - 测试三个关键时间点：
start_date、end_date - 1微秒、end_date——最后这个点必须不匹配 - 拉链表场景下，同一主键若存在版本重叠（ETL异常），
BETWEEN会返回多行；必须加QUALIFY ROW_NUMBER() OVER (PARTITION BY id ORDER BY start_date DESC) = 1或等效子查询去重
NULL值参与JOIN条件是否意外过滤
ON a.id = b.id中任一字段为NULL，该行直接不匹配——哪怕业务上希望它保留（如未知ID归为“其他”）。更隐蔽的是WHERE b.status = 'active'写在LEFT JOIN后，实际把左表没匹配到的行全干掉了。
- 右表过滤条件必须写进
ON子句：ON a.id = b.id AND b.status = 'active'，而非WHERE - 若需保留NULL匹配，显式处理：
ON (a.id = b.id OR (a.id IS NULL AND b.id IS NULL))，但需确认业务是否真允许NULL等价 - 测试时人工插入一行
id = NULL，看是否出现在结果中；若不应出现，确认ON条件里没有IS NULL类逻辑干扰索引选择
真正难测的不是语法通不通，而是“看起来跑通了，但某天凌晨三点数据源突然少传一条，整个报表就差17%”。边界测试要卡住那些不报错却悄悄错的点。
