存储过程计算结果缓存的核心思路，是把昂贵查询得到的结果集或标量值先放到一个能快速访问的存储结构中，后续逻辑重复用到这些数据时，不再重新扫描基表或重算聚合。存储过程和普通查询不同，它通常包含分批处理、条件分支、循环更新等步骤，中间数据如果每次都用基表重新计算，执行时间会成倍增加。优化存储过程的重点不是消灭所有计算，而是让相同计算只发生一次。
重复计算从何而来：定位缓存需求
很多存储过程性能问题不是缺少索引，而是重复计算。比如一个报表存储过程先计算订单总额，再按订单总额分层，再计算各省份占比，每一步都从订单明细表聚合一次。即使基表有合适索引，三次大范围扫描也消耗大量I/O。典型重复来源于视图嵌套、CASE中的标量子查询、WHILE循环中的SELECT以及复用CTE。CTE在查询中只是一个内联视图，多个地方引用同一个CTE会导致其逻辑被展开执行多次，并不适合作为缓存中间值的主要手段。
下面是一个典型的问题代码示例，它在游标循环中逐条处理客户记录，每一条都重新聚合订单明细表。假如客户数量很多，这段代码会把同一张大表扫描多次，执行时间随客户数线性甚至更差地增长。
CREATE PROCEDURE dbo.ReportCustomerTotals
AS
BEGIN
DECLARE @CustomerID INT, @Total DECIMAL(18,2);
DECLARE cur CURSOR FOR SELECT CustomerID FROM Customers;
OPEN cur;
FETCH NEXT FROM cur INTO @CustomerID;
WHILE @@FETCH_STATUS = 0
BEGIN
SELECT @Total = SUM(Amount)
FROM OrderDetails
WHERE CustomerID = @CustomerID;
UPDATE CustomerStats
SET TotalAmount = @Total
WHERE CustomerID = @CustomerID;
FETCH NEXT FROM cur INTO @CustomerID;
END
CLOSE cur;
DEALLOCATE cur;
END定位重复计算的方法并不复杂。可以查看执行计划中是否出现了多次聚集索引扫描或RID查找，观察逻辑读次数是否会随着循环次数线性放大；也可以打开STATISTICS IO，看同一张基表是否被访问多次且过滤条件相似。如果答案是肯定的，就说明需要把中间结果缓存起来，而不是继续在循环里重复扫描。
用临时表与表变量缓存中间结果
临时表（#temp）和表变量（@table）是最常用的中间结果存储对象。临时表适合结果集较大、需要创建索引、需要可靠统计信息的场景；表变量适合非常小的数据集，但SQL Server不维护表变量的统计信息，优化器通常估计只有一行数据，当实际行数较多时可能生成低效执行计划。因此缓存聚合结果时，推荐优先使用临时表，只有在明确只有几十行或几百行数据时才考虑表变量。
假设某个存储过程需要先计算每个区域和产品类别的销售额，再基于这个汇总结果做占比、排名和筛选。与其让每个步骤都扫描订单明细表，不如先用一次GROUP BY把聚合结果写入临时表，后续步骤直接读临时表。下面示例展示了这个流程，并为临时表建立必要的索引。
IF OBJECT_ID('tempdb..#SalesSummary') IS NOT NULL
DROP TABLE #SalesSummary;
SELECT
s.RegionID,
p.CategoryID,
SUM(od.Amount) AS TotalAmount,
COUNT(*) AS OrderCount
INTO #SalesSummary
FROM OrderDetails od
JOIN Products p ON od.ProductID = p.ProductID
JOIN SalesRegions s ON od.RegionID = s.RegionID
GROUP BY s.RegionID, p.CategoryID;
CREATE INDEX IX_SalesSummary_Region
ON #SalesSummary(RegionID);
SELECT
RegionID,
SUM(TotalAmount) AS RegionTotal
FROM #SalesSummary
GROUP BY RegionID;CTE在该场景中容易被误认为已经缓存了结果。实际上，CTE如果只被引用一次，它只是提高可读性的内联结构；如果同一个CTE在查询中被引用多次，SQL Server会重复执行它的定义逻辑。只有把CTE的结果写入临时表，才真正实现了物化。临时表在会话结束时会自动删除，但存储过程反复执行时如果临时表已存在，需要先判断并删除，否则会报错或导致旧数据混入。
内存优化表与持久化计算结果
当临时表数据量较大、并发较高、tempdb成为瓶颈时，可以考虑内存优化表。内存优化表常驻内存，采用乐观并发控制，能够减少锁和闩锁争用，特别适合作为高并发存储过程中的中间结果缓存。SQL Server还支持本机编译存储过程，将T-SQL编译为机器代码，可以进一步提升CPU密集型计算的执行速度，不过本机编译存储过程有较多语法限制，需要结合具体版本评估。
下面示例创建一个仅用于当前会话或过程的内存优化表，将聚合结果插入其中。使用DURABILITY = SCHEMA_ONLY表示不持久化数据，适合只作为中间结果存储。需要提前在数据库中创建内存优化文件组，示例省略了文件组配置部分。
CREATE TABLE dbo.MO_Cache ( RegionID INT NOT NULL, CategoryID INT NOT NULL, TotalAmount DECIMAL(18,2) NOT NULL, PRIMARY KEY NONCLUSTERED (RegionID, CategoryID) ) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY); INSERT INTO dbo.MO_Cache(RegionID, CategoryID, TotalAmount) SELECT RegionID, CategoryID, SUM(Amount) FROM OrderDetails GROUP BY RegionID, CategoryID; SELECT * FROM dbo.MO_Cache;
对于需要跨执行复用的计算结果，可以使用普通表或索引视图作为持久化汇总缓存。比如每日汇总表存储按日聚合的结果，存储过程只需要读取小表，避免每次都扫描业务明细。普通表存在数据刷新问题，需要设计增量更新或定期重建机制；索引视图适合聚合查询固定且更新不频繁的场景，数据库会自动维护结果同步，但限制条件较多。临时对象解决一次执行内部的复用，持久化对象解决跨执行复用，两者可以结合使用。
缓存中间值的常见陷阱与优化建议
缓存本身也有成本。临时表写入会占用tempdb空间，表变量不受事务回滚影响但可能因统计信息缺失导致错误执行计划，内存优化表则需要足够内存支撑。在循环中反复TRUNCATE和INSERT临时表会造成系统表元数据争用，可以改为在循环外创建一次，或者在循环内使用DELETE替代。此外，不要把所有中间结果都缓存，只缓存那些会被多次使用且扫描成本高的结果集；一次性的计算结果直接内联在查询中反而更简洁。
原先用游标循环逐行更新统计值的存储过程，可以改成先一次性聚合到临时表，再通过连接批量更新目标表。下面示例展示了这个优化方式，一次聚合替代了每行一次的大表扫描，能显著减少逻辑读。
IF OBJECT_ID('tempdb..#Agg') IS NOT NULL
DROP TABLE #Agg;
SELECT
CustomerID,
SUM(Amount) AS TotalAmount
INTO #Agg
FROM OrderDetails
GROUP BY CustomerID;
CREATE INDEX IX_Agg_Customer
ON #Agg(CustomerID);
UPDATE cs
SET cs.TotalAmount = a.TotalAmount
FROM CustomerStats cs
JOIN #Agg a ON cs.CustomerID = a.CustomerID;综合来看，优化存储过程计算结果缓存可以从以下几点入手：
- 优先使用
GROUP BY一次性聚合，避免循环中的标量子查询。 - 小结果集可选用表变量，大结果集使用临时表并创建索引。
- 同一个CTE多次引用时，将结果物化到临时表。
- 高并发、高计算量场景评估内存优化表或本机编译存储过程。
- 注意清理临时对象，避免名称冲突；同时监控tempdb空间与争用情况。
存储过程优化不能仅凭经验，还需要结合执行计划、逻辑读、等待统计和tempdb使用情况综合判断。合理缓存计算结果和中间值，可以在不改变业务逻辑的前提下，让复杂存储过程的执行时间明显缩短。