问Server查询优化:何处(Col=@Col或@Col=Null)

EN

不知道从哪里开始--不确定问题是我在愚弄查询优化器，还是在涉及nulls时索引的工作方式固有的问题。

我遵循的一个编码约定是编写这样的存储过程：

declare procedure SomeProc
  @ID int = null
as
  select
    st.ID,st.Col1,st.Col2
  from
    SomeTable st
  where
    (st.ID = @ID or @ID is null) --works, but very slow (relatively)

当然，在这个简单的测试用例中不太有用，但是当您希望存储的proc对满足某些条件的整个表或行进行操作时，它在其他场景中很有用。但是，在更大的桌子上使用是很慢的.如果我将where子句替换为：

where
    st.ID = @ID --3-5x faster than first example

更让我困惑的是，用-1替换空的速度与上面的“固定”WHERE子句的速度几乎相同：

declare procedure SomeProc
  @ID int = -1
as
  select
    st.ID,st.Col1,st.Col2
  from
    SomeTable st
  where
    (st.ID = @ID or @ID=-1) --much better... but why?

很明显，使事情变得古怪的是零，但为什么，确切地说呢？对我来说，从执行计划上看，答案并不明确。多年来，我在各种数据库、表和Server版本上都注意到了这一点，所以我不认为这是我当前环境的怪癖。我已经通过将缺省参数值从null转换为-1来解决这个问题；我的问题是为什么会工作。

备注

1. SomeTable.ID被索引
2. 它可能与(或者实际上可能是)一个参数嗅探问题SQL Server中的参数嗅探(或欺骗)有关，无论它的价值如何，在每次编辑/重新编译proc之后，我几乎一直在用"exec SomeProc“进行测试，省略了可选的参数。