带IsActive条件的SQL Inner Join查询过慢，执行sp_updatestats后的疑问

现有如下SQL查询：

select C.customerId, C.firstName, C.LastName, R.IsActive 
from Customer as C
Inner join Rider as R ON R.customerId = C.customerid
where R.rideid = 'xyz' 
    and R.rideareacode = 'abc' 
    and R.isActive = 1

该查询耗时长达90秒甚至更久，但移除R.IsActive = 1条件后仅需1秒完成。IsActive字段仅有1或0两个取值，Customer和Rider表均为大数据表（各约8万行）。

尝试为Rider表的IsActive字段创建非聚集索引，以及(rideid, rideareacode, isActive)复合索引，但查询速度仍未改善。Rider表现有索引如下：

IsActive (nonclustered)
rideid, rideareacode, isActive, userid (nonclustered, unique)
riderid (nonclustered, unique, primary key)

Customer表无任何索引。

执行sp_updatestats命令后，所有相关查询均能在1秒内完成。现咨询：

• 该命令的作用是什么？
• 是否会在未来引发问题？
• 原查询及相关查询变慢的根本原因是什么？

sp_updatestats的作用 #

sp_updatestats是SQL Server内置存储过程，核心作用是更新数据库内所有用户表和系统表的统计信息。统计信息是查询优化器生成高效执行计划的关键依据，它记录了表中数据的分布特征（比如字段值的占比、行数、数据密度等）。

这个过程会自动检查每个统计对象的过期状态（比如数据修改量超过系统阈值），仅更新过期的统计信息，确保优化器能基于最新的数据分布来选择最优的执行策略。

是否会在未来引发问题？ #

正常使用sp_updatestats不会引发问题，反而有助于维持查询性能：

• 它属于轻量级操作，更新统计的资源开销远低于慢查询带来的业务损失；
• 统计信息过期是数据库运行中的常态，定期执行（比如每周一次）能避免类似性能问题复发；
• 仅需注意避开业务高峰时段执行，防止短暂的资源占用影响业务，但通常这个影响可以忽略。

原查询变慢的根本原因 #

核心问题是统计信息过期，导致查询优化器生成了低效的执行计划：

• 当添加R.IsActive = 1条件时，过期的统计信息错误估计了该条件的匹配行数（比如误判符合条件的行数极少或极多）；
• 优化器基于错误的行数估计，选择了糟糕的执行方式——比如没有使用你创建的(rideid, rideareacode, isActive)复合索引，反而进行全表扫描，或者选择了低效的连接算法；
• 移除IsActive = 1条件后，优化器基于相对准确的rideid和rideareacode统计信息，选择了高效的执行计划，所以查询耗时骤降；
• 另外Customer表无任何索引的问题，被过期统计信息进一步放大——优化器可能错误判断了连接操作的行数，从而选择了更差的连接策略，加剧了查询延迟。

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