子查询必须用括号包裹，否则报语法错误；FROM中派生表需别名；多列子查询不可用于单值上下文；相关子查询性能敏感；交叉销售需用EXISTS识别同客户多品类共现；分组统计须对齐子查询粒度；索引缺失是性能瓶颈主因。
子查询必须用括号包裹，否则 SQL syntax error 直接报错
很多用户写完 SELECT * FROM orders WHERE customer_id IN SELECT id FROM customers WHERE region = '华东' 就报错，根本原因是子查询没加括号。MySQL、PostgreSQL、SQL Server 全部强制要求：任何子查询出现在 WHERE、FROM 或 SELECT 中时，必须用 ( ) 包裹。
正确写法是：SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE region = '华东')。漏括号不是风格问题，是语法硬性限制。
常见踩坑点：
- 在
FROM子句中嵌套子查询（即派生表）时，必须给子查询起别名，例如FROM (SELECT customer_id, COUNT(*) c FROM orders GROUP BY customer_id) AS t，否则报Every derived table must have its own alias - 子查询返回多列但被用在单值上下文（如
WHERE x = (SELECT a,b FROM ...)），会直接报错，此时应改用EXISTS或联结 - 相关子查询（含外部引用）性能敏感，比如
SELECT o.*, (SELECT SUM(amount) FROM payments p WHERE p.order_id = o.id) FROM orders o，每行都会触发一次子查询执行，大数据量时明显变慢
交叉销售计算的关键是识别「同客户不同品类」共现关系
典型场景：找出购买过「笔记本电脑」的客户中，有多少人还买了「无线鼠标」，并计算转化率。不能只查两个品类各自销量，必须定位到同一 customer_id 下的订单交集。
推荐用 EXISTS + 相关子查询实现，比 IN 更安全（自动忽略 NULL 值干扰）：
SELECT
COUNT(*) AS buyers_of_laptop,
COUNT(CASE WHEN EXISTS (
SELECT 1 FROM order_items i2
JOIN products p2 ON i2.product_id = p2.id
WHERE i2.order_id = o.id AND p2.category = '无线鼠标'
) THEN 1 END) AS also_bought_mouse,
ROUND(100.0 * COUNT(CASE WHEN EXISTS (... ) THEN 1 END) / COUNT(*), 2) AS cross_sell_rate
FROM orders o
JOIN order_items i ON o.id = i.order_id
JOIN products p ON i.product_id = p.id
WHERE p.category = '笔记本电脑';注意点：
- 子查询里用
SELECT 1而非SELECT *，语义清晰且避免字段歧义 - 外层
WHERE过滤主品类（笔记本电脑），子查询检查辅品类（无线鼠标），逻辑方向不能反 - 若需扩展为「任意两品类组合」，建议把品类条件抽成参数或 CTE，避免硬编码重复
多维度聚合必须用 GROUP BY 对齐子查询粒度
当要按地区、月份、会员等级等维度统计交叉销售率时，子查询结果必须和外层分组键对齐，否则会触发 Invalid use of group function 或聚合错误。
错误写法：SELECT region, COUNT(*) FROM customers c WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id AND o.date >= '2024-01-01') GROUP BY region —— 这里子查询没感知 region，但外层按 region 分组，逻辑上没问题；可一旦子查询里也想按月统计，就容易出错。
正确做法是让子查询也带上分组维度，或改用 JOIN + LEFT JOIN 显式关联：
SELECT c.region, DATE_FORMAT(o.order_date, '%Y-%m') AS ym, COUNT(DISTINCT c.id) AS laptop_buyers, COUNT(DISTINCT CASE WHEN m.order_id IS NOT NULL THEN c.id END) AS cross_buyers FROM customers c JOIN order_items i1 ON c.id = i1.customer_id JOIN products p1 ON i1.product_id = p1.id AND p1.category = '笔记本电脑' JOIN orders o ON i1.order_id = o.id LEFT JOIN ( SELECT DISTINCT i2.customer_id, i2.order_id FROM order_items i2 JOIN products p2 ON i2.product_id = p2.id AND p2.category = '无线鼠标' ) m ON c.id = m.customer_id AND o.id = m.order_id GROUP BY c.region, ym;
这样每个维度组合都独立计算，不会因子查询“看不见”分组字段而失真。
性能瓶颈往往卡在子查询未走索引，而非语法本身
即使语法全对，交叉销售类查询在百万级订单表上仍可能秒变分钟级。核心原因：子查询中的关联字段（如 order_id、customer_id）缺少索引。
必须检查并确保以下索引存在：
-
order_items(customer_id, product_id)—— 支撑「某客户买了什么」快速过滤 -
order_items(order_id, product_id)—— 支撑「某订单含哪些品类」快速下钻 -
products(category, id)—— 加速品类条件筛选，避免全表扫描 - 若子查询含时间范围（如最近30天），务必在
orders(order_date, id)上建联合索引
用 EXPLAIN 看执行计划时，重点关注子查询部分是否显示 type=ref 或 range；如果出现 type=all，基本可以确定缺索引。
最后提醒：子查询嵌套超过两层、或含多个相关子查询时，可读性和维护性急剧下降。这种情况下，优先考虑用 CTE 拆解逻辑，或落地中间结果表——交叉销售分析本就是离线场景，没必要强求单条 SQL 解决所有问题。
