SQL - 优化复杂的分页搜索查询

Question

我目前正在为大型数据库中的复杂搜索开发一个存储过程。因为有数千个条目，所以可以返回我想使用分页。虽然它正在工作，但我认为它太慢了。我阅读了很多关于 SQL 查询分页和优化性能的文章和文章。但大多数“优化”只对非常基本的请求有用，例如“从表 x 中提供 20-30 项”。

由于我们的世界并不是那么简单，而且还有更复杂的查询要进行，我想获得一些帮助以优化以下查询：

CREATE PROCEDURE [SearchItems]
@SAttr1 BIT = 0,
@SAttr2 BIT = 0,
@SAttr3 BIT = 0,
@Flag1 BIT = 0,
@Flag2 BIT = 0,
@Param1 VARCHAR(20),
@Param2 VARCHAR(10),
@SkipCount BIGINT,
@TakeCount BIGINT,
@SearchStrings NVARCHAR(1000)    
AS
    DECLARE @SearchStringsT TABLE(
        Val NVARCHAR(30)
    )

    INSERT INTO @SearchStringsT 
    SELECT * FROM dbo.Split(@SearchStrings,',');

WITH ResultTable AS (
    SELECT  Table1.*, ROW_NUMBER() OVER(ORDER BY Table1.ID ASC) AS [!ROWNUM!]
    FROM Table1
    INNER JOIN Table2 ON Table1.ID = Table2.FK1
    INNER JOIN Table3 ON Table2.ID = Table3.FK2
    INNER JOIN Table4 ON Table3.XX = Table4.FKX
    WHERE Table1.X1 = @Parameter1
    AND
        (@Flag1 = 0 OR Table1.X2 = 1) AND
        (@Flag2 = 0 OR Table2.X4 = @Parameter2) AND
        (@Flag3 = 0 OR EXISTS(SELECT * FROM Table5 WHERE Table5.ID = Table3.X1)) 
    AND
    (                   
        (@SAttr1 = 0 OR EXISTS(SELECT * FROM @SearchStringsT WHERE Table1.X1 LIKE Val)) OR
        (@SAttr2 = 0 OR EXISTS(SELECT * FROM @SearchStringsT WHERE Table2.X1 LIKE Val)) OR
        (@SAttr3 = 0 OR EXISTS(SELECT * FROM @SearchStringsT WHERE Table3.X1 LIKE Val)) OR
        (@SAttr4 = 0 OR EXISTS(SELECT * FROM @SearchStringsT WHERE Table4.X1 LIKE Val))
    )
)
SELECT TOP(@TakeCount) * FROM ResultTable
WHERE [!ROWNUM!] BETWEEN (@SkipCount + 1) AND (@SkipCount + @TakeCount)
RETURN

@SAttr 参数是指定是否搜索字段的位参数，@Flag 参数用于打开/关闭某些布尔表达式的检查，@SkipCount 和@TakeCount 用于分页。 @SearchString 是一个逗号分隔的搜索关键字列表，已经包含通配符。

我希望有人可以帮助我优化这一点，因为在主表中有 20.000 个条目的数据库中的单次搜索持续 800 毫秒，并且随着条目数的增加而增加。最终的应用程序需要处理超过 100.000 个条目。

非常感谢您的每一次帮助。 标记

Answer 1

虽然我同意 Tom H. 的观点，这可能是动态 SQL 最好的情况（而且我是一个存储 proc 类型的女孩，所以我不经常这么说），但可能你不这样做' t 在您的表上有良好的索引。所有可能的搜索字段都编入索引了吗？是否所有 FK 都已编入索引？

我的意思是 20,000 是一个很小的表，而 100,000 也是如此，所以看起来你可能还没有建立索引。

检查您的执行计划以查看是否正在使用索引。

Answer 2

存储过程不太擅长超泛型，因为它会阻止 SQL Server 始终使用最佳方法。最近在类似的情况下，我使用了 (gasp) 动态 SQL。我的搜索存储过程将构建 SQL 代码来执行搜索，就像你拥有它一样使用分页（使用 ROW_NUMBER() 等）。优点是如果参数表明一条信息没有在搜索中使用，那么生成的代码将忽略它。最后，它允许更好的查询计划。

确保正确使用 sp_executesql 以防止 SQL 注入攻击。