sql - LIKE SQL 中的解决方法(性能问题)

Question

我一直在阅读并发现使用 LIKE 会导致查询速度大大减慢。

一位同事推荐我们使用

Select Name
From mytable
a.Name IN (SELECT Name 
           FROM mytable
           WHERE Name LIKE '%' + ISNULL(@Name, N'') + '%' 
           GROUP BY Name)

代替

Select Name
From mytable
a.Name LIKE '%' + ISNULL(@Name, N'') + '%'

现在我不是 SQL 专家，我并不真正理解这些语句的内部工作原理。这是一个更好的选择，值得在每个类似的语句中键入一些额外的字符吗？有更好的(并且更容易输入)替代方案吗？

Answer 1

有几个性能问题需要解决...

如果可能，不要多次访问同一个表

不要对无需引用同一个表的其他副本即可完成的条件使用子查询。如果由于使用聚合函数(MAX、MIN 等)而需要来自表副本的数据，这是可以接受的，但分析函数(ROW_NUMBER、RANK 等)可能更适合(假设支持)。

不要比较不需要的东西

如果您的参数为 NULL，这意味着您想要比较的列的任何值，请不要包含过滤条件。像这样的陈述:

WHERE a.Name LIKE '%' + ISNULL(@Name, N'') + '%'

...保证优化器必须比较 name 列的值，无论是否使用通配符。在使用 LIKE 的情况下，更糟糕的是，对求值左侧进行通配会确保索引存在于正在搜索的列中时无法使用。

性能更好的方法是:

IF @Name IS NOT NULL 
BEGIN
   SELECT ...
     FROM ...
    WHERE a.name LIKE '%' + @Name + '%'
END
ELSE 
BEGIN
   SELECT ...
     FROM ...
END

性能良好的 SQL 就是根据您的需要进行定制。这就是为什么你should be considering dynamic SQL when you have queries with two or more independent criteria .

使用正确的工具

当您检查文本数据中是否存在字符串时，LIKE 运算符在搜索文本方面效率不高。 Full Text Search (FTS) technology旨在解决以下缺点:

IF @Name IS NOT NULL
BEGIN
   SELECT ...
     FROM ...
    WHERE CONTAINS(a.name, @Name) 
END
ELSE
BEGIN
   SELECT ...
     FROM ...
END

始终测试和比较

我同意 LittleBobbyTables 的观点 - 该解决方案最终依赖于检查所有替代方案的查询/执行计划，因为表设计和数据会影响优化器决策和性能。在 SQL Server 中，子树成本最低的树是最高效的，但如果不维护表统计信息和索引，它可能会随着时间而改变。