关联子查询是依赖外部查询列、逐行执行的子查询，普通子查询只执行一次；核心区别在于是否引用外部表字段并动态重算，如用workstation_id关联获取各工位标准产能计算效率。
什么是关联子查询，它和普通子查询有什么区别？
关联子查询的核心在于「对外部查询的依赖」——子查询里必须引用外部查询的某列（比如 workstation_id），每次外部行扫描时都会重新执行一次子查询。普通子查询只执行一次，结果被缓存复用；而关联子查询是逐行计算，天然适合「为每条记录算一个动态指标」这类场景，比如每个工位各自的效率。
常见错误是漏写关联条件，导致子查询变成独立执行，结果全一样或报错：ERROR: column "t1.workstation_id" does not exist。必须确保子查询的 WHERE 中明确写出类似 t2.workstation_id = t1.workstation_id 的等值关联。
怎么写一个计算单个工位效率的关联子查询？
假设你有两张表：production_log（记录每班次产量、工时）和 workstation_specs（记录各工位标准产能/小时）。效率 = 实际产出 ÷（标准产能 × 实际工时）。关键是要让子查询按当前工位取对应的标准产能。
- 子查询必须返回单值，否则会报错
subquery must return only one column或more than one row returned - 用
(SELECT standard_output_per_hour FROM workstation_specs WHERE workstation_id = t1.workstation_id)获取本工位标准值 - 外部查询的别名（如
t1）必须在子查询中可访问，不能在子查询里再用t1别名去查别的表 - 如果某工位在
workstation_specs中缺失，子查询返回NULL，整行效率也为NULL；加COALESCE(..., 0)可兜底
SELECT
t1.workstation_id,
t1.shift_date,
t1.actual_output,
t1.actual_hours,
t1.actual_output / (
(SELECT COALESCE(standard_output_per_hour, 0)
FROM workstation_specs
WHERE workstation_id = t1.workstation_id) * t1.actual_hours
) AS efficiency_ratio
FROM production_log t1;为什么效率值异常偏高或为 Infinity？
绝大多数是分母为零或空值导致。关联子查询返回 NULL（比如标准产能没填）、actual_hours 为 0、或者两者同时为 0，都会让除法失效。
-
actual_hours = 0时，即使标准产能存在，也会得到division by zero错误（PostgreSQL）或NULL（MySQL 默认行为） - 用
NULLIF(t1.actual_hours, 0)把 0 转成NULL，再配合COALESCE避免报错 - 标准产能字段类型要是数值型，别用字符串存数字（如
'5.2'），否则子查询可能隐式转换失败或返回空 - 检查
workstation_specs表是否有重复workstation_id—— 关联子查询若返回多行，直接报错
性能差、查询卡住怎么办？
关联子查询本质是 N×M 复杂度：外部表每行都触发一次子查询扫描。如果 production_log 有 10 万行，而 workstation_specs 没索引，就会扫 10 万次全表。
- 必须在
workstation_specs.workstation_id上建索引：CREATE INDEX idx_ws_id ON workstation_specs(workstation_id); - 避免在子查询里写复杂逻辑（如嵌套函数、多表 JOIN），它会被重复执行
- 如果只是要各工位汇总效率（非逐班次），改用
JOIN+GROUP BY更快，关联子查询更适合「每行独立计算」场景 - PostgreSQL 可用
EXPLAIN ANALYZE看子查询是否走了索引；MySQL 注意EXPLAIN中的select_type是否为DEPENDENT SUBQUERY
关联子查询真正难的不是语法，而是想清楚「哪部分必须随外部行变化」——标准产能是静态参数，所以放子查询；但实际工时、产出是变动数据，必须从外部行取。漏掉这个区分，就容易把能 JOIN 的东西硬写成子查询，白白拖慢速度。
