嵌套查询语义清晰利于评审快速定位逻辑缺陷，但需警惕MySQL 5.7子查询别名限制、IN与EXISTS对NULL处理差异、相关子查询导致的n+1性能问题，须在评审阶段确认版本兼容性、NULL过滤及执行代价。
嵌套查询的语义清晰度直接影响评审时能否快速定位逻辑缺陷
代码评审不是读完就过，而是要判断“这个查询是否真能表达业务意图”。嵌套查询一旦写成扁平化长 WHERE 或强行 JOIN，外层 WHERE 里混着聚合条件、排序限制、空值处理，评审者必须手动推演执行顺序才能确认逻辑是否正确。而语义清晰的嵌套结构，比如把 SELECT user_id FROM purchases WHERE product_id = '12345' 单独作为子查询，外层只用 IN (…) 做成员判断，评审时一眼就能看出“这是先找买过某商品的人”，无需反向解析条件耦合关系。
MySQL 5.7 及更早版本对子查询别名的限制常被忽略，导致评审通过但运行报错
在 FROM 子句中写 (SELECT …) AS t 后，如果外层又想引用 t 的字段做计算或过滤，MySQL 5.7 会直接报错：「Unknown column 't.id' in 'where clause'」。这不是语法错误，而是执行期解析失败。很多团队评审只看逻辑、不验版本兼容性，结果上线后触发 ERROR 1054。解决方法不是升级数据库，而是用 INNER JOIN (SELECT …) AS t ON 1=1 包一层——这个绕法必须在评审阶段就确认是否已加，否则测试环境跑得通，生产一查大表就崩。
EXISTS 和 IN 在语义上不等价，但评审时容易当成同义替换
用 WHERE id IN (SELECT id FROM t2 WHERE …) 和 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.id AND …) 看似都能实现“存在性判断”，但行为差异极大：IN 遇到子查询返回 NULL 时整行被过滤掉；EXISTS 不受 NULL 影响。如果子查询涉及左连接或可空字段，评审时若没盯住 NULL 处理逻辑，就可能漏掉数据一致性风险。实操建议：
- 优先用
EXISTS替代IN做关联存在性检查，语义更稳 - 若坚持用
IN，子查询末尾必须加AND col IS NOT NULL - 评审时直接搜
IN (SELECT，然后人工确认子查询是否可能返回NULL
相关子查询的性能陷阱藏在语义背后
SELECT name FROM employees e WHERE salary > (SELECT AVG(salary) FROM employees WHERE dept = e.dept) 这类相关子查询，表面看是“查高于本部门平均薪资的员工”，语义很直白。但实际执行时，子查询会为 e 的每一行重新执行一次，数据量大时极易拖垮响应。评审不能只说“逻辑对”，必须结合数据规模预判：如果 employees 有百万行，且部门数超千，这个查询大概率会超时。此时应改为窗口函数或提前物化部门均值——语义清晰反而容易让人放松对执行代价的警惕。
