3

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

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

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

该节点包含以下内容：

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

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

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

我对执行计划相当陌生

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

问候

标记

4

1 回答 1

1

一些变量可以有排序规则：在此处输入链接描述

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

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

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

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

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

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

alter table Products 添加约束 uckProducts_ProductNumber unique(ProductNumber)

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

会很好的。

于 2013-01-16T04:18:22.217 回答