子查询中不能直接用SELECT定义的列别名进行二次计算，因SQL执行顺序为FROM→WHERE→GROUP BY→HAVING→SELECT，别名在SELECT阶段才生成，故WHERE和HAVING（非聚合场景）无法引用；必须通过嵌套子查询或CTE固化中间结果，再在外层筛选。
子查询里不能直接用别名做二次计算？
SQL标准规定，SELECT子句中定义的列别名在同级WHERE或HAVING中不可引用——这是最常踩的坑。比如写SELECT price * 1.1 AS final_price WHERE final_price > 100会报错，因为final_price在WHERE执行时尚未生成。
真正能用别名做二次过滤的方式只有两种：嵌套子查询，或使用HAVING（仅限聚合场景）。动态计算字段的“二次数学过滤”，本质是把一次计算结果作为新数据源再筛一遍。
- 外层
WHERE只能作用于内层子查询的输出列，所以要把带计算的字段放在子查询的SELECT里 - 避免在子查询中重复写长表达式，可先用
SELECT算出中间值，再在外层加条件 - MySQL 8.0+ 支持 CTE，但 CTE 本身不改变执行逻辑，仍需按“先算后筛”顺序组织
怎么写一个带价格上调后过滤的子查询？
假设原始表products有base_price，要筛选“上调10%后大于100且小于500”的商品。不能写成WHERE base_price * 1.1 > 100 AND base_price * 1.1 ——虽然语法合法，但无法复用计算结果，也不符合“动态计算字段再过滤”的意图。
正确做法是让子查询产出final_price，外层再对它做范围判断：
SELECT * FROM ( SELECT id, name, base_price * 1.1 AS final_price FROM products ) AS t WHERE t.final_price > 100 AND t.final_price < 500;
注意别名t必须存在，否则多数数据库（如 PostgreSQL、SQL Server）会报错；MySQL 允许省略，但加上更稳妥。
- 如果还要排序或分页，
ORDER BY和LIMIT必须放在最外层 - 子查询里不要加
WHERE提前过滤，除非能显著减少数据量——否则可能干扰优化器选择索引 -
base_price * 1.1这种浮点运算在WHERE中可能引发精度问题，生产环境建议用ROUND(base_price * 1.1, 2)
多个动态字段叠加时子查询怎么嵌套？
当需要同时计算折扣价、税费、最终实付，并基于其中两个做联合过滤（比如“实付5”），一层子查询不够用。这时候不是无限制嵌套，而是按依赖关系分层：
- 第一层子查询算出基础衍生字段（如
discounted_price = base_price * 0.9） - 第二层基于第一层结果再算复合字段（如
tax = discounted_price * 0.08、final_paid = discounted_price + tax） - 最外层对
final_paid和tax做WHERE判断
示例：
SELECT * FROM (
SELECT id, name,
discounted_price,
ROUND(discounted_price * 0.08, 2) AS tax,
discounted_price + ROUND(discounted_price * 0.08, 2) AS final_paid
FROM (
SELECT id, name, ROUND(base_price * 0.9, 2) AS discounted_price
FROM products
) AS step1
) AS step2
WHERE step2.final_paid < 100 AND step2.tax > 5;每层只做一步计算，语义清晰，也方便单独调试某一层的输出。
性能和可读性哪个更值得牺牲？
子查询嵌套会让执行计划变复杂，尤其当内层没走索引、又返回大量行时，外层WHERE就变成全表扫描。但比起在应用层拉取全部数据再过滤，SQL 层过滤始终更高效。
真正该警惕的是“为嵌套而嵌套”。如果所有计算都基于单个字段、逻辑简单，直接写在WHERE里反而更快：
- 用
WHERE base_price * 0.9 * 1.08 BETWEEN 5 AND 100比两层子查询快得多 - 只有当计算结果要被多次引用（比如同时用于
WHERE、ORDER BY、SELECT输出），才值得用子查询固化中间值 - 某些数据库（如 PostgreSQL）支持
LATERAL，可在FROM侧动态计算并过滤，比子查询更灵活，但兼容性差
子查询不是银弹，它的价值在于明确数据流阶段——算什么、筛什么、输出什么，三者必须分清。混淆这三步，再漂亮的嵌套也救不了慢查询。
