tsql - 2 varchars 之间的 T-SQL 隐式转换

Question

我有一些我继承的 T-SQL (SQL Server 2008)，我试图找出为什么有些查询运行得非常慢。在 Actual Execution Plan 中，我进行了三个聚簇索引扫描，分别花费了 19%、21% 和 26%，所以这似乎是我问题的根源。

字段的内容通常是数字(但有些工作编号有字母前缀)

数据库设计(供应商提供)非常糟糕。他们的应用程序中作业编号的最大长度为 12 个字符，但在连接的表中，它在某些地方被定义为 varchar(50) 和 varchar(15) 在其他方面。我的参数是 varchar(12)，但如果我将它更改为 varchar(50)

，我会得到同样的结果

节点包含这个:

Predicate: [Live_Costing].[dbo].[TSTrans].[JobNo] as [sts1].[JobNo]=CONVERT_IMPLICIT(varchar(50),[@JobNo],0)

sts1 是一个派生表，但它从中提取 jobno 的表是一个 varchar(50)

我不明白为什么要在 2 个 varchar 之间进行隐式转换。仅仅是因为它们的长度不同吗？

我对执行计划还很陌生

有没有一种简单的方法可以找出执行计划中的哪个节点与查询的哪个部分相关？是谓词，连接子句？

问候

标记

Answer 1

一些变量可以有排序规则:enter link description here

无论您需要验证排序规则，都可以在服务器、数据库、表和列级别指定。

首先，检查 tempdb 和供应商提供的数据库之间的排序规则。它应该匹配。如果没有，它将倾向于进行隐式转换。

假设您无法修改供应商提供的代码库，以下一项或多项应该可以帮助您:1) 预定义临时表并为关键字段指定与正在使用的数据库相同的排序规则，而不是 tempdb。2) 在进行字符串比较时提供排序规则。3) 如果对临时表使用“select into”，则指定键值的排序规则4) 确保表和列的排序规则与数据库排序规则相匹配(如果您仅将供应商的特定表导入现有数据库，这一点非常重要。)

如果您可以更改供应商提供的代码库，我建议您查看使所有字符键长度相同而不是 varchar 的成本。 Varchar 有 10 的开销。需要注意的是，如果您创建一个非空的固定长度字符字段，它将被填充到右侧(不可避免)。

理想情况下，您将拥有 int 键，并且仅使用 varchar 字段进行用户交互/查找:

创建表 Products(ProductID int not null identity(1,1) primary key clustered, ProductNumber varchar(50) not null)

改变表产品添加约束 uckProducts_ProductNumber unique(ProductNumber)

然后在 ProductID 而不是 ProductNumber 上进行所有联接。只需过滤 ProductNumber。

会非常好。