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

Question

在SQL Server 2017 Developer Edition上运行。

我有一个简单的例子，我试图取两个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和VERB选择到单个列NUMBER中：

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：为清楚起见，我添加了有关场景的更多细节，例如create table DDL和添加了一些insert语句。

Answer 1

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

有一个连接项“表达式中的新类型转换...... SQL2012中的警告，太嘈杂到实际使用”，其中微软回应

我明白你的意思了。虽然我同意在大多数情况下这是噪音，但我们要优先考虑。如果我们得到更多反馈，我们会考虑一下。现在我已经通过设计关闭了它

当连接关闭时，这会丢失。关于UserVoice site here的类似投诉。

当转换/转换列在选定/预计列列表中被简单引用而在过滤子句中根本不被引用时，它似乎是一种超越。

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

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

但我不推荐这个。 FORMAT有自己的问题（性能）和应用不必要的FORMAT使代码可读性降低。