SQL表达式是组成全部或部分SQL语句的字符串，是用在SQL语句中对数据进行操作、计算或条件判断的组合式语句，由常量、列名、运算符、函数等元素组成，可用在查询过滤、数据转换、聚合计算等场景。下面，我们仅介绍如何使用子查询优化SQL表达式？我们优化SQL表达式的目标是提升查询效率、简化逻辑、减少重复计算并提高索引利用率。我们使用子查询优化SQL表达式的思路是将复杂表达式拆分为独立的子查询，通过暂存中间结果、简化主查询逻辑，减少重复计算或提升索引利用率。具体如下：

一、消除重复计算，简化主查询

当主查询中多次出现相同的复杂表达式（如：计算、函数调用）时，我们可将其放入子查询中一次性计算，主查询直接引用结果，避免重复运算。

场景：计算订单表中“金额（amount）+ 税费（tax）”的总和，并筛选出该总和大于1000的订单，同时在结果中显示该总和。

优化前（重复计算）：

SELECT 
  order_id,
  amount + tax AS total,  -- 第一次计算：金额加税费
  (amount + tax) * 0.05 AS fee,  -- 第二次计算：相同表达式用于计算手续费
  (amount + tax) * 1.1 AS total_with_service  -- 第三次计算：相同表达式用于计算含服务费总额
FROM orders
WHERE (amount + tax) > 1000;  -- 第四次计算：相同表达式用于过滤条件

问题所在：amount + tax被重复计算4次，不仅低效，且修改时需同步更新所有位置，维护成本高。

优化后（子查询暂存结果）：

-- 子查询计算一次total，主查询直接引用
SELECT 
  order_id,
  total,  -- 直接使用子查询结果
  total * 0.05 AS fee,  -- 基于子查询结果计算
  total * 1.1 AS total_with_service  -- 基于子查询结果计算
FROM (
  SELECT 
    order_id,
    amount + tax AS total  -- 仅计算一次：金额加税费
  FROM orders
) AS sub  -- 子查询必须命名（此处为sub）
WHERE total > 1000;  -- 直接使用子查询结果过滤

优化说明：子查询中amount + tax仅计算一次，主查询通过别名total直接引用，减少重复运算，且逻辑更清晰。

再举一例：库存成本计算优化

-- 优化前：复杂表达式在SELECT和WHERE中重复出现
SELECT 
    product_id,
    product_name,
    -- 复杂计算：成本*数量 + 运输费*折扣（重复3次）
    (cost * quantity + shipping_fee * discount) AS total_cost,
    -- 基于复杂计算的二次运算
    (cost * quantity + shipping_fee * discount) * 1.1 AS total_with_tax,
    -- 基于复杂计算的三次运算
    (cost * quantity + shipping_fee * discount) * 0.02 AS service_fee
FROM inventory
-- 重复使用相同的复杂计算作为过滤条件
WHERE (cost * quantity + shipping_fee * discount) > 1000
  AND category = 'electronics';

-- 优化后：将复杂表达式放入子查询，只计算一次
SELECT 
    product_id,
    product_name,
    total_cost,  -- 直接引用子查询结果
    total_cost * 1.1 AS total_with_tax,  -- 基于子查询结果计算
    total_cost * 0.02 AS service_fee  -- 基于子查询结果计算
FROM (
    -- 子查询：一次性计算复杂表达式并命名为total_cost
    SELECT 
        product_id,
        product_name,
        cost,
        quantity,
        shipping_fee,
        discount,
        (cost * quantity + shipping_fee * discount) AS total_cost
    FROM inventory
    WHERE category = 'electronics'  -- 提前过滤类别，减少数据量
) AS subquery
-- 直接使用子查询中已计算好的total_cost进行过滤
WHERE total_cost > 1000;

优化说明：
1、我们将重复出现的(cost * quantity + shipping_fee * discount)复杂表达式移至子查询，仅计算一次
2、子查询中提前过滤category = 'electronics'，减少主查询需要处理的数据量
3、主查询直接引用子查询中计算好的total_cost，避免了多次重复计算
4、逻辑更清晰，若需修改计算逻辑，只需在子查询中修改一次即可

二、将复杂条件拆分，提升索引利用率

当过滤条件包含复杂表达式（如：函数、多列运算）时，直接写在WHERE中可能导致索引失效，具体说：直接对索引列使用函数（如：YEAR(register_time)）会导致：索引失效（数据库无法使用B+树定位）；强制全表扫描（性能灾难）。用子查询拆分后，可让主查询的过滤条件更简单，便于利用索引。

场景：我们查询用户表中“注册年份（register_time的年份）为2023”的用户，register_time字段有索引。

优化前（索引失效）：

-- YEAR(register_time)是函数，导致register_time的索引无法使用
-- 数据库需全表扫描并对每条记录执行函数计算，效率低
SELECT user_id, register_time
FROM users
WHERE YEAR(register_time) = 2023;  -- 索引列被函数包裹

优化后（子查询拆分，利用索引）：

-- 子查询先通过索引筛选时间范围，再提取年份（避免函数直接作用于索引列）
SELECT user_id, register_time
FROM (
  -- 子查询用范围条件，可利用register_time的索引快速定位
  SELECT user_id, register_time
  FROM users
  WHERE register_time BETWEEN '2023-01-01' AND '2023-12-31 23:59:59' -- 范围查询用索引
) AS sub
WHERE YEAR(register_time) = 2023;  -- 过滤边缘数据，进一步精确筛选（处理极端时间格式）

优化说明：子查询的BETWEEN条件可直接使用register_time的索引，效率远高于主查询中直接对索引列使用函数。

三、用关联子查询简化多表复杂逻辑

