嵌套查询仅用于数据筛选，无法实现真正关联推荐；需通过分组聚合统计共现频次、加阈值过滤并归一化处理，配合索引优化与应用层策略才能支撑电商推荐。
嵌套查询本身不直接实现“推荐逻辑”，它只是数据筛选工具；真正支撑关联推荐的是对用户行为集合的结构化表达——比如“买过A的人也买了B”，这本质是关系代数中的除运算或自连接，不是靠多层 SELECT 堆叠就能解决的。
WHERE 中用 IN 做基础关联筛选，但别指望它推荐
常见错误是写成：SELECT * FROM products WHERE id IN (SELECT product_id FROM order_items WHERE order_id IN (SELECT order_id FROM order_items WHERE product_id = 101))。这只能查出“和商品 101 出现在同一订单里的其他商品”，但它不区分频次、不排权重、不剔除噪声（比如凑单赠品）。实际业务中，这种结果常被误当作“推荐”，其实是粗粒度共现。
- 必须加
COUNT(*)和GROUP BY统计共现次数，否则无法排序 -
IN子查询返回空集时，外层查询结果为空——要改用LEFT JOIN或EXISTS控制空值行为 - MySQL 8.0+ 支持
LATERAL，但多数电商系统仍用 MySQL 5.7 或 PostgreSQL 12，LATERAL不可用
用 EXISTS 替代 IN 处理存在性判断更安全
当你要找“买过商品 A 的用户中，哪些人还买过商品 B”，写 IN 容易因子查询返回 NULL 导致整行被过滤掉。而 EXISTS 只关心是否存在匹配行，语义更清晰，执行计划也更容易走索引。
- 示例：
SELECT DISTINCT u.user_id FROM users u WHERE EXISTS (SELECT 1 FROM order_items oi1 JOIN order_items oi2 ON oi1.order_id = oi2.order_id WHERE oi1.product_id = 101 AND oi2.product_id = 102 AND u.user_id = oi1.user_id) -
EXISTS子查询里用SELECT 1，不是SELECT *，避免列解析开销 - 确保
order_items(order_id, product_id)和order_items(user_id, order_id)有复合索引，否则性能断崖下跌
真正做关联推荐得绕开纯嵌套，转向分组聚合 + 排序
电商场景下，“买了 A 的人还买了什么”必须回答两个问题：频次是否显著？是否排除热门通用品？这靠单层嵌套做不到，得用聚合后过滤。
- 先算共现矩阵：
SELECT oi1.product_id AS target, oi2.product_id AS also_bought, COUNT(*) AS cooccur FROM order_items oi1 JOIN order_items oi2 ON oi1.order_id = oi2.order_id WHERE oi1.product_id = 101 AND oi1.product_id != oi2.product_id GROUP BY oi1.product_id, oi2.product_id - 再加阈值过滤：
HAVING cooccur >= 5（排除偶然下单），并JOIN products补商品名 - 不能只依赖嵌套——上面这个查询如果硬拆成三层子查询，MySQL 会拒绝优化，执行时间从 200ms 涨到 3s+
复杂点在于：共现频次得归一化（比如除以该商品总销量），否则耳机配件永远压倒大家电；还有冷启动问题——新上架商品没共现数据，嵌套查询直接返回空。这些都不是语法层面能解决的，得在应用层补策略或引入图算法预计算。
