表达式中的类型转换可能会影响查询计划选择中的“CardinalityEstimate”?

Iai*_*der 11 sql-server optimization cardinality-estimates

我维护一个存档数据库,该数据库将历史数据存储在分区视图中。分区列是日期时间。视图下的每个表存储一个月的数据。

我们使用日期时间列上的检查约束来约束每个表上的事件。这允许优化器限制为在事件日期时间列上过滤的查询而搜索的表。

检查约束的名称是由 SQL Server 生成的,因此通过查看名称很难知道它们的作用。

我希望约束名称的形式为“CK_TableName_Partition”。

我可以使用此查询生成重命名脚本并从 sql_text 列复制数据。WHERE 子句匹配名称看起来像是由 SQL Server 生成的检查约束:

SELECT
  checks.name AS check_name,
  tabs.name AS table_name,
  skemas.name AS schema_name,
  cols.name AS column_name,
  N'
EXECUTE sys.sp_rename
  @objname = N''' + skemas.name + N'.' + checks.name + N''',
  @newname = N''CK_' + tabs.name + N'_Partition'',
  @objtype = ''OBJECT'';' AS sql_text
FROM sys.check_constraints AS checks
INNER JOIN sys.tables AS tabs ON
  tabs.object_id = checks.parent_object_id
INNER JOIN sys.schemas AS skemas ON
  skemas.schema_id = tabs.schema_id
INNER JOIN sys.columns AS cols ON
  tabs.object_id = cols.object_id AND
  cols.column_id = checks.parent_column_id
WHERE checks.name LIKE (
  N'CK__' + SUBSTRING(tabs.name, 1, 9) +
  N'__' + SUBSTRING(cols.name, 1, 5) +
  N'__' + REPLACE(N'xxxxxxxx', N'x', N'[0-9A-F]') COLLATE Latin1_General_BIN2
)
ORDER BY table_name;
Run Code Online (Sandbox Code Playgroud)

输出如下所示:

check_name  table_name  schema_name column_name sql_text
CK__tbAcquisi__Acqui__5C4299A5  tbAcquisitions_201301   Archive AcquisitionDT   EXECUTE sys.sp_rename  @objname = N'Archive.CK__tbAcquisi__Acqui__5C4299A5',  @newname = N'CK_tbAcquisitions_201301_Partition',  @objtype = 'OBJECT';
CK__tbAcquisi__Acqui__76026BA8  tbAcquisitions_201302   Archive AcquisitionDT   EXECUTE sys.sp_rename  @objname = N'Archive.CK__tbAcquisi__Acqui__76026BA8',  @newname = N'CK_tbAcquisitions_201302_Partition',  @objtype = 'OBJECT';
CK__tbAcquisi__Acqui__7D6E8346  tbAcquisitions_201303   Archive AcquisitionDT   EXECUTE sys.sp_rename  @objname = N'Archive.CK__tbAcquisi__Acqui__7D6E8346',  @newname = N'CK_tbAcquisitions_201303_Partition',  @objtype = 'OBJECT';
...
CK__tbRequest__Reque__60132A89  tbRequests_201301   Archive RequestDT   EXECUTE sys.sp_rename  @objname = N'Archive.CK__tbRequest__Reque__60132A89',  @newname = N'CK_tbRequests_201301_Partition',  @objtype = 'OBJECT';
CK__tbRequest__Reque__1392CE8F  tbRequests_201302   Archive RequestDT   EXECUTE sys.sp_rename  @objname = N'Archive.CK__tbRequest__Reque__1392CE8F',  @newname = N'CK_tbRequests_201302_Partition',  @objtype = 'OBJECT';
CK__tbRequest__Reque__1AFEE62D  tbRequests_201303   Archive RequestDT   EXECUTE sys.sp_rename  @objname = N'Archive.CK__tbRequest__Reque__1AFEE62D',  @newname = N'CK_tbRequests_201303_Partition',  @objtype = 'OBJECT';
Run Code Online (Sandbox Code Playgroud)

查询的结果似乎是正确的,服务器执行得很快。

但是执行计划的根节点有一个警告:

表达式中的类型转换 (CONVERT_IMPLICIT(nvarchar(128),[o].[name],0)) 可能会影响查询计划选择中的“CardinalityEstimate”

在这种情况下,这意味着什么?如此复杂的过滤器会让优化器感到困惑吗?这是我应该担心的事情吗?

Pau*_*ite 17

查询的结果似乎是正确的,服务器执行得很快。

但是执行计划的根节点有一个警告:

表达式中的类型转换 (CONVERT_IMPLICIT(nvarchar(128),[o].[name],0)) 可能会影响查询计划选择中的“CardinalityEstimate”

在这种情况下,这意味着什么?如此复杂的过滤器会让优化器感到困惑吗?这是我应该担心的事情吗?

该警告是信息性的。如果您的查询执行缓慢,或者您注意到基数估计不正确,警告将提供有关在哪里寻找可能原因的信息。

该警告由用于排序规则更改的隐式转换触发。如果使用排序规则是获得正确结果的最简单方法,请保持原样。或者,如果您详细解释为什么需要它,有人会建议您。

顺便说一句,REPLACE可以替换为:

REPLICATE(N'[0-9A-F]', 8);
Run Code Online (Sandbox Code Playgroud)

(此答案是对该问题的评论的摘要。)