存储过程结果插入临时表后查询极慢，求原因及优化方案

• 临时表无索引+全量扫描：你创建的临时表#temptableT未定义索引，若MySProc返回数据量较大，后续WHERE param1 = param2会触发全表扫描，这部分耗时远超过原存储过程的7秒。另外原代码中CREATE TABLE #temptableT 'params'是语法错误，临时表结构不明确会导致字段类型匹配异常，进一步拖慢插入与查询效率。
• 全量加载后过滤：原存储过程返回的所有数据会先写入临时表再做过滤，相当于先读取全量数据再筛选，完全绕开了原存储过程可能存在的查询优化逻辑，数据量越大，这种方式的开销越高。
• 执行计划无法整体优化：用EXEC调用存储过程插入临时表时，数据库无法将后续过滤条件下推到原存储过程的查询中，只能分三步独立执行（运行MySProc、插入临时表、查询临时表），无法生成最优的整体执行计划。

方案1：修改原存储过程，内置过滤逻辑 #

这是最优解，直接给MySProc添加过滤逻辑，避免全量数据输出：

ALTER PROCEDURE MySProc
AS
BEGIN
    -- 保留原存储过程的查询逻辑，末尾添加过滤条件
    SELECT ... -- 原存储过程的查询字段
    FROM ... -- 原存储过程的表关联逻辑
    WHERE param1 = param2 -- 新增过滤条件
END

之后直接调用EXEC MySProc即可，耗时与原存储过程接近。

方案2：将原存储过程转为内联表值函数 #

若无法修改原存储过程，把MySProc内部的查询逻辑提取成内联表值函数，这样可直接在外部查询中添加过滤条件，数据库能生成整体最优执行计划：

CREATE FUNCTION dbo.GetMySProcData()
RETURNS TABLE
AS
RETURN
(
    -- 复制MySProc内部的完整SELECT逻辑
    SELECT ... -- 原存储过程返回的所有字段
    FROM ... -- 原存储过程的表、连接、过滤逻辑
)

查询时直接使用：

SELECT * FROM dbo.GetMySProcData() WHERE param1 = param2

方案3：优化临时表方案（迫不得已时使用） #

若必须保留临时表写法，先修正语法错误，再添加索引：

CREATE PROCEDURE MySProcWithWhereClause
BEGIN
    -- 明确定义临时表字段结构，匹配MySProc返回的字段类型
    CREATE TABLE #temptableT (
        param1 INT,
        param2 INT,
        -- 其他字段按实际类型定义
        col3 VARCHAR(50),
        col4 DATETIME
    )

    INSERT INTO #temptableT
        EXEC MySProc

    -- 添加覆盖索引，加速WHERE查询
    CREATE NONCLUSTERED INDEX IX_TempParam ON #temptableT (param1, param2)
    INCLUDE (col3, col4) -- 包含查询需要返回的其他字段

    SELECT * 
    FROM #temptableT 
    WHERE param1 = param2

    DROP TABLE #temptableT
END

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