数据库优化：拆分多IF分支存储过程为单过滤存储过程是否更优？

你提到的将多分支存储过程拆分为多个单逻辑子存储过程、后端判断调用的方案属于可行方案，但并非通用最优解，是否适用完全取决于你的业务场景：

• 适用场景：查询逻辑固定，所有入参的非空组合一共只有不到10种，后续不会频繁加新的查询参数。这种场景下拆分的收益很高：每个子存储过程的执行计划完全稳定，不会出现参数嗅探、执行计划选错的问题，SQL逻辑简单，排查问题效率也高。
• 不适用场景：可选入参数量多（≥5个）、参数组合灵活，后续可能新增查询参数。这种场景下拆分的维护成本极高，比如8个可选参数就有255种非空组合，你不可能维护上百个存储过程，后端也不可能写几百个分支判断调用逻辑。

下面两种方案是SQL Server中处理这类多可选参数查询的主流优化手段，维护成本远低于拆分大量子存储过程，执行效率也能得到保障：

方案1：参数化动态SQL #

在存储过程内根据非空入参拼接查询语句，通过sp_executesql执行，完全避免SQL注入风险，不同的参数组合会生成独立的最优执行计划：

CREATE PROCEDURE [dbo].[sp_GetFilters]
    @Id INT = NULL,
    @Name VARCHAR(50) = NULL,
    @LastName VARCHAR(50) = NULL,
    @Age INT = NULL,
    @AND_MORE_PARAMETERS VARCHAR(MAX) = NULL
AS 
BEGIN
    SET NOCOUNT ON;
    DECLARE @SQL NVARCHAR(MAX) = N'SELECT * FROM EXAMPLE_TABLE WHERE 1=1 '
    
    IF @Id IS NOT NULL
        SET @SQL += N'AND Id = @Id '
    IF @Name IS NOT NULL
        SET @SQL += N'AND Name = @Name '
    IF @LastName IS NOT NULL
        SET @SQL += N'AND LastName = @LastName '
    IF @Age IS NOT NULL
        SET @SQL += N'AND Age = @Age '
    -- 其余参数按相同规则拼接
    
    EXEC sp_executesql @SQL, 
        N'@Id INT, @Name VARCHAR(50), @LastName VARCHAR(50), @Age INT, @AND_MORE_PARAMETERS VARCHAR(MAX)',
        @Id = @Id, @Name = @Name, @LastName = @LastName, @Age = @Age, @AND_MORE_PARAMETERS = @AND_MORE_PARAMETERS
END

优势：不用维护大量子存储过程，新增参数只需要加一行拼接逻辑和参数定义，执行效率和拆分存储过程基本一致，是这类场景的首选方案。

方案2：短路查询加编译提示 #

直接在WHERE条件中写短路判断，加OPTION (RECOMPILE)提示，让SQL Server每次执行时根据实际传入的非空参数生成最优执行计划：

CREATE PROCEDURE [dbo].[sp_GetFilters]
    @Id INT = NULL,
    @Name VARCHAR(50) = NULL,
    @LastName VARCHAR(50) = NULL,
    @Age INT = NULL,
    @AND_MORE_PARAMETERS VARCHAR(MAX) = NULL
AS 
BEGIN
    SET NOCOUNT ON;

    SELECT * 
    FROM EXAMPLE_TABLE 
    WHERE 
        (@Id IS NULL OR Id = @Id)
        AND (@Name IS NULL OR Name = @Name)
        AND (@LastName IS NULL OR LastName = @LastName)
        AND (@Age IS NULL OR Age = @Age)
        -- 其余参数按相同规则写判断
    OPTION (RECOMPILE)
END

优势：代码最简洁，维护成本最低，适合查询频率不算极高、参数组合灵活的场景。如果查询QPS非常高，重编译的开销可以忽略不计的前提下，这个方案的开发成本最低。

• 如果你的查询场景完全固定，参数组合不超过10种：可以按你原本的方案拆分存储过程，没有问题
• 如果参数组合多、后续可能新增参数：优先选择参数化动态SQL方案，其次选择短路查询加编译提示的方案，不要硬拆成大量子存储过程，后续维护会是灾难

内容的提问来源于stack exchange，提问作者Legendarkz