为什么在列存储索引部署后子选择筛选器失败？

Question

我在一个巨大的表上部署了一个列存储索引，整体性能提升非常显着，但是一个包含 where id in (subselect) 过滤的报告开始因数据类型不匹配而失败。 我检查了数据类型，错误消息没有任何意义。 当我回滚新索引时，查询运行没有任何错误。 玩了一下，发现如果我将 where -subselect 翻转为带有 string_split 的连接，它可以与索引一起使用。

你有没有经历过类似的事情？

先感谢您！

Answer 1

正如评论中提到的其他人，您必须在导致问题的数据中某处进行隐式转换。 需要显式转换数据并相应地处理异常

/*Raw data*/
DROP TABLE IF EXISTS #Test
CREATE TABLE #Test (ID INT IDENTITY(1,1) PRIMARY KEY, Val Varchar(100))
INSERT INTO #Test VALUES ('1'),('2'),('A')

/*Example of how index might "break" code aka expose implicit conversion issue*/

/*This select works*/
CREATE INDEX ix on #Test(Val)
SELECT TOP (1) * FROM #Test WITH (INDEX (ix)) WHERE Val = 2 /*Implicitly casts Val to int*/

/*Change index and run same query, it now tries to cast 'A' and breaks*/
CREATE INDEX ix on #Test(Val DESC) WITH (DROP_EXISTING = ON )
SELECT TOP (1) * FROM #Test WITH (INDEX (ix)) WHERE Val = 2

可能的解决方案

/*Need to explicitly cast so data types match*/
/*Can cast the search parameter (generally most performant as it allows use of indexes on source data)*/
SELECT TOP (1) * FROM #Test WHERE Val = Cast(2 AS Varchar(100)) /*Explicitly cast the parameter*/

/*Or use TRY_CAST to cast the source data. Might be needed if you have formatted data in the Val column*/
SELECT TOP (1) * FROM #Test WHERE TRY_CAST(Val AS INT) = 2