这问题我之前处理大表查询时碰到过类似情况，结合SQL Server的运行机制，大概率是下面这几个原因导致的：

• 隐式转换与索引失效风险
  你的Sap_Equipment_ID是bigint类型，但ISNULL的第二个参数是0（默认是int类型）。虽然SQL Server会按数据类型优先级把int转成bigint，但这种隐式转换可能让优化器无法高效利用该列上的现有索引——尤其是当查询需要处理大量数据时，优化器可能放弃索引查找，转而执行全表扫描，直接拖慢查询速度。

• 统计信息过期导致执行计划选错
  如果表的统计信息很久没更新，优化器就不知道Sap_Equipment_ID列中NULL值的占比。不加ISNULL时，优化器可能根据统计信息判断可以用快速索引访问；但加上ISNULL后，优化器对转换后的数据分布预估错误，选择了低效的执行计划（比如不必要的表扫描），导致查询卡住。

• NULL值的额外计算开销
  SQL Server对NULL值的存储有特殊优化，但当你用ISNULL把大量NULL值转换成0时，每一行都需要额外的判断和转换操作。如果表的数据量很大，且Sap_Equipment_ID列的NULL值占比很高，这些累加的计算开销会让查询速度急剧下降。

• 覆盖索引无法被利用
  如果你之前为Sap_Equipment_ID列创建了覆盖索引，不加ISNULL时查询可以直接从索引里取数据，速度很快；但加上ISNULL后，优化器会认为需要对索引列进行计算，无法直接使用覆盖索引，不得不回表查询完整数据，这就大大增加了IO开销。

建议你可以对比两个查询的执行计划，看看是不是扫描方式或者索引使用情况有差异，也可以尝试更新表的统计信息（UPDATE STATISTICS dbo.Event）后再测试带ISNULL的查询。

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