踩坑！统计信息过期，查询慢到崩溃还计数失真

明明SQL没写错，count(*)时而对时而错，查询还突然慢了5倍，到底是哪里出问题？排查一圈发现，既不是数据页损坏，也不是索引失效，而是被忽略的「统计信息过期」在搞鬼！

要知道，SQL Server的查询计划全靠统计信息“指路”，一旦统计信息过期，数据库就会“瞎猜”数据分布，要么生成低效查询计划，要么计数失真，堪称DBA的“隐形坑”。

一、现场还原：统计信息过期的3个典型症状

1. 同样的count(*)查询，多次执行结果波动（比如时而174万，时而175万）

2. 简单的WHERE筛选查询，突然从毫秒级变成秒级，执行计划显示“全表扫描”（明明有索引）

3. 索引明明存在，却无法被查询计划使用，甚至出现“键查找”异常

就像这样，明明表结构、数据都没变，查询却突然“罢工”，大概率是统计信息“过期失效”了。

二、底层解密：统计信息到底有什么用？

很多DBA对统计信息的重视度不够，觉得“只要索引建得好，查询就不会糟”，其实大错特错。统计信息相当于SQL Server的“数据地图”，记录着如下重要信息：

• 表中数据的分布情况（比如某列的取值范围、重复率）
• 索引的碎片情况、数据页分布
• 每行数据的大致位置

当统计信息过期，“数据地图”就会过时，数据库生成查询计划时，就会做出错误判断——比如明明可以走索引，却非要全表扫描；明明数据只有100万行，却预估有1000万行，最终导致查询慢、计数失真。

重点：统计信息过期和数据页损坏的区别的是——前者是“地图错了”，数据本身没问题；后者是“数据本身坏了”，地图可能还是对的。

三、实操：3步搞定统计信息过期问题（附脚本）

步骤1：检查统计信息是否过期

执行以下SQL，快速定位过期的统计信息：

-- 查看数据库所有过期的统计信息
SELECT 
    t.name AS 表名,
    s.name AS 统计信息名,
    s.stats_id,
    STATS_DATE(t.object_id, s.stats_id) AS 统计信息更新时间,
    DATEDIFF(day, STATS_DATE(t.object_id, s.stats_id), GETDATE()) AS 过期天数
FROM sys.tables t
JOIN sys.stats s ON t.object_id = s.object_id
WHERE STATS_DATE(t.object_id, s.stats_id) < DATEADD(day, -7, GETDATE()) -- 超过7天未更新视为过期
ORDER BY 过期天数 DESC;

步骤2：更新统计信息（两种方式，按需选择）

✅ 方式1：更新单个表的所有统计信息（推荐，影响范围小）

-- 更新指定表的统计信息， WITH FULLSCAN 确保扫描所有数据，更精准
UPDATE STATISTICS [dbo].表名  WITH FULLSCAN;

✅ 方式2：更新整个数据库的统计信息（适合维护时段执行）

-- 更新数据库所有表的统计信息
EXEC sp_updatestats;

步骤3：设置自动更新统计信息

避免后续再次过期，直接开启自动更新：

-- 开启数据库自动更新统计信息（默认开启，可确认）
ALTER DATABASE [数据库名] SET AUTO_UPDATE_STATISTICS ON;
-- 开启自动更新统计信息时，使用全扫描（更精准，适合核心库）
ALTER DATABASE [数据库名] SET AUTO_UPDATE_STATISTICS_ASYNC ON;

以下这3种情况，一定要手动更新统计信息

• 表中数据大量新增/删除/修改（比如批量插入10万行以上）
• 执行了索引重建/重组操作后
• 查询性能突然下降，排除索引、锁阻塞问题后

四、总结

统计信息过期是SQL Server查询慢、计数失真的“隐形元凶”，比索引失效更隐蔽；建议定期检查一次统计信息，核心表建议每日更新；如有必要可以开启自动更新统计信息，再配合手动维护，可彻底杜绝这类问题。

下次再遇到查询慢、计数不准，别只查索引和数据页了，先检查统计信息是否过期！

💡 留言区说说：你有没有踩过统计信息的坑？遇到过哪些诡异的查询异常？

关注「数据库干货铺」，每天一条DBA实操避坑指南，远离数据库故障烦恼。