当我们需要基于另一张表的条件筛选数据时，关联子查询可替代复杂的多表连接+表达式，让逻辑更清晰。

场景1：我们查询“订单金额大于该用户平均订单金额”的订单，涉及orders表（订单）和users表（用户）。

优化前（复杂连接+表达式）：显式JOIN示例

SELECT o.order_id, o.user_id, o.amount
FROM orders o
-- 先计算每个用户的平均订单金额，再通过JOIN关联
JOIN (                 -- 临时聚合表
  SELECT user_id, AVG(amount) AS avg_amount
  FROM orders
  GROUP BY user_id
) AS avg_o ON o.user_id = avg_o.user_id
WHERE o.amount > avg_o.avg_amount;  -- 主查询中用连接结果判断

优化后（关联子查询）：

SELECT order_id, user_id, amount
FROM orders o
WHERE amount > (
  -- 关联子查询：直接计算当前订单所属用户的平均金额
  SELECT AVG(amount) 
  FROM orders 
  WHERE user_id = o.user_id  -- 关联外部表orders的user_id，关联当前用户
);

优化说明：关联子查询通过WHERE user_id = o.user_id直接关联外部表，避免了显式连接，逻辑更简洁，且数据库通常会优化这类子查询的执行效率。

场景2（多表关联深化）：我们查询“购买过至少3件商品且订单金额超过该商品类别平均价格”的订单详情。

优化前（多层连接）：

SELECT o.order_id, o.product_id, o.quantity, o.amount
FROM orders o
JOIN products p ON o.product_id = p.product_id
JOIN (
  -- 计算每个类别的平均价格
  SELECT category_id, AVG(price) AS avg_category_price
  FROM products
  GROUP BY category_id
) AS avg_p ON p.category_id = avg_p.category_id
WHERE o.quantity >= 3  -- 购买数量条件
  AND o.amount > avg_p.avg_category_price;  -- 金额超过类别均价

优化后（关联子查询）：

SELECT order_id, product_id, quantity, amount
FROM orders o
WHERE quantity >= 3  -- 先过滤数量条件
  AND amount > (
    -- 子查询：获取当前商品所属类别的平均价格
    SELECT AVG(price)
    FROM products p1
    WHERE p1.category_id = (
      -- 嵌套子查询：获取当前商品的类别ID
      SELECT category_id 
      FROM products p2 
      WHERE p2.product_id = o.product_id
    )
  );

优化说明：通过嵌套关联子查询，逐层获取所需信息，避免了多表显式连接，逻辑层次更清晰。

四、使用子查询优化SQL表达式语法模板

1、基础子查询（用于暂存中间结果）

-- 主查询：引用子查询的结果进行筛选或计算
SELECT 主查询字段
FROM (
  -- 子查询：计算或筛选基础数据
  SELECT 
    字段1, 
    字段2, 
    -- 复杂表达式仅计算一次
    (复杂表达式) AS 别名 
  FROM 表名
  WHERE 子查询过滤条件  -- 可选：提前过滤部分数据
) AS 子查询别名  -- 子查询必须有别名
WHERE 主查询过滤条件;  -- 使用子查询的别名简化条件

2、关联子查询（引用外部表字段）

SELECT 外部表字段
FROM 外部表 外部表别名
WHERE 外部表字段 比较运算符 (
  -- 关联子查询：通过WHERE条件与外部表关联
  SELECT 聚合函数(内部表字段)  -- 通常用于聚合计算
  FROM 内部表 内部表别名
  WHERE 内部表字段 = 外部表别名.外部表字段  -- 关联条件
  GROUP BY 分组字段  -- 可选：按条件分组计算
);

3、子查询在SELECT列表中（用于补充字段）

SELECT 
  主表字段,
  -- 子查询作为字段：为每条记录补充额外计算结果
  (SELECT 子查询字段 
   FROM 子查询表 
   WHERE 子查询表关联字段 = 主表.主表关联字段) AS 补充字段别名
FROM 主表
WHERE 主查询条件;

示例：查询每个用户的最新订单ID

SELECT 
  user_id,
  -- 子查询：获取当前用户的最新订单ID
  (SELECT order_id 
   FROM orders 
   WHERE user_id = u.user_id 
   ORDER BY create_time DESC 
   LIMIT 1) AS latest_order_id
FROM users u;

总结：

子查询优化SQL表达式的主要方式：
1、暂存中间结果：减少重复计算，尤其适合多次出现的复杂表达式；
2、拆分复杂条件：让过滤条件更简单，便于数据库使用索引；
3、简化关联逻辑：用关联子查询替代复杂连接，提升可读性和执行效率。

除此之外，在子查询中优先过滤无关数据（如：固定条件、非核心字段筛选），减少主查询需要处理的记录数，能间接优化表达式计算效率。示例：我们计算“电子类商品库存成本”时，子查询先通过WHERE category = 'electronics'过滤非电子类商品，再计算成本，减少主查询的处理数据量。我们还可以合理使用子查询位置，优化字段补充逻辑：将子查询嵌入SELECT列表，为每条记录补充额外计算结果（如：关联表的最新数据），避免复杂的JOIN+GROUP BY操作。示例：查询用户列表时，通过(SELECT order_id FROM orders WHERE user_id = u.user_id ORDER BY create_time DESC LIMIT 1)获取每个用户的最新订单ID。

需注意：实际优化时，我们需结合执行计划（EXPLAIN）分析索引使用和数据扫描情况，避免子查询嵌套过深导致的性能问题。子查询不宜嵌套过深（通常建议不超过3层），否则可能影响性能，此时我们可考虑临时表或CTE（公用表表达式）进一步优化。同时，并非所有场景都适合子查询，我们需结合实际数据量和执行计划选择最优方案。

阅读原文：原文链接