子查询多表校验关键在“查什么”和“怎么比”：用NOT EXISTS防NULL陷阱，ABS容差处理浮点误差，JOIN替代相关子查询提升性能，派生表避免重复计算，执行前需EXPLAIN验证索引与执行计划。
子查询做多表校验，核心不是嵌套多深，而是“查什么”和“怎么比”——尤其当涉及 NULL、浮点精度、一对多关系时，直接写 IN 或 = 极易漏数据或报错。
WHERE 中用 EXISTS 校验外键存在性（防 NULL 陷阱）
用 IN 判断字段是否在另一张表中，遇到子查询返回 NULL 时整个条件变 UNKNOWN，该行直接被过滤，不是 bug，是 SQL 三值逻辑的必然行为。比如检查订单的 customer_id 是否真实存在于客户表：
- 别写：
WHERE customer_id IN (SELECT id FROM customers)—— 若customers.id有NULL，整条条件失效 - 改用：
WHERE NOT EXISTS (SELECT 1 FROM customers WHERE customers.id = orders.customer_id)，它只关心“有没有匹配行”，完全绕过NULL干扰 - 子查询里永远写
SELECT 1或主键，不写SELECT *，避免传输冗余字段、干扰优化器选择执行计划
聚合值跨表比对：SUM 对 SUM 要加 ABS 容差（防浮点误差）
核对明细表总金额和汇总表字段是否一致，不能直接 WHERE (SELECT SUM(...)) = (SELECT total_amount ...)，因为浮点数存储本身有精度损失，= 几乎必错。
- 正确做法是用
ABS(a - b) 判断，把容差设为业务可接受的最小单位（如分） - 如果明细表按天聚合、汇总表按日分区，子查询必须显式带上相同维度条件，例如都加
WHERE DATE(created_at) = '2024-06-01'，否则数据库可能做全表扫描再过滤 - 若 A 表是明细、B 表是汇总但未按相同粒度分组（比如 B 表没带
GROUP BY date），直接套子查询会引发隐式笛卡尔积，性能暴跌甚至 OOM
相关子查询性能崩了？立刻转 JOIN + 索引
像 WHERE amount > (SELECT MAX(amount) FROM sales s2 WHERE s2.product_id = s1.product_id) 这种写法，数据库会对 s1 每一行都执行一次子查询，N 行就是 N 次全表扫描——这就是相关子查询的典型性能黑洞。
- 等价改写为
LEFT JOIN (SELECT product_id, MAX(amount) AS max_amt FROM sales GROUP BY product_id) t ON t.product_id = s1.product_id WHERE s1.amount > t.max_amt - 确保
sales.product_id有索引，否则GROUP BY阶段就慢 - MySQL 5.7 及更早版本不支持子查询内用
ORDER BY ... LIMIT，这类写法在校验脚本里要提前规避，换成窗口函数或临时表
FROM 子句里的派生表校验：避免重复计算
当需要多次引用同一子查询结果（比如既要算明细总和，又要算去重用户数），别在多个地方重复写 (SELECT ...)，直接提成 FROM 子句里的派生表：
SELECT detail_sum, user_cnt, ABS(detail_sum - summary_sum) AS diff
FROM (
SELECT
(SELECT SUM(amount) FROM sales WHERE date = '2024-06-01') AS detail_sum,
(SELECT COUNT(DISTINCT user_id) FROM sales WHERE date = '2024-06-01') AS user_cnt,
(SELECT total_amount FROM daily_summary WHERE date = '2024-06-01') AS summary_sum
) t改成：
SELECT
s.detail_sum,
s.user_cnt,
ABS(s.detail_sum - d.total_amount) AS diff
FROM (
SELECT
SUM(amount) AS detail_sum,
COUNT(DISTINCT user_id) AS user_cnt
FROM sales
WHERE date = '2024-06-01'
) s
CROSS JOIN daily_summary d
WHERE d.date = '2024-06-01'后者只扫一遍 sales，前者可能扫三遍——尤其是没走索引时，差异会放大十倍以上。
最常被忽略的是：子查询的执行时机依赖数据库优化器，而优化器又高度依赖统计信息是否最新。校验类 SQL 在上线前务必在生产镜像环境跑 EXPLAIN，确认没走全表扫描，且关键字段都有索引覆盖。
