在触发器中获取父节点Path需显式JOIN原表查询，根节点ParentCategoryID为NULL时Path应设为'/ID/'，UPDATE需检测父级变更并递归更新子树Path，且须分批处理防锁表、建索引优化查询、手动校验环路。
触发器里怎么拿到父节点的 Path 值？
INSERT 触发器中不能直接用 SELECT Path FROM inserted 获取父路径，因为 inserted 表只含新行数据，不含其父节点。必须显式 JOIN 原表查父级：SELECT p.Path FROM inserted i LEFT JOIN Category p ON i.ParentCategoryID = p.CategoryID。漏掉这步，Path 就会是 NULL 或空字符串。
AFTER INSERT 触发器必须检查 ParentCategoryID 是否为 NULL
根节点的 ParentCategoryID 是 NULL，此时 Path 应设为自身 ID（如 '/1/'），不能拼接父路径。常见错误是硬写 CONCAT(p.Path, i.CategoryID, '/')，导致根节点路径变成 NULL1/。正确做法是用 ISNULL(p.Path, '/') 或 CASE WHEN i.ParentCategoryID IS NULL THEN CONCAT('/', i.CategoryID, '/') ELSE ... END。
UPDATE 触发器要同时处理 ParentCategoryID 和 Path 变更
用户可能只改了父节点，但忘了更新子树所有后代的 Path；也可能手动改了 Path 字段，绕过触发器逻辑。所以 UPDATE 触发器里必须：
- 用
EXISTS (SELECT 1 FROM deleted d WHERE d.CategoryID = i.CategoryID AND d.ParentCategoryID != i.ParentCategoryID)判断父级是否变动 - 对受影响的子树（包括自身）递归更新
Path，不能只更新当前行 - 加
WHERE i.Path != 新计算值避免无意义更新引发连锁触发
性能隐患：深层嵌套时递归更新会锁表太久
一个 20 层深、5000 个节点的分类树，移动根下某分支到另一父节点，可能触发上万行 UPDATE。SQL Server 默认事务会持锁直到结束，容易阻塞其他读写。实际部署时建议：
- 把路径更新逻辑抽成存储过程，用
WHILE+TOP 100分批更新，避免单事务过大 - 在触发器里加
IF @@ROWCOUNT > 1000 BEGIN RAISERROR('路径变更影响过大，请用后台任务处理', 16, 1); ROLLBACK; RETURN; END -
Path字段务必建索引——但注意，前缀索引（如Path LIKE '/1/%'）在 SQL Server 上无法走索引查找，得用LIKE '1/%'配合函数索引或计算列
触发器能自动维护路径，但无法替代对层级变更的业务校验；比如禁止把部门 A 移动到自己的子部门下，这种环路检测必须在触发器里手写递归 CTE 查询 DELETED 和原表，否则数据一致性就垮了。
