在SQL查询编写过程中，我们经常会先通过表达式生成计算列，再在后续的嵌套查询中引用这个计算列完成进一步筛选或统计，但很多时候会直接遇到列不存在的报错，这本质是由SQL的逻辑执行顺序导致的。
问题产生的原因
SQL的逻辑执行顺序和书写顺序并不一致，计算列的生效时机晚于WHERE、GROUP BY等子句，也晚于同层的嵌套子查询。如果我们直接在嵌套查询中引用同层刚定义的计算列，数据库引擎还没有完成计算列的解析，自然无法识别这个列。
比如下面这段错误的查询代码，我们想要先计算出订单的总金额，再筛选出总金额大于1000的订单：
SELECT
order_id,
unit_price * quantity AS total_price
FROM orders
WHERE total_price > 1000;
这段查询会直接报错，因为WHERE子句执行时，total_price这个计算列还没有被解析出来，引擎无法识别这个列名。
派生表的核心作用
派生表指的是在FROM子句中嵌套的SELECT查询，它会生成一个临时的结果集，这个结果集可以像普通表一样被外层查询引用。由于派生表的执行优先级高于外层的WHERE、GROUP BY等子句，因此计算列在派生表中生成后，外层查询就可以正常识别和使用。
通过派生表解决问题的示例
我们还是用刚才的订单场景，把计算列的生成放到派生表中，外层查询再引用计算列做筛选，就可以避免报错：
SELECT
order_id,
total_price
FROM (
-- 派生表，先生成计算列total_price
SELECT
order_id,
unit_price * quantity AS total_price
FROM orders
) AS derived_table
WHERE total_price > 1000;
在这个查询中，内层派生表先执行，生成包含total_price列的临时结果集，外层查询再从这个临时结果集中筛选total_price大于1000的记录，此时计算列已经存在，所以不会报错。
更复杂的嵌套场景示例
如果我们需要在嵌套查询中进一步使用计算列做分组统计，同样可以用派生表解决。比如我们要统计每个用户的总订单金额，再筛选出总订单金额大于5000的用户：
SELECT
user_id,
sum_total
FROM (
-- 第一层派生表，先计算每个订单的总金额
SELECT
user_id,
order_id,
unit_price * quantity AS order_total
FROM orders
) AS order_derived
-- 第二层派生表，再统计每个用户的总订单金额
INNER JOIN (
SELECT
user_id,
SUM(order_total) AS sum_total
FROM (
SELECT
user_id,
unit_price * quantity AS order_total
FROM orders
) AS inner_derived
GROUP BY user_id
) AS user_derived
ON order_derived.user_id = user_derived.user_id
WHERE user_derived.sum_total > 5000;
这里的计算列order_total先在最内层的派生表中生成，后续的分组和筛选都可以正常引用这个列，不会出现列不存在的问题。
注意事项
- 派生表必须指定别名，否则数据库会报错，比如上面的
derived_table、order_derived都是派生表的别名。 - 派生表生成的结果集是临时的，查询执行完成后就会释放，不会占用永久存储。
- 如果计算列的逻辑比较简单，也可以考虑使用CTE（公用表表达式）实现，逻辑和派生表类似，只是书写方式更清晰。
总结
SQL嵌套查询中无法引用计算列的核心原因是执行顺序导致的列可见范围限制，派生表通过将计算列提前生成临时结果集，让外层查询可以正常识别计算列，完美解决了引用顺序的问题。掌握派生表的使用方式，能帮助我们更灵活地编写复杂的SQL查询，避免不必要的报错。