gpt4 book ai didi

performance - CHARINDEX 与 LIKE 搜索给出了非常不同的性能,为什么?

转载 作者:行者123 更新时间:2023-12-04 03:20:05 26 4
gpt4 key购买 nike

我们使用 Entity Framework 进行数据库访问,当我们“思考” LIKE 语句时 - 它实际上会生成 CHARINDEX 内容。因此,在我简化它们以在我们的特定服务器上证明一个点之后,这里有 2 个简单的查询:

-- Runs about 2 seconds
SELECT * FROM LOCAddress WHERE Address1 LIKE '%1124%'
-- Runs about 16 seconds
SELECT * FROM LOCAddress WHERE ( CAST(CHARINDEX(LOWER(N'1124'), LOWER([Address1])) AS int)) = 1

表现在包含大约 100k 条记录。 Address1 是 VarChar(100) 字段,没什么特别的。

这是并排的2个计划的片段。没有任何意义,显示 50% 和 50% 但执行时间像 1:8
enter image description here

我在网上搜索,一般建议是使用 CHARINDEX 而不是 LIKE。根据我们的经验,情况正好相反。我的问题是什么导致了这种情况以及我们如何在不更改代码的情况下解决它?

最佳答案

我将回答我自己的问题,因为很难找到正确的答案,并且 SQL Server 2012 执行计划输出指出了我的问题。正如您在原始问题中看到的那样 - 表面上看起来一切正常。这是 SQL Server 2008。

当我在 2012 年运行相同的查询时,我在 CHARINDEX 上收到警告询问。问题是 - SQL Server 必须进行类型转换。 Address1VarChar并且查询有 N'1124' 是 Unicode 或 NVarChar .如果我这样更改此查询:

SELECT * 
FROM LOCAddress
WHERE (CAST(CHARINDEX(LOWER('1124'), LOWER([Address1])) AS int))

然后它和 LIKE 一样运行。询问。因此,由 Entity Framework 生成器引起的类型转换导致了这种可怕的性能损失。

关于performance - CHARINDEX 与 LIKE 搜索给出了非常不同的性能,为什么?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/32788227/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com