小编Dan*_*lam的帖子

我最近在做一些性能测试时注意到了这一点。当我将一个值插入到需要隐式转换（例如bigintinto nvarchar）的列中时，我收到一条警告：

表达式中的类型转换(CONVERT_IMPLICIT(nvarchar(50),[tempdb].[dbo].[#MyFunIntTable].[EvenCoolerColumn],0))可能会影响查询计划选择中的“基数估计”。

作为一个关心的公民，我检查了所有明显的嫌疑人，并最终深入研究了 XML 以确认它实际上是关于插入表的警告。问题是，我无法弄清楚为什么这会影响基数估计。如果我在连接中或在具有更多逻辑的地方执行此操作，那将是有道理的，但是实际插入操作不应该存在基数估计不匹配，对吗？

我注意到当它不仅仅是一个简单的查询时会发生这种情况 - 只要插入了多个值，或者我们从表中提取一个值，我们就会点击这个。

这个问题吸引了一些潜在的重复，包括：

• 为什么我会得到从 Int / Smallint 到 Varchar 的隐式转换，它真的会影响基数估计吗？
• 表达式中的类型转换可能会影响查询计划选择中的“CardinalityEstimate”？

我认为它与这些问题不同，因为我实际上没有对这个专栏做任何事情。我没有在过滤器、排序、分组、连接或函数中使用它 - 这些东西中的任何一个都会使场景变得更加复杂。我所做的只是将 a 插入bigint到 a 中nvarchar，这永远不会影响我能想到的有意义的基数估计。

我特别想从答案中寻找的是：

1. 解释为什么我在没有任何兴趣的情况下收到此警告 - 是否只是 SQL Server 会保守并报告，即使它不会影响计划选择？
2. 什么基数估计在这里实际上存在风险，基于该基数估计的不准确性，哪些操作会发生变化？
3. 是否存在这会影响计划选择的情况？显然，如果我开始加入或过滤转换后的列，它可以，但按原样？
4. 除了更改数据类型（假设这是数据模型交互方式的要求）之外，还有什么可以防止它发出警告的吗？

我用下面的简单例子重新创建了它（粘贴计划）

DROP TABLE IF EXISTS #MyFunStringTable;
DROP TABLE IF EXISTS #MyFunIntTable;

CREATE TABLE #MyFunStringTable
(
  SuperCoolColumn nvarchar(50) COLLATE DATABASE_DEFAULT NULL
);

CREATE TABLE #MyFunIntTable
(
  EvenCoolerColumn bigint NULL
);

INSERT INTO #MyFunIntTable
( EvenCoolerColumn …