我应该担心会用完HierarchyID吗？

Question

当您请求在两个其他HierarchyID之间创建新的the时，结果会逐渐变长。例如，在2/5.6和2/5.7之间，只有2/5.6.1和其他4个组件路径。HierarchyID数据类型被限制为800字节，因此您不能永远重复此操作。同样，整数类型也是有限的，但这在实践中并不是问题。我是否应该定期整理我的表的碎片，这样高度就不会无限增长？

Answer 1

对于hierarchyid来说，“附加”新的It被认为是一种“最佳实践”，这样您就根本不需要使用这些中间状态(比如/2/5.6/)。如果您的hierarchyid是一个聚集主键，那么这对性能是不利的，它将导致类似于uniqueidentifier的页面拆分。

如果您生成连续的子代，则不太可能需要担心耗尽资源；实际上，每个父代都可能有数百万个子代。

Here是一个如何生成hierarchyid值的示例：

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION 
    UPDATE Hierarchy
    SET @LastChild = LastChild = HId.GetDescendant(LastChild, NULL)
    WHERE HId = @ParentID

    INSERT Hierarchy (HId, ...)
    VALUES (@LastChild, ...)
COMMIT

如果您以这种方式生成ids，请放心，您永远不必担心耗尽资源。

出于好奇心，我运行了一个快速测试，以确定您可以深入到什么程度。下面是一个测试脚本：

DECLARE
    @parent hierarchyid,
    @child hierarchyid,
    @high hierarchyid,
    @cnt int

SET @parent = '/1/'
SET @child = @parent.GetDescendant(NULL, NULL)
SET @cnt = 0

WHILE (@@ERROR = 0)
BEGIN
    SET @cnt = @cnt + 1
    PRINT CAST(@cnt AS varchar(10)) + ': ' + @child.ToString()
    SET @high = @parent.GetDescendant(@child, @high)
    SET @child = @parent.GetDescendant(@child, @high)
END

您可以看到它在点嵌套级别1426的错误，所以这是您可以创建的“中间”节点的最坏情况限制，最坏情况意味着每个插入都位于两个嵌套最深的节点之间。

正如我在评论中提到的，很难达到这个极限，但这仍然不是一个好主意。当你使用越来越多的“点”时，实际的字节长度会变得越来越长，这会降低性能。如果hierarchyid是您的聚集索引，这将降低页面拆分的性能。如果您尝试按父级对节点进行排序，那么请改用排名列；与在INSERT期间进行排序相比，从较晚的SELECT进行排序更容易、效率更高，因为您必须担心事务隔离和其他类似的问题。