left join 保留左表全部类目（含无子类的父类），inner join 会丢弃无匹配子类的记录，导致分类筛选结果不全。
为什么用 LEFT JOIN 而不是 INNER JOIN 处理分类层级？
因为电商类目常存在“有父类但无子类”或“叶子类目无下级”的情况，用 INNER JOIN 会直接丢弃这些类目，导致筛选结果不全。比如用户选中“手机配件”，但该类目下暂时没商品或子类，INNER JOIN 就会让它从结果里消失。
实操建议：
- 所有分类层级关联（如一级类目 → 二级类目 → 三级类目）统一用
LEFT JOIN，确保顶层类目始终可见 - 在
WHERE条件中对非顶层类目字段加IS NOT NULL判断，避免因 LEFT JOIN 引入的 NULL 值污染筛选逻辑 - 若需强制只返回有商品的类目路径，把过滤条件移到
ON子句而非WHERE，否则 LEFT JOIN 会退化为 INNER JOIN 效果
如何让“多级分类筛选”支持任意深度而不硬编码 JOIN 次数？
硬写 JOIN category c2 ON c1.id = c2.parent_id × 5 层，既难维护又无法应对动态层级。真实场景中，类目树深度可能从 1 到 7 不等，且前端筛选器需要“点击一级显示二级，再点二级显示三级”这样的渐进式加载。
实操建议：
- 放弃单条 SQL 拉取全路径，改用递归 CTE（PostgreSQL / SQL Server / MySQL 8.0+）查出指定类目下的完整子树：
WITH RECURSIVE category_tree AS (...) - 业务层按需分步查询：先查
SELECT * FROM category WHERE parent_id = ?，拿到二级 ID 列表后再查三级，避免大宽表 JOIN 导致的笛卡尔积膨胀 - 如果必须单次返回可筛选的全量层级结构，给分类表加
path字段（如/1/5/23/），用字符串前缀匹配替代 JOIN，索引友好且查询稳定
商品表与多级分类关联时，该连哪一层的 category_id？
常见错误是让 product.category_id 直接连到最末级类目，然后在筛选时反复 JOIN 向上找父类——这会导致每次筛选都要走 N 层 JOIN，性能断崖式下跌。更糟的是，有些商品可能属于多个叶子类目（比如“iPhone 15”同时挂在“智能手机”和“苹果手机”下），硬连单个 ID 就失去灵活性。
实操建议：
- 商品-类目关系必须拆成独立关联表
product_category，用多对多结构承载归属关系 - 筛选时不要从商品反推类目层级，而是先用 CTE 或子查询算出目标类目集合（含所有子孙节点），再用
IN (SELECT category_id FROM ...)关联商品 - 对高频筛选路径（如“全部手机 → 旗舰机 → iOS”）可预计算并缓存
category_id_set字段到商品表，用 JSON 或逗号分隔字符串存储，配合生成列 + 函数索引加速
MySQL 5.7 没有 WITH RECURSIVE，怎么安全实现无限级分类筛选？
MySQL 5.7 是很多老电商系统的现实约束，强行模拟递归容易写出 N+1 查询或临时表爆内存。直接用多次 JOIN 又受限于最大 JOIN 数（默认 61），且无法应对深度突变。
实操建议：
- 用存储过程 + 临时表：先插入根类目，循环
INSERT INTO tmp_cat SELECT id FROM category WHERE parent_id IN (SELECT id FROM tmp_cat)，直到影响行为 0 - 应用层控制递归深度，限制最多展开 4 级，超出则提示“请缩小筛选范围”，比数据库卡死更可控
- 把类目树快照定期导出为 JSON 文件，由后端服务加载进内存做树遍历，SQL 只负责查商品，分离读写压力
多级分类筛选真正的复杂点不在 SQL 写法，而在于“哪些数据该放库内实时算、哪些该离线预热、哪些该交给前端懒加载”。一旦忽略这个边界，再漂亮的 JOIN 也会在百万商品+十万类目时拖垮整个搜索链路。
