MySQL复合查询：核心类型与性能优化实战

1. 复合查询：MySQL进阶必备技能

作为一名常年与MySQL打交道的数据库工程师，我必须说复合查询是SQL语言中最实用也最容易踩坑的特性之一。它不像基础SELECT语句那样简单直白，也不像存储过程那样复杂难懂，而是处于一个恰到好处的中间地带——用好了能让查询效率提升数倍，用不好则可能让数据库直接崩溃。

复合查询本质上就是多个SELECT语句通过特定方式组合在一起的操作。想象你是个餐厅经理，基础查询就像单独查看今日牛排或沙拉销量，而复合查询则是要分析"点了牛排又点红酒的顾客中，同时点了甜品的比例"这类复杂业务问题。这正是实际工作中最常见的分析场景。

2. 复合查询的四种核心类型

2.1 联合查询（UNION）：数据合并的艺术

UNION就像把两个Excel表格上下拼接在一起。上周我帮电商客户分析用户行为时，需要合并APP端和Web端的访问日志：

sql复制SELECT user_id, page_url, access_time FROM app_logs
UNION
SELECT user_id, page_url, access_time FROM web_logs
ORDER BY access_time DESC;

关键注意点：

• 默认会去除重复行（用UNION ALL可保留重复）
• 每个SELECT的列数必须相同
• 对应列的数据类型要兼容（比如不能把varchar和int列合并）

实际踩坑经验：当UNION多个大表时，务必先在各子查询做好条件过滤，否则可能生成超大临时表导致内存溢出。我曾见过一个UNION操作把16GB的临时表空间撑爆的案例。

2.2 子查询：查询中的查询

子查询分为单行子查询和多行子查询两种。最经典的场景就是找出比平均工资高的员工：

sql复制SELECT name, salary FROM employees
WHERE salary > (SELECT AVG(salary) FROM employees);

多行子查询常配合IN、ANY、ALL使用。比如查找至少有一个订单金额超过1000的客户：

sql复制SELECT customer_name FROM customers
WHERE customer_id IN (
    SELECT DISTINCT customer_id FROM orders
    WHERE amount > 1000
);

性能提示：MySQL 8.0+对子查询有显著优化，但5.7版本中复杂的嵌套子查询可能导致全表扫描。有次我优化一个三层嵌套的子查询，改为JOIN后执行时间从12秒降到0.3秒。

2.3 派生表：给子查询起别名

派生表其实就是放在FROM子句中的子查询，必须要有别名。比如分析各部门薪资排名：

sql复制SELECT d.department_name, e.name, e.salary
FROM departments d
JOIN (
    SELECT department_id, name, salary,
           RANK() OVER(PARTITION BY department_id ORDER BY salary DESC) as rank
    FROM employees
) e ON d.department_id = e.department_id
WHERE e.rank <= 3;

这个例子同时用到了窗口函数，是MySQL 8.0的新特性。在5.7版本中要实现类似功能，就得用更复杂的变量技巧。

2.4 EXISTS：存在性检测利器

EXISTS用于检查子查询是否返回结果，特别适合"存在即满足"的场景。比如查找下过订单但最近30天没登录的用户：

sql复制SELECT user_id, username FROM users u
WHERE EXISTS (
    SELECT 1 FROM orders o WHERE o.user_id = u.user_id
)
AND NOT EXISTS (
    SELECT 1 FROM login_logs l 
    WHERE l.user_id = u.user_id 
    AND l.login_time > DATE_SUB(NOW(), INTERVAL 30 DAY)
);

EXISTS的性能通常比IN好，尤其是当子查询结果集很大时。因为EXISTS找到第一个匹配项就会停止，而IN需要收集所有结果。

3. 复合查询性能优化实战

3.1 EXPLAIN是你的最佳朋友

任何复杂的复合查询都应该先用EXPLAIN分析执行计划。重点关注：

• type列：最好看到eq_ref或range，避免ALL(全表扫描)
• Extra列：出现"Using temporary"或"Using filesort"时要警惕
• rows列：估算的扫描行数

3.2 索引使用黄金法则

• WHERE子句中的列优先加索引
• JOIN条件列必须加索引
• ORDER BY/GROUP BY的列考虑加索引
• 多列条件考虑组合索引

但注意：索引不是越多越好！每个索引都会降低写操作性能。上周我优化的一个表有18个索引，删除冗余索引后写入速度提升了5倍。

3.3 临时表与内存使用

复合查询经常需要创建临时表。通过以下参数可以优化：

sql复制-- 查看当前配置
SHOW VARIABLES LIKE '%tmp%';

-- 建议设置(根据服务器内存调整)
SET tmp_table_size = 256*1024*1024;
SET max_heap_table_size = 256*1024*1024;

当临时表超过这些大小时，MySQL会转为磁盘临时表，性能急剧下降。

4. 真实业务场景案例解析

4.1 电商用户行为分析

需求：找出购买过A商品后又购买B商品的用户路径

sql复制SELECT DISTINCT a.user_id
FROM orders a
JOIN orders b ON a.user_id = b.user_id
WHERE a.product_id = 'A'
AND b.product_id = 'B'
AND b.order_date > a.order_date
AND b.order_date < DATE_ADD(a.order_date, INTERVAL 30 DAY);

这个查询用到了自连接，是复合查询中的高级技巧。在大数据量时，务必确保user_id和order_date有联合索引。

4.2 财务报表的多维度统计

sql复制SELECT 
    YEAR(transaction_date) as year,
    MONTH(transaction_date) as month,
    SUM(CASE WHEN type = 'income' THEN amount ELSE 0 END) as total_income,
    SUM(CASE WHEN type = 'expense' THEN amount ELSE 0 END) as total_expense,
    SUM(CASE WHEN type = 'income' THEN amount ELSE -amount END) as profit
FROM transactions
WHERE transaction_date BETWEEN '2023-01-01' AND '2023-12-31'
GROUP BY YEAR(transaction_date), MONTH(transaction_date)
WITH ROLLUP;

这里使用了条件聚合+CASE表达式+WITH ROLLUP，能一次性生成带小计的报表。WITH ROLLUP是MySQL特有的扩展功能。

5. 常见错误与避坑指南

5.1 笛卡尔积灾难

忘记写JOIN条件是最危险的错误：

sql复制-- 错误示例(将产生M×N条结果)
SELECT * FROM users, orders;

-- 正确写法
SELECT * FROM users u JOIN orders o ON u.user_id = o.user_id;

我曾见过一个开发人员误操作导致两个百万级表笛卡尔积，生成上万亿条临时数据，直接把生产库拖垮。

5.2 GROUP BY的坑

MySQL的GROUP BY处理与其他数据库不同：

sql复制-- 在MySQL中可能返回随机值(其他数据库会报错)
SELECT department_id, employee_name, salary
FROM employees
GROUP BY department_id;

-- 正确写法
SELECT department_id, 
       GROUP_CONCAT(employee_name),
       AVG(salary)
FROM employees
GROUP BY department_id;

5.3 LIMIT在子查询中的陷阱

sql复制-- 这个查询可能返回不符合预期的结果
SELECT * FROM products
WHERE price > (
    SELECT price FROM products ORDER BY price DESC LIMIT 1,1
);

-- 更安全的写法
SELECT * FROM products
WHERE price > (
    SELECT MIN(price) FROM (
        SELECT price FROM products ORDER BY price DESC LIMIT 2
    ) t
);

6. 新版本特性与未来趋势

MySQL 8.0引入了许多增强复合查询的功能：

1. 公用表表达式(CTE)：

sql复制WITH regional_sales AS (
    SELECT region, SUM(amount) as total_sales
    FROM orders
    GROUP BY region
)
SELECT region, total_sales
FROM regional_sales
WHERE total_sales > 100000;

2. 窗口函数：

sql复制SELECT 
    product_id,
    sale_date,
    amount,
    SUM(amount) OVER(PARTITION BY product_id ORDER BY sale_date) as running_total
FROM sales;

3. 横向派生表(LATERAL)：

sql复制SELECT u.user_id, latest_order.order_date
FROM users u,
LATERAL (
    SELECT order_date FROM orders
    WHERE user_id = u.user_id
    ORDER BY order_date DESC LIMIT 1
) latest_order;

这些新特性让复合查询更强大也更易读。我建议所有新项目都直接使用MySQL 8.0+版本。

复合查询就像SQL语言中的瑞士军刀，掌握它们需要练习但绝对值得。建议读者从简单的UNION和子查询开始，逐步尝试更复杂的组合。记住：任何复杂的查询都应该先在测试环境用EXPLAIN验证，并准备好在性能不佳时重写为更简单的形式。