不可修复的空间索引损坏是否被视为正常现象？

我有一个空间索引用于该DBCC CHECKDB报告损坏：

DBCC CHECKDB(MyDB) 
WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY, NO_INFOMSGS, ALL_ERRORMSGS, TABLERESULTS

空间索引，XML索引或索引视图'sys.extended_index_xxx_384000'（对象ID xxx）不包含视图定义生成的所有行。这不一定代表此数据库中数据的完整性问题。

空间索引，XML索引或索引视图'sys.extended_index_xxx_384000'（对象ID xxx）包含视图定义未生成的行。这不一定代表此数据库中数据的完整性问题。

CHECKDB在表'sys.extended_index_xxx_384000'（对象ID xxx）中发现了0个分配错误和2个一致性错误。

维修等级为repair_rebuild。

删除并重新创建索引不会删除这些损坏报告。没有EXTENDED_LOGICAL_CHECKS但没有DATA_PURITY错误，则不会报告。

同样，CHECKTABLE此表花费45分钟，尽管它的CI大小为30 MB，大约有3万行。该表中的所有数据都是点geography数据。

在任何情况下都可以预期这种行为吗？它说：“这不一定代表完整性问题”。我应该做些什么？CHECKDB失败了，这是一个问题。

此脚本重现了该问题：

CREATE TABLE dbo.Cities(
    ID int  NOT NULL,
    Position geography NULL,
 CONSTRAINT PK_Cities PRIMARY KEY CLUSTERED 
(
    ID ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)

GO
INSERT dbo.Cities (ID, Position) VALUES (20171, 0xE6100000010C4E2B85402E424A40A07312A518C72A40)
GO
CREATE SPATIAL INDEX IX_Cities_Position ON dbo.Cities
(
    Position
)USING  GEOGRAPHY_AUTO_GRID 
WITH (
CELLS_PER_OBJECT = 16, PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO

这是版本12.0.4427.24（SQL Server 2014 SP1 CU3）。

我用表和数据脚本编写表，并使用新鲜的DB执行。同样的错误。CHECKDB还具有45分钟的惊人运行时间。我使用SQL Profiler捕获了CHECKDB查询计划。它具有错误引导的循环连接，显然导致过多的运行时间。该计划在表的行数中具有二次运行时间！双嵌套扫描循环联接。

清除所有非空间索引不会更改任何内容。

我无法立即在2014-12.0.4213.0上重现此内容，但在SQL Server 2016（CTP3.0）-13.0.700.242上确实看到了。

在2014年版本（无DBCC错误）上，该计划如下所示。

而在2016年的版本中（报告了 DBCC错误）。

第二个计划有一个从合并反半联接中出来的行，第一个计划为零行。

连接谓词pk0在与空间索引中的列匹配方面有所不同。

第一个将其正确映射到表主键，第二个将其映射到Id从TVF返回的列。

根据SQL Server 2012内部手册，这是单元格的希尔伯特数的binary（5）值，因此该谓词当然是不正确的（如果基表中单行的ID设置为1052031049而不是20171，我否不再看到任何DBCC错误，因为它恰好与此的值相对应0xa03eb4b849。

在2014-12.0.4213.0中，按如下所示重新创建表格后，我可以重现该问题。

CREATE TABLE dbo.Cities(
    Id int  NOT NULL,
    Position geography NULL,
 CONSTRAINT PK_Cities PRIMARY KEY CLUSTERED 
(
    Id ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)

（请注意从更改ID为Id）

我的2014实例安装了区分大小写的排序规则。因此，看来这可能以前防止了列混淆。

所以我想一个潜在的解决方法可能是将列重命名Cities为CityId例如。

连接项（Microsoft错误报告）