Question

我正在查询从表中搜索结果，如果一行匹配特定对象，它将提供结果。

所以，这是一个12个字母的数字。

所以功能是如果用户提供了一个数字为414.it将搜索'％414％'。

如果数字长度超过6位，则会搜索“4146144％”

因此，由于我们拥有2000万条记录，因此查询速度变慢了。

请你帮我解决这个问题。

公司不允许使用任何API或其他任何内容。

 SELECT  distinct TOP (15) bt_id AS [Key]
       , UPPER(rtrim(ltrim(bt_id)))+' - '+UPPER(rtrim(ltrim(bt_desc))) AS [Description]   
 FROM    fcbillto 
 WHERE   bt_id   like '%' + @SearchTerm + '%'
 OR      bt_desc like '%' + @SearchTerm + '%'

如果全文扫描是解决方案，我可以为单个表创建两个不同的目录，因为上面是我需要搜索的列之一，而在其他情况下我正在搜索同一个表的其他列。所以，我需要创建两个存储库。

Answer 1

您有两个问题阻碍了查询的有效使用：

1）OR条款。 SQL不能在bt_id或bt_desc上使用带有OR子句的索引，因为使用索引过滤一列可能会淘汰符合另一列谓词的有效行。如果您在两个列上都有索引，则可以使用UNION来获取符合这两个条件的行（或者如果您很幸运，优化器可能会在引擎盖下执行此操作），但索引可能不会被用作事物的原因是因为......

2）具有前导LIKE的{{1}}无法在索引上搜索，因为索引是根据前导字符排序的。如果必须在字符串中间查找字符，则它不能使用索引来搜索行。（这并不意味着它不会扫描索引，因为它比表本身小 - 所以在此基础上可能仍会有性能改进。）

因此，如果不改变要求，可能很难看到真正的性能改进。如果您可以更改要求以使搜索仅在前导字符上（或限制另一个索引列上的查询），那么这将更快（假设%和bt_id上的索引）：

bt_desc

全文索引旨在搜索列中的单词 - 您只需要有字符，这样就无法提供帮助。

Answer 2

试试这个。

SELECT distinct TOP (15) 
  bt_id AS [Key], 
  UPPER(rtrim(ltrim(bt_id)))+' - '+UPPER(rtrim(ltrim(bt_desc))) AS [Description] 
FROM fcbillto 
WHERE charindex(@SearchTerm, bt_id) > 0 OR charindex(@SearchTerm, bt_desc) > 0

像操作员搜索那么慢

2 个答案: