千万级大表 SQL Server 查询慢？一套可落地的性能调优实战路径

当 SQL Server 单表数据量突破千万级别，"查询越来越慢"几乎是必然会出现的问题。很多同学一上来就加索引、改代码，结果收效甚微，甚至越调越慢。

真正有效的性能调优，不是靠"感觉"，而是靠一套可复现、可验证的步骤。本文结合生产实践，给你一套从"看现状 → 找瓶颈 → 精准优化 → 验证效果"的完整流程。

一、先别急着改：建立性能基线

调优的第一步，是搞清楚：现在到底有多慢？为什么慢？

1. 明确业务指标

不要只说"很慢"，要量化：

单次查询耗时：从 200ms 到 5s？
并发下 QPS / TPS 下降多少？
CPU / 内存 / IO 是否被打满？
影响的是全部查询，还是某几个特定 SQL？

2. 抓取"坏 SQL"

使用 SQL Server 自带的工具定位问题 SQL：

sql 复制代码

-- 查看当前正在执行的请求
SELECT
    r.session_id,
    r.status,
    r.command,
    r.cpu_time,
    r.total_elapsed_time,
    t.text AS sql_text,
    p.query_plan
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
CROSS APPLY sys.dm_exec_query_plan(r.plan_handle) p
WHERE r.session_id <> @@SPID;

也可以用：

SQL Server Profiler / Extended Events：抓慢查询
DMV（动态管理视图） ：分析历史执行情况

重点关注：

total_elapsed_time
total_logical_reads
total_worker_time

这些指标能告诉你：是 CPU 算得慢，还是 IO 读得多，还是等锁等得久。

二、看执行计划：找到真正的"罪魁祸首"

千万级数据下，80% 的性能问题都写在执行计划里。

1. 获取实际执行计划

在 SSMS 中按 Ctrl + M 打开"包含实际执行计划"，再执行你的 SQL。

重点看：

Table Scan / Clustered Index Scan：全表扫描，大表的噩梦
Key Lookup：非聚集索引回表次数太多
Sort / Hash Match：内存不足导致溢出到 TempDB
Estimated vs Actual Rows：预估行数偏差过大，说明统计信息过期

2. 常见"危险信号"

现象	可能原因
Table Scan	无合适索引
Key Lookup 多	索引覆盖不足
Sort 溢出	内存不足 / ORDER BY 不合理
预估行数偏差大	统计信息过期

经验法则：千万级表，几乎不能容忍 Table Scan。

三、索引优化：最值得投入的 20%

索引通常是性价比最高的优化手段。

1. 检查现有索引的使用情况

css 复制代码

SELECT
    i.name AS index_name,
    i.type_desc,
    s.user_seeks,
    s.user_scans,
    s.user_lookups,
    s.user_updates
FROM sys.indexes i
JOIN sys.dm_db_index_usage_stats s
    ON i.object_id = s.object_id
   AND i.index_id = s.index_id
WHERE OBJECT_NAME(i.object_id) = 'YourBigTable';

关注：

user_scans 很高：可能是缺失 WHERE 条件索引
user_updates 很高但 user_seeks 很低：索引维护成本高，收益低，考虑删除

2. 设计"对的"索引

千万级表建索引，有几个铁律：

（1）WHERE + JOIN + ORDER BY 是核心

sql 复制代码

-- 示例
SELECT *
FROM Orders
WHERE CustomerID = @cid
  AND OrderDate >= @start
ORDER BY OrderDate;

推荐复合索引：

scss 复制代码

CREATE INDEX IX_Orders_CustomerID_OrderDate
ON Orders(CustomerID, OrderDate);

顺序原则：

等值条件字段放前面（CustomerID）
范围条件字段放后面（OrderDate）

（2）避免"索引失效"的写法

这些写法容易导致索引失效，触发全表扫描：

WHERE ISNULL(Status,0)=1
WHERE DATEDIFF(DAY, CreateTime, GETDATE()) > 7
WHERE Column + 1 = 10
LIKE '%abc'（前导通配符）

改写示例：

sql 复制代码

-- 不推荐
WHERE DATEDIFF(DAY, CreateTime, GETDATE()) > 7

-- 推荐
WHERE CreateTime < DATEADD(DAY, -7, GETDATE())

3. 覆盖索引（Covering Index）

如果查询只用到少数几列，尽量让索引"包圆"：

scss 复制代码

CREATE INDEX IX_Orders_Cover
ON Orders(CustomerID, OrderDate)
INCLUDE (TotalAmount, Status);

这样可以避免 Key Lookup，性能提升往往是数量级的。

四、统计信息：让优化器"看清"数据

SQL Server 优化器依赖统计信息来做决策。统计信息不准，索引再好也没用。

1. 检查统计信息状态

arduino 复制代码

DBCC SHOW_STATISTICS ('Orders', IX_Orders_CustomerID_OrderDate);

关注：

Rows Sampled 是否远小于总行数
Updated 时间是否太久远

2. 手动更新统计信息

sql 复制代码

UPDATE STATISTICS Orders WITH FULLSCAN;

或在维护窗口内定期执行：

ini 复制代码

EXEC sp_updatestats;

千万级表建议：关键索引使用 FULLSCAN，普通索引可用默认采样，并在业务低峰期执行。

五、SQL 语句本身：少干活，早过滤

很多时候，不是数据库不行，而是 SQL 写得"太勤奋"。

1. 减少返回的数据量

禁止 SELECT *
只查需要的列
分页必须带索引

sql 复制代码

-- OFFSET / FETCH（SQL Server 2012+）
SELECT Id, Name, CreateTime
FROM Orders
ORDER BY CreateTime
OFFSET 100000 ROWS FETCH NEXT 50 ROWS ONLY;

前提是 CreateTime 上有索引。

2. 避免不必要的计算与排序

能用 EXISTS 就不用 COUNT(*) > 0
能用 JOIN 就避免多层子查询
能提前过滤就不要在 HAVING 里过滤

sql 复制代码

-- 不推荐
SELECT CustomerID, COUNT(*)
FROM Orders
GROUP BY CustomerID
HAVING COUNT(*) > 10;

-- 推荐
SELECT CustomerID, COUNT(*)
FROM Orders
WHERE Status = 'Active'
GROUP BY CustomerID;

六、表结构与存储：从"根"上减负

当索引和 SQL 都优化到位后，就该看"数据本身"了。

1. 分区表（Partition Table）

千万级甚至亿级数据，强烈建议考虑分区表：

sql 复制代码

-- 按日期分区示例
CREATE PARTITION FUNCTION pf_OrderDate (DATETIME)
AS RANGE RIGHT FOR VALUES
('2024-01-01', '2024-07-01', '2025-01-01');

CREATE PARTITION SCHEME ps_OrderDate
AS PARTITION pf_OrderDate ALL TO ([PRIMARY]);

优势：

查询只扫相关分区（Partition Elimination）
维护（重建索引、删除历史数据）更快
备份恢复更灵活

2. 数据类型精简

每少 1 字节，千万行就是 10MB 的差距：

INT → SMALLINT / TINYINT
VARCHAR(500) → VARCHAR(50)
避免滥用 NVARCHAR（除非真需要 Unicode）
能用 DATE 就不要用 DATETIME

3. 归档历史数据

不是所有数据都要放在"热表"里：

超过 1 年的订单 → 归档表 / 归档库
日志类数据 → 按月拆分
冷热数据分离，热表体积越小，性能越好

七、服务器与配置：别让硬件拖后腿

1. 内存：最重要的资源

千万级表，数据页能否留在内存，直接决定性能。

确保 SQL Server 有足够的最大内存
避免与其他服务争抢内存
监控 Page Life Expectancy（PLE），过低说明内存压力

ini 复制代码

SELECT *
FROM sys.dm_os_performance_counters
WHERE counter_name = 'Page life expectancy';

2. TempDB：隐藏的性能杀手

排序、哈希连接、临时表都用到 TempDB。

优化建议：

多个 TempDB 数据文件（一般等于 CPU 核数，最多 8 个）
文件大小一致，开启自动增长但要设合理步长
放在高速磁盘（SSD / NVMe）

3. 参数嗅探（Parameter Sniffing）

同一个存储过程，有时快有时慢，很可能是参数嗅探问题。

应对方式：

使用 OPTION (RECOMPILE)
使用局部变量屏蔽参数
更新统计信息
SQL Server 2016+ 可使用 USE HINT('DISABLE_PARAMETER_SNIFFING')

八、一个简化的调优流程清单

实际工作中，可以按这个顺序来：

确认问题 SQL（Profiler / DMV）
查看执行计划（找 Scan / Lookup / Sort）
检查索引（缺失 / 冗余 / 覆盖）
更新统计信息
改写 SQL（减少数据量、避免函数）
评估分区 / 归档
检查服务器配置（内存 / TempDB）
验证效果并固化（索引 + 定时维护）

九、总结

千万级大表的性能调优，不是"一招鲜"，而是一个系统工程：

执行计划和 DMV 是眼睛，帮你看清真相
索引和统计信息是武器，解决大多数问题
SQL 写法是基本功，决定下限
分区、归档、硬件配置是兜底，决定上限

记住一句话：先测量，再优化；先整体，再局部；先低成本，再高风险。