MySQL无限级分类最实用方案是用parent_id字段配合应用层逻辑实现：表含id、name、parent_id三字段，根节点parent_id设为0并加索引，排序靠sort_order字段，导航栏按需分步查询+细粒度Redis缓存。
用 parent_id 实现无限级分类最实用
MySQL 本身不支持递归查询（8.0 以前），所以“无限级分类”不是靠某个函数自动展开，而是靠 parent_id 字段 + 应用层逻辑配合完成。别指望一条 SQL 拉出整棵树——那是 PostgreSQL 的 WITH RECURSIVE 干的事，MySQL 得自己控制层级和顺序。
典型表结构就三字段：id、name、parent_id，其中根分类的 parent_id 设为 0 或 NULL（推荐 0，避免 NULL 判断干扰）。
-
parent_id必须加索引，否则查子类时WHERE parent_id = ?会全表扫描 - 别用自增主键当排序依据，分类顺序得靠额外字段如
sort_order - 前端导航栏一般只展示 2–3 级，没必要一次性加载全部层级，按需查更稳
查一级分类 + 各自二级分类的写法
商城首页顶部导航常见需求：显示所有一级分类，鼠标悬停时拉出对应二级分类。这不是树形遍历，而是两步查：先查 parent_id = 0，再对每个一级分类查它的子类。
不要写成 JOIN 或子查询试图“一步到位”，容易因数据量大导致笛卡尔积或慢查询。稳妥做法是：
- 第一步：
SELECT id, name FROM category WHERE parent_id = 0 ORDER BY sort_order - 第二步：对每个返回的
id，执行SELECT id, name FROM category WHERE parent_id = ? ORDER BY sort_order - 如果怕 N+1，可用
IN批量查二级：SELECT * FROM category WHERE parent_id IN (1,2,5,8)，但要注意IN列表长度限制（默认 max_allowed_packet 影响）
误用 path 字段或 closure table 的代价
有人看到“无限级”就想上 path（如 "0/1/5/23"）或闭包表（category_closure），这在后台管理批量移动分类时确实方便，但对前台导航是过度设计。
问题在于：
-
path字段无法走索引做前缀匹配（LIKE '0/1/%'是全表扫描），查某分类下所有子孙性能差 - 闭包表要维护父子关系的每一对组合，插入/移动分类时需大量写操作，电商大促期间容易成为瓶颈
- 导航栏几乎不涉及“查某个分类的所有后代”，只关心“当前分类的直接子类”，
parent_id完全够用
缓存必须做，且不能只缓存一级
分类数据变更是低频的（运营改个名字、上下架），但读请求极高。不做缓存，每次页面打开都查数据库，QPS 上去后 parent_id 索引也扛不住。
关键点是：缓存粒度得细到“每个父 ID 对应的子列表”，而不是整个分类表 dump 一份。
- 用 Redis 存
category:children:0、category:children:1这样的 key，过期时间设长些（比如 1 小时） - 运营修改分类时，主动删掉相关 key，比如改了 ID=5 的分类，就删
category:children:0和category:children:5 - 别图省事缓存整棵树 JSON，一旦某节点变动，整个缓存失效，更新成本高还容易不一致
真正麻烦的是三级以后的懒加载（比如点击二级才拉三级），这时候既要防重复请求，又要处理并发更新缓存的竞争——这些细节比表结构本身更容易出问题。
