SQL Server SELECT查询效率优化：足球投注赛果组合筛选提速问询

一、核心逻辑重构（收益最高，预计降低60%以上耗时） #

你当前的核心瓶颈是每次为160万行的表新增数百个非持久化计算列，查询时需要逐行计算所有列的结果，完全没有复用空间，耗时自然居高不下。可以直接把计算逻辑从列定义迁移到查询逻辑中，或者拆分匹配规则为参数化处理，彻底避免动态加列的开销：

• 把每周的700条匹配规则预先存入独立的规则表dbo.MatchRules，字段设计如下：

CREATE TABLE dbo.MatchRules(
    RuleID INT PRIMARY KEY,
    MatchNo INT, -- 对应第几场比赛，取值1-13
    TargetResult INT, -- 要求的赛果：1/3/2
    Score INT, -- 命中后的得分，即原CASE表达式中的1/0值
    RequiredCount INT -- 该规则要求的总命中场数，比如你示例中的1
)

• 把13场比赛的宽表预先转为长表固化存储，避免每次计算时逐列判断逻辑，该表只需初始化一次，后续不用修改：

CREATE TABLE dbo.RowsLong(
    RowID INT,
    MatchNo INT,
    Result INT,
    PRIMARY KEY (RowID, MatchNo)
)
-- 初始化长表数据
INSERT INTO dbo.RowsLong
SELECT RowID, 1, Match_1 FROM dbo.Rows
UNION ALL SELECT RowID, 2, Match_2 FROM dbo.Rows
UNION ALL SELECT RowID, 3, Match_3 FROM dbo.Rows
-- Match_4到Match_13以此类推写完即可

• 每周更新规则表后，一次查询即可算出所有规则的匹配结果，不需要新增任何计算列：

SELECT r.RowID, r.Match_1, r.Match_2, -- 其余Match字段自行补齐
FROM dbo.Rows r
JOIN (
    SELECT rl.RowID, mr.RuleID, SUM(mr.Score) MatchCount
    FROM dbo.RowsLong rl
    JOIN dbo.MatchRules mr ON rl.MatchNo = mr.MatchNo AND rl.Result = mr.TargetResult
    GROUP BY rl.RowID, mr.RuleID
    HAVING SUM(mr.Score) = MAX(mr.RequiredCount)
) t ON r.RowID = t.RowID
INTO FinalRows

这种方案完全规避了动态加计算列的开销，也不用逐行计算数百个CASE表达式，仅需一次关联聚合就能得到结果，160万行的关联聚合在SQL Server中运行耗时不会超过2分钟。

二、现有架构轻量化优化（不改核心逻辑也可大幅提效） #

如果暂时不想重构核心逻辑，可做以下调整：

• 给dbo.Rows的RowID字段设置聚集主键，你当前的表是堆表，扫描和关联效率远低于有序的聚集索引表，改完后全表扫描和关联速度可提升30%左右。
• 把非持久化计算列改为持久化计算列：原非持久化计算列每次查询都要实时计算，改为持久化后数据会物理存储在磁盘上，仅在写入/更新行时计算一次，你的160万行是13场比赛的全组合，属于固定数据，改完后查询直接读取存储结果即可，无需重复计算。修改语法示例：

ALTER TABLE dbo.Rows ADD Group1 AS (/* 原有CASE逻辑 */) PERSISTED

• 给常用过滤条件加非聚集索引：如果每周规则的命中范围很小，可以给计算列建非聚集索引，过滤时直接走索引定位行，不用扫全表：

CREATE NONCLUSTERED INDEX IX_Rows_Group1 ON dbo.Rows(Group1) INCLUDE (/* 你要查询的所有Match字段 */)

• 简化冗余查询逻辑：你当前的CTE完全是冗余的，直接一步查询即可完成，减少不必要的逻辑开销：

SELECT RowID,Match_1/* 其余字段补齐 */ INTO FinalRows
FROM dbo.Rows WHERE Group1 = 1

三、配置层面优化 #

• 给SQL Server分配足够内存，确保160万行的表可完全缓存在内存中，避免磁盘IO开销，该表总大小仅几十MB，完全可以全部放入内存。
• 执行查询时关闭SSMS的「包含实际执行计划」「客户端统计信息」等功能，减少数据传输和统计开销。
• 不要将700条条件拆分700次执行，尽量合并为一条批量查询语句一次执行，减少多次连接和编译的开销。

按照以上方案调整，尤其是落地核心逻辑重构后，整体耗时肯定可以压缩到5分钟以内，甚至更快。

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