带参数的 SQL LIKE：巨大的性能损失

Question

我有这个问题：

select top 100 id, email, amount from view_orders
    where email LIKE '%test%' order by created_at desc

运行时间不到一秒。

现在我想参数化它：

declare @m nvarchar(200)
set @m = '%test%'
SELECT TOP 100 id, email, amount FROM view_orders
    WHERE email LIKE @m ORDER BY created_at DESC

5 分钟后，它仍在运行。对于任何其他类型的参数测试（如果我将“like”替换为“=”），它会下降到性能的第一个查询级别。

我使用的是 SQL Server 2008 R2。

我尝试过 OPTION(RECOMPILE) ，它下降到 6 秒，但仍然慢得多（非参数化查询是瞬时的）。由于这是一个我预计会经常运行的查询，因此这是一个问题。

表的列有索引，视图没有，不知道能不能有所作为。

视图连接了 5 个表：一个有 3,154,333 行（用户），一个有 1,536,111 行（订单），3 个最多有几十行（订单类型等）。搜索在“用户”表（有 3M 行）上完成。

硬编码值：

参数：

更新

我已使用SET STATISTICS IO ON 运行查询。结果如下（抱歉，我不知道怎么读）：

硬编码值：

表“货币”。扫描计数 1，逻辑读取 201。

表“订单状态”。扫描计数 0，逻辑读取 200。

表“付款”。扫描计数 1，逻辑读取 100。

表“礼物”。扫描计数 202，逻辑读取 404。

表“订单”。扫描计数 95，逻辑读取 683。

表“用户”。扫描计数 1，逻辑读取 7956。

参数：

表“货币”。扫描计数 1，逻辑读取 201。

表“订单状态”。扫描计数 1，逻辑读取 201。

表“付款”。扫描计数 1，逻辑读取 100。

表“礼物”。扫描计数 202，逻辑读取 404。

表“用户”。扫描计数 0，逻辑读取 4353067。

表“订单”。扫描计数 1，逻辑读取 4357031。

更新 2

此后我看到了“强制索引使用”提示：

SELECT TOP 100 id, email, amount
FROM view_orders with (nolock, index=ix_email)
WHERE email LIKE @m
ORDER BY created_at DESC

不确定它是否会起作用，我不再在这个地方工作了。

Answer 1

这可能是参数嗅探问题。 更好的索引或全文搜索是可行的方法，但您可能可以获得可行的折衷方案。 试试：

SELECT TOP 100 A, B, C FROM myview WHERE A LIKE '%' + @a + '%'
OPTION (OPTIMIZE FOR (@a = 'testvalue'));

（就像 Sean Coetzee 建议的那样，我不会在参数中传入通配符）

Answer 2

当您向 A 列添加索引时，您肯定会赢。 有时索引建议可以被 SQL Server 管理工作室借用。粘贴您的查询并按“显示估计的执行计划”按钮

Answer 3

CREATE INDEX index_name ON myview (A);
CREATE INDEX index_name ON myview (B);
CREATE INDEX index_name ON myview (C);

declare @a nvarchar(200)
set @a = '%testvalue%'
SELECT TOP 100 A, B, C FROM myview WHERE A LIKE @a

Answer 4

如果你尝试会发生什么：

set @a = 'test'
select top 100 A, B, C 
  from myview 
 where A like '%' + @a + '%'

我尝试了一些虚拟数据的测试，看起来它可能会更快。

Answer 5

参数化版本的估计执行计划显然不对。我不相信我见过两次估计成本为 100% 的查询！因为成本应该是100%。有趣的是，它认为当您清楚地按用户表上的某些内容进行过滤时，它需要从订单开始。

我会重建视图中引用的所有表的统计信息。

update statistics <tablename> with resample

对涉及的每个表执行其中一项。

您可以尝试直接运行 sql（将粘贴视图主体复制到 sql 中），既参数化又不查看是否是视图 sql 有问题。

最终，即使您解决了这个问题，它实际上也只是一个权宜之计。您有 300 万用户，每次运行查询 sql 都必须遍历所有 300 万条记录（顶部查询中的 75% 扫描）才能找到所有可能的记录。您获得的用户越多，查询速度就越慢。非全文索引不能用于前面带有通配符的类似查询。

在这种情况下，您可以将 sql 索引视为书籍索引。您可以使用带有单词“部分”的书籍索引来快速找到任何内容吗？不，您必须扫描整个索引才能找出所有可能性。

你真的应该考虑在你的视图上使用全文索引。