推荐用 path 字段存储层级路径，如 'a/3/2/05'，避免闭包表或递归 cte；建 binary 索引，应用层拼接与解析，前缀匹配查询，批量更新保障一致性。
用 path 字段存层级路径，别硬套闭包表或递归 CTE
MySQL 5.7 及更早版本不支持标准递归查询，WITH RECURSIVE 在 8.0+ 才稳定可用。仓库库位天然有深度（如“A区→3排→2层→05号”），强行用父子 ID 关联查多级路径，每次都要 JOIN 多次，性能差、代码绕、分页也难做。
直接在库位表加一个 path 字段（例如 'A/3/2/05'），用斜杠分隔，所有层级信息一目了然：
CREATE TABLE `warehouse_location` ( `id` INT PRIMARY KEY, `code` VARCHAR(32) NOT NULL, `path` VARCHAR(255) NOT NULL COMMENT '如 A/3/2/05', `level` TINYINT NOT NULL COMMENT '共几级，方便快速过滤' );
-
path建BINARY或utf8mb4_bin索引，避免大小写或前导空格干扰匹配 - 插入时由应用层拼接，不是靠数据库触发器生成——否则迁移、修复数据时容易失控
- 查某一层级全部库位？用
WHERE path LIKE 'A/3/%' AND level = 4，比连表快一个数量级
查询子树必须用 LIKE + 前缀匹配，别用 FIND_IN_SET
FIND_IN_SET 只能查单个节点是否在逗号分隔字符串里，对路径完全无效。想查“A区下所有库位”，本质是前缀匹配问题。
正确写法是：
SELECT * FROM warehouse_location WHERE path LIKE 'A/%';
- 确保
path字段开头没有空格，否则'A/%'匹配不到' A/3/2/05' - 如果路径含特殊字符（如
+、%），需转义：用ESCAPE '\'并在LIKE中写成'A\%/3\%' ESCAPE '\' - MySQL 8.0+ 可考虑生成列 + 函数索引：
ALTER TABLE warehouse_location ADD COLUMN path_prefix VARCHAR(64) STORED AS (SUBSTRING_INDEX(path, '/', 2))，再对path_prefix建索引，加速二级筛选
更新路径时要批量重写，不能只改一级
库位调整很常见：比如把 “B/1/1/01” 整排挪到 “C/2/1/01”。如果只改 parent_id 或只改第一段，path 就断了，后续所有基于路径的查询都会漏数据或错乱。
- 必须用应用逻辑完整重算新
path，例如从 “B/1/1/01” → “C/2/1/01”，不能只替换首段 - 涉及移动整棵子树（如整排搬迁），先查出所有
path LIKE 'B/1/%'的记录，再用字符串替换批量更新，避免逐条 UPDATE - 操作前加事务，失败则回滚；生产环境建议加
SELECT ... FOR UPDATE锁住相关行，防并发修改冲突
导出 Excel 或对接 WMS 时，path 要可逆解析成字段
实际业务中，报表常要拆出“区域”“排”“层”“编号”四列。别在 SQL 里用 SUBSTRING_INDEX 套四层——可读性差、MySQL 5.7 不支持窗口函数、一旦层级变深就崩溃。
推荐做法：应用层解析 path 字符串，按 / 切分后映射到字段。示例 Python 片段：
parts = location['path'].split('/')
area, row, shelf, pos = parts[0], parts[1], parts[2], parts[3] if len(parts) > 3 else ''- 前端展示或导出时，直接用这四个变量拼表格，比数据库里硬拆安全得多
- 如果必须 SQL 导出，定义视图时用
SUBSTRING_INDEX(path, '/', 1)等，但仅限固定层级场景；层级不统一时，视图会出空值 - 注意：路径末尾不要加斜杠（如
'A/3/2/05/'），否则split('/')会产生空字符串，容易引发越界错误
路径设计看着简单，真正麻烦的是层级变动和跨系统同步——只要 path 字段被其他系统（比如 PLC 或扫码枪固件）直接读取，任何格式微调都得全链路对齐。
