Question

我在我的SQL Server表中存储字符串前缀，我想知道这些值是否是给定参数值的有效前缀。

e.g。假设我有一个电话拒收呼叫列表，它包含一个条目，禁止拨打以“1425123”开头的号码的所有电话，而不是插入10000个号码（14251230000到14251239999 ）它存储前缀。

像这样：

CREATE TABLE Prefixes (
    Value varchar(10)
)

CREATE INDEX IX_Value UNIQUE Prefixes ( Value )

评估如下：

DECLARE @value varchar(10) = 'foobar'

SELECT
    *
FROM
    Prefixes
WHERE
    @value LIKE ( Value + '%' );

当我在SQL Server Management Studio的Azure SQL中运行它时，它说它正在执行索引扫描。在Azure SQL S1数据库上有大约70,000个条目，查询需要200到500毫秒才能执行。该工具不建议对索引进行任何改进以提高性能。

为了进行比较，完全相等匹配（Value = @value）使用索引查找并立即发生。

200-500ms对我的应用来说太慢了。

一个选项是使用Trie将查找移动到我的应用程序代码中以进行有效的前缀搜索（这会引入同步问题），但另一种方法是将查询更改为以下内容：

DECLARE @v1 varchar(1) = LEFT( @value, 1 )
DECLARE @v2 varchar(2) = LEFT( @value, 2 )
DECLARE @v3 varchar(3) = LEFT( @value, 3 )
DECLARE @v4 varchar(4) = LEFT( @value, 4 )
DECLARE @v5 varchar(5) = LEFT( @value, 5 )
DECLARE @v6 varchar(6) = LEFT( @value, 6 )
DECLARE @v7 varchar(7) = LEFT( @value, 7 )
DECLARE @v8 varchar(8) = LEFT( @value, 8 )
DECLARE @v9 varchar(9) = LEFT( @value, 9 )

SELECT
    *
FROM
    Prefixes
WHERE
    Value = @v1 OR
    Value = @v2 OR
    Value = @v3 OR
    Value = @v4 OR
    Value = @v5 OR
    Value = @v6 OR
    Value = @v7 OR
    Value = @v8 OR
    Value = @v9

当我运行它时，它会更快（使用索引搜索）但它感觉就像一个黑客，但因为我知道长度少于10个字符我现在没问题......现在。

有更好的方法吗？ SQL Server是否可以在内部进行前缀匹配（即在我的最后一个示例中使用相同的逻辑但不使用重复且脆弱的SQL）？

Answer 1

这是辅助数字表可以帮助的东西。

因为您只需要1-10我在查询中创建了一个内联而不是假设存在一个。

您可以通过将派生表V替换为对永久数字表的引用来缩短代码（如果您有一个或可以创建一个）。

SELECT IIF(EXISTS (SELECT *
                   FROM   (VALUES(1),(2),(3),
                                 (4),(5),(6),
                                 (7),(8),(9),(10)
                          ) V(number)
                          JOIN Prefixes P WITH(FORCESEEK)
                            ON P.Value = LEFT(@value, number)
                   WHERE  number <= LEN(@value)), 1, 0) AS PrefixExists

  |--Compute Scalar(DEFINE:([Expr1014]=CASE WHEN [Expr1015] THEN (1) ELSE (0) END))
       |--Nested Loops(Left Semi Join, DEFINE:([Expr1015] = [PROBE VALUE]))
            |--Constant Scan
            |--Nested Loops(Inner Join, OUTER REFERENCES:([Union1010]))
                 |--Filter(WHERE:([Union1010]<=len([@value])))
                 |    |--Constant Scan(VALUES:(((1)),((2)),((3)),((4)),((5)),((6)),((7)),((8)),((9)),((10))))
                 |--Index Seek(OBJECT:([tempdb].[dbo].[Prefixes].[IX_Value] AS [P]), SEEK:([P].[Value]=substring([@value],(1),[Union1010])) ORDERED FORWARD)

Answer 2

您的第一个选项很慢的原因是它不是sargable，因为您在where子句中修改Prefixes.Value。

因此，无法利用该指数。

您建议的解决方案很好（尽管您错过了长度为10的前缀）。

我唯一指出的是，您肯定会使用EXISTS查询吗？一旦你找到了一场比赛，那么你就完成了;没有必要找到更多。另外IN更加谦逊。

即

IF EXISTS (
    SELECT  *
    FROM    Prefixes
    WHERE   Value IN (@v1, @v2, ...)
)
    RETURN 1
ELSE
    RETURN 0

PS如果它非常重要，您可以考虑使用Full Text Indexing。（不幸的是，我自己从未使用它，所以无法进一步帮助。）我知道它的工作量更多，但可能是合理的。过去需要运行额外的服务;而且我不知道是否仍然如此。

修改

从Dudu Markovitz's idea借款，如果例如：
仍然效率低下

@Value = '9999999999'且与任何前缀都不匹配。

原因是所有Prefixes.Value < '9999999999'。

但没有匹配过滤器@value like value + '%'。

因此查询仍然必须扫描所有行。

但是我确实认为这可以（通过一些调整）通过始终获取第一个 value < @value然后检查具体是否匹配{{}来提高效率1}}。您需要首先保证@value like value + '%'不包含任何＆＃34;冗余＆＃34;值（或至少可以使用标志轻松过滤掉冗余值）。

冗余我指的是任何本身无效的Prefixes，因为它以现有的较短前缀开头。

然后您可以使用以下查询。

Value

如果优化器未能选择正确的索引，这将是我主张使用索引提示的罕见情况之一。

将列值匹配为前缀

2 个答案: