json - OPENJSON 性能不佳，CROSS/OUTER APPLY 和数百万行

Question

我有一个包含数百万行和三个相关列的表:

CREATE TABLE [EventSourcing].[EventsTableCompressed](
    [DocumentKey] [nvarchar](200) NOT NULL,
    ...
    [JsonCompressed] [varbinary](max) NOT NULL,
    [JsonDecompressed]  AS (CONVERT([nvarchar](max),Decompress([JsonCompressed]))),
 CONSTRAINT [PK_EventsTableCompressed] PRIMARY KEY CLUSTERED 
(
    [DocumentKey] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

当我使用集群索引执行搜索时，搜索速度如预期的那样快，示例:

SELECT 
DocumentKey,
JSON_VALUE(JsonDecompressed, '$.MyJsonProperty') as MyJsonProperty
FROM  [EventSourcing].[EventsTableCompressed] C
where DocumentKey> 'RangeInit' and DocumentKey< 'RangeEnd'

返回的行或多或少超过 100 亿，并且 IO 是最小的(如预期的那样)

但是，如果我尝试使用 CROSS APPLY OPENJSON 或 OUTER APPLY OPENJSON 完成查询，性能一点也不好(提取 100 行需要 1 分钟)

SELECT DocumentKey,  JSON_VALUE(JsonDecompressed, '$.CreditUid') as CreditUid
FROM  [EventSourcing].[EventsTableCompressed] C  
OUTER APPLY OPENJSON (C.JsonDecompressed, '$.MyArrayInsideTheJson') as J
where DocumentKey> 'RangeInit' and DocumentKey< 'RangeEnd'

检查查询计划，我在这两种情况下都有相同的情况，大部分时间都使用集群索引查找。但是，在 Profiler 工具中，我可以在第二个查询中看到一个非常大的读和写数。

我想知道这种行为的原因。似乎 APPLY 正在所有行上执行，而不仅仅是 where 子句过滤的行。是这样吗？

Answer 1

禁用数据库中的统计信息可以防止错误。似乎，第一次，统计数据必须更新或类似的东西(这就是高容量或写入的原因)。