INT 列的连接警告：表达式中的类型转换导致执行计划中的 CardinalityEstimate 警告

Question

在 SQL Server 2017 开发人员版上运行。

我有一个简单的案例，我试图获取两个 INT 列并将它们连接成一个名为“NUMVER”的列，用分号分隔。尽管我可以重构应用程序中的内容以不同方式执行此操作，但如果可以不重构并更改语法以使其不会引发“！”，将会很有趣。执行计划中的警告。

详情：

名为“DOCS”的表具有列 NUM 和 VER，它们都是 INT 加上一个 PK：

CREATE TABLE [dbo].[DOCS2](
    [DOCS_ID] [int] IDENTITY(1,1) NOT NULL,
    [NUM] [int] NOT NULL,
    [VER] [int] NOT NULL,
 CONSTRAINT [PK_DOCS] PRIMARY KEY CLUSTERED ([DOCS_ID] ASC)
)
GO

一些数据：

INSERT INTO dbo.DOCS (NUM, VER) VALUES (1,1);
INSERT INTO dbo.DOCS (NUM, VER) VALUES (2,1);

我想用分号分隔符将 NUM 和 VER 选择到单列 NUMVER 中：

SELECT CAST(NUM AS varchar(20)) + ';' + CAST(VER AS varchar(20)) AS "MENU" FROM DOCS;

返回结果很好，我得到“1;1”或“2;1”等，但我收到关于执行计划的警告：

表达式中的类型转换 (CONVERT(varchar(20),[mydb].[dbo].[DOCS].[NUM],0)) 可能会影响查询计划选择中的“CardinalityEstimate”，表达式中的类型转换 (CONVERT (varchar(20),[mydb].[dbo].[DOCS].[VER],0)) 可能会影响查询计划选择中的“CardinalityEstimate”

上面的示例是一个更复杂、非常繁忙的表的简化示例，如果这是一个微不足道的警告，我会继续前进，但我希望得到“！”如果可能的话消失？

注意：我没有观察到性能问题，我只是在积极主动（或者可能过于好奇和谨慎）。

注2：为了清楚起见，我添加了有关该场景的更多细节，例如创建表DDL并添加了一些插入语句。

Answer 1

操作词是可能。在这种情况下，这不会影响基数估计，因为该列只是被选中，并未用于任何可能影响估计的过滤或分组操作。

有微软回应了一个连接项“表达式中的新类型转换.....警告在 SQL2012 中，噪音太大而无法实际使用”

我明白你的意思。虽然我同意这在大多数情况下都是噪音， 这是我们修复的低优先级。如果我们得到更多，我们会看看它 回馈。现在我已经按设计关闭了它

连接关闭时丢失。 UserVoice site here 也有类似的投诉。

当转换/转换列很简单时，这似乎是一个过度 在选定/预计的列列表中引用，而不是在 过滤子句。

有可能跳过一些箍来摆脱它。例如

SELECT FORMAT(NUM, 'N0') + ';' + FORMAT(VER, 'N0') 
FROM [DOCS2];

但我不建议这样做。 FORMAT 有其自身的问题（性能方面），应用不必要的 FORMAT 会使代码的可读性降低。