子查询是嵌套在SELECT、INSERT、UPDATE或DELETE语句中的查询，MySQL会先执行内层查询，再将结果交给外层查询继续处理。子查询可以出现在SELECT列表、FROM子句、WHERE条件以及HAVING条件等多个位置。由于子查询写法直观、逻辑清晰，很多复杂业务条件都会优先使用它。不过子查询在执行效率上并不总是最优，尤其是相关子查询在内层被反复执行时，容易产生严重的性能问题。理解子查询的分类、执行机制以及优化策略，是写出高效MySQL语句的基本功。
MySQL支持多种子查询形式。按照返回结果的结构，通常分为标量子查询、列子查询、行子查询和表子查询。标量子查询返回单个值，通常用于比较运算；列子查询返回一列数据，常用于IN或NOT IN判断；行子查询返回一行中的多个字段，可以与括号包裹的字段组合进行比较；表子查询返回多行多列，一般放在FROM后面作为派生表使用。按照是否依赖外层查询，还可以分为非相关子查询和相关子查询。非相关子查询可以独立执行，相关子查询则会引用外层查询的字段，每处理一行外层数据就要重新执行一次内层查询。不同的子查询类型对性能的影响差异很大。
一、MySQL子查询的常用类型与语法
标量子查询最常见的使用场景是在SELECT列表中计算某个统计值，或者作为WHERE条件中的比较值。例如查询每位员工及其所在部门名称时，可以写一个标量子查询：
SELECT e.name,
e.salary,
(SELECT d.name
FROM departments d
WHERE d.id = e.department_id) AS dept_name
FROM employees e;
这条语句中，内层查询会为每位员工查找一次department_id对应的部门名称。数据量小的时候没有明显问题，但如果employees表有几十万行，每次匹配departments表都需要通过索引快速定位，否则就会出现大量全表扫描。由于标量子查询本质上是一个相关子查询，执行次数与外层返回行数相同，因此必须关注内层字段的索引设计。
列子查询常配合IN和NOT IN使用。例如查询位于东部区域的部门下的所有员工：
SELECT id, name, salary
FROM employees
WHERE department_id IN (
SELECT id
FROM departments
WHERE region = 'East'
);
这种子查询是非相关的，优化器通常可以先执行内层查询得到部门ID列表，再遍历employees表进行匹配。MySQL 5.6及之后的版本对IN子查询做了半连接优化，能够直接利用索引进行连接操作，而不是简单地把内层结果物化成临时表。但NOT IN子查询对NULL值敏感，如果内层结果中包含NULL，整个NOT IN判断可能返回空结果，这是使用列子查询时容易踩的坑。
行子查询的写法相对较少，但它可以同时比较多个字段。例如查找某位指定员工同部门且岗位一致的记录：
SELECT id, name, salary
FROM employees
WHERE (department_id, job_title) = (
SELECT department_id, job_title
FROM employees
WHERE id = 1001
);
表子查询通常放在FROM之后，作为派生表进行二次查询。例如先按部门计算平均工资，再关联员工表筛选高于平均工资的人：
SELECT e.name, e.salary, t.avg_salary
FROM employees e
JOIN (
SELECT department_id, AVG(salary) AS avg_salary
FROM employees
GROUP BY department_id
) t
ON e.department_id = t.department_id
WHERE e.salary > t.avg_salary;
表子查询会先在内层完成分组聚合，生成结果后再与外层表进行连接。如果派生表数据量较大，MySQL需要将其写入临时表并可能产生磁盘临时表，这会增加I/O开销。因此派生表的行数控制和索引使用同样重要。
二、子查询的执行过程与性能瓶颈
理解子查询的执行过程需要区分相关子查询和非相关子查询。对于非相关子查询，MySQL可以先独立执行内层查询，把结果保存到内存或临时表中，再执行外层查询。这种执行方式相对高效，只扫描一次内层表。例如前面按区域查询部门的IN子查询，内层只执行一次，得到若干部门ID，外层再根据这些ID过滤员工。相反，相关子查询会在外层查询的每一行上重复执行内层查询，执行次数等于外层结果集的行数。例如查询工资高于本部门平均工资的员工：
SELECT e.name, e.salary
FROM employees e
WHERE e.salary > (
SELECT AVG(salary)
FROM employees e2
WHERE e2.department_id = e.department_id
);
这条语句中，外层每次读取一个员工记录，就会执行一次内层AVG计算。如果employees表有10万行，内层就要执行10万次，哪怕department_id有索引，累计开销也非常可观。执行计划中如果出现DEPENDENT SUBQUERY，就说明这个子查询是相关子查询，需要特别关注其执行次数。出现UNCACHEABLE SUBQUERY则提示子查询结果无法缓存，每次外层行都需要重新计算，通常与函数、变量或非确定性表达式有关。
MySQL优化器会对子查询进行不同程度的改写和优化。对于IN子查询，优化器可能将其转换为半连接，执行方式类似于内连接，只返回外层表记录，不会产生重复行。半连接能充分利用索引，避免先物化整个内层结果。对于派生表，MySQL 5.7开始支持派生表合并优化，能够把简单的派生表直接展开到外层查询中，减少临时表创建。但如果派生表包含分组、聚合、DISTINCT、LIMIT等操作，则无法合并，只能物化到临时表，再与外层表连接。执行计划中的MATERIALIZED表示使用了物化策略，此时临时表的大小直接决定查询效率。
性能瓶颈主要来自几个方面：一是相关子查询导致大量重复扫描；二是IN子查询遇到大结果集时，内层物化消耗内存和I/O；三是子查询中的关联列没有索引，导致内层全表扫描；四是SELECT列表中的子查询逐行执行，拖慢整条SQL。判断这些问题最直接的手段是使用EXPLAIN查看执行计划，关注DEPENDENT SUBQUERY、MATERIALIZED、Using temporary和Using filesort等提示。找到瓶颈后，才能针对性地改写SQL。
三、子查询优化的六种实用方法
第一种方法是把IN子查询改写为JOIN。当内层查询返回的结果集较大时，JOIN通常比IN更高效，因为JOIN可以利用连接顺序和索引，而不需要先生成完整的内层结果集。例如查询所有下过订单的用户信息：
SELECT DISTINCT u.id, u.name FROM users u JOIN orders o ON u.id = o.user_id;
如果使用SELECT * FROM users WHERE id IN (SELECT user_id FROM orders)，优化器可能需要先扫描orders表得到大量user_id，再去匹配users表。当orders表非常大时，JOIN配合orders表的user_id索引可以大幅降低扫描成本。不过需要注意，JOIN可能产生重复行，必要时使用DISTINCT去重。如果内层结果集很小且已经建立唯一索引，IN子查询的性能未必差，这时不必盲目改写。
第二种方法是根据外内层表大小选择EXISTS和IN。传统经验认为，外层小内层大时适合用EXISTS，外层大内层小时适合用IN。实际上MySQL优化器已经能对IN做半连接优化，EXISTS则通常以相关子查询形式执行，每行外层记录去内层探测一次。当外层结果集很大而内层表有主键或唯一索引时，EXISTS可以利用快速索引探测，效果不错。例如查询存在大额销售记录的员工：
SELECT e.id, e.name
FROM employees e
WHERE EXISTS (
SELECT 1
FROM sales s
WHERE s.employee_id = e.id
AND s.amount > 10000
);
这里sales表的employee_id和amount如果是复合索引，EXISTS的执行效率会很高。反之，如果外层员工很少，内层销售记录很多，IN子查询也许更直观。编写SQL时不应死记结论，而应结合实际执行计划进行判断。
第三种方法是改写相关子查询为JOIN或派生表。相关子查询因为执行次数多，往往是性能杀手。以查询每个部门工资最高的员工为例，原始写法可能为：
SELECT e.name, e.salary, e.department_id
FROM employees e
WHERE e.salary = (
SELECT MAX(salary)
FROM employees e2
WHERE e2.department_id = e.department_id
);
可以改写为JOIN加聚合派生表：
SELECT e.name, e.salary, e.department_id
FROM employees e
JOIN (
SELECT department_id, MAX(salary) AS max_salary
FROM employees
GROUP BY department_id
) t
ON e.department_id = t.department_id
AND e.salary = t.max_salary;
第二种写法只扫描两次employees表，第一次分组聚合，第二次连接匹配，执行次数远低于逐行计算MAX。派生表中的GROUP BY department_id如果配合department_id索引，还可以进一步优化分组操作。这个例子很典型，能直观体现SQL改写对性能的提升。
第四种方法是避免在SELECT列表中使用相关子查询。很多开发者喜欢在SELECT中嵌套子查询获取附加信息，例如查员工工资时追加部门平均工资：
SELECT e.name,
e.salary,
(SELECT AVG(salary)
FROM employees e2
WHERE e2.department_id = e.department_id) AS dept_avg
FROM employees e;
这种写法每行都会执行一次AVG计算，10万员工就执行10万次。更好的方式是用JOIN连接预聚合结果：
SELECT e.name,
e.salary,
t.dept_avg
FROM employees e
JOIN (
SELECT department_id, AVG(salary) AS dept_avg
FROM employees
GROUP BY department_id
) t
ON e.department_id = t.department_id;
派生表只执行一次聚合，外层JOIN可以利用关联索引，整体性能通常优于相关子查询。如果业务允许，还可以使用窗口函数，MySQL 8.0支持AVG() OVER (PARTITION BY department_id)，写法更简洁，执行效率也较高。
第五种方法是为子查询涉及的内外表关联列建立合适索引。子查询的性能并不完全取决于SQL写法，索引设计同样关键。例如相关子查询WHERE e2.department_id = e.department_id中，内层表e2的department_id字段有索引时，每次内层查询才能通过索引快速定位，否则每次都是全表扫描。对于EXISTS子查询，关联字段和外层过滤字段组合成复合索引效果更好。比如sales表建立INDEX idx_emp_amount (employee_id, amount)，那么WHERE s.employee_id = e.id AND s.amount > 10000可以同时利用索引完成定位和过滤。
第六种方法是控制子查询返回的数据量。对于不能改写为JOIN的场景，可以考虑在内层查询中使用LIMIT限制返回行数，尤其是只需要判断是否存在或获取某个极值的情况。例如只需要判断某部门是否存在员工，可以使用EXISTS配合SELECT 1，让内层在找到第一条匹配记录后立即停止扫描。对于标量子查询，如果内层可能返回空值，需要确保业务逻辑能正确处理NULL，避免外层条件意外失效。
四、实战：从慢查询日志到SQL改写
假设一条慢查询日志显示如下SQL执行超过5秒，出现在高并发报表场景中：
SELECT u.id, u.nickname, u.register_date,
(SELECT COUNT(*)
FROM orders o
WHERE o.user_id = u.id) AS order_count
FROM users u
WHERE u.status = 1
ORDER BY order_count DESC
LIMIT 100;
这条语句从用户表读取状态为1的用户，再用相关子查询计算每个用户的订单数，最后按订单数倒序取前100。users表有几十万行，status字段选择性很低，内层orders表虽然有user_id索引，但每行用户都要执行一次COUNT聚合，累计开销巨大。通过EXPLAIN可以看到SELECT列表中的DEPENDENT SUBQUERY，且外层扫描了大量行。
优化思路是先将订单数聚合到派生表，再与用户表连接，最后排序取前100。改写后的SQL如下：
SELECT u.id, u.nickname, u.register_date, t.order_count
FROM users u
JOIN (
SELECT user_id, COUNT(*) AS order_count
FROM orders
GROUP BY user_id
) t
ON u.id = t.user_id
WHERE u.status = 1
ORDER BY t.order_count DESC
LIMIT 100;
改写后，orders表只需要按user_id分组聚合一次，生成每个用户的订单数，再与users表连接。即便聚合结果仍然很大，MySQL也可以使用临时表配合索引进行排序和LIMIT操作，避免重复扫描。若orders表数据量特别大，还可以考虑在user_id字段上建立索引，并适当调整sort_buffer_size或使用覆盖索引，减少回表。实践中这条SQL从5秒降到200毫秒以内，性能提升明显。
另一个常见例子是NOT IN导致结果异常和性能下降。例如查询没有下过订单的用户：SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM orders)。如果orders.user_id存在NULL，整个NOT IN条件可能返回空集，而且反连接优化对NULL处理复杂，执行计划可能选择全表扫描。此时改写为NOT EXISTS更安全且通常更快：
SELECT u.*
FROM users u
WHERE NOT EXISTS (
SELECT 1
FROM orders o
WHERE o.user_id = u.id
);
NOT EXISTS的语义对NULL友好，内层查询利用orders.user_id索引，外层users表也可以按主键顺序扫描。对比两种写法，NOT EXISTS在大多数情况下都能获得稳定的执行计划，避免NOT IN带来的NULL陷阱和性能波动。
总结来说，子查询是MySQL处理复杂数据关系的重要工具，但性能优化需要结合执行计划、索引设计和业务数据量综合判断。优先使用JOIN或EXISTS替代高开销的相关子查询，避免在SELECT列表中做逐行聚合，为关联列建立复合索引，并用EXPLAIN验证改写效果。掌握这些方法后，大多数由子查询引起的慢查询都能得到有效改善。