"IF..ElseIf..Else" or "Where clause" to guide Stored Procedure results

I have the following two SQL statements

First one:

IF(@User_Id IS NULL)  
BEGIN  
      SELECT *
      FROM [UserTable]
END  
ELSE           
BEGIN                  
      SELECT *
   FROM  [UserTable] AS u
   WHERE  u.[Id] = @User_Id                  
END 

Second one:

SELECT  *
FROM [UserTable] AS u
WHERE (@User_Id IS NULL OR u.[Id] = @User_Id)

Both of those queries would be wrapped in its own stored procedure. I am suspecting that the IF statement is causing a lot开发者_StackOverflow社区 of recompilations on SQL. I am faced with either separating each part of the IF statement into its own stored procedure, OR replacing the entire IF statement with a WHERE clause (illustrated above in the second SQL statement)

My question is: What is the difference between the two statements from a performance perspective, and how would SQL treat each statement?

Thanks.

Both solution will generate identical number of compilations.

The first solution the query optimizer is free to come up with the best plan for each of the two, different, queries. The first query (on the NULL branch of the IF) is not much that can be optimized, but the second one (on the NOT NULL branch of the ID) can be optimized if an index on Id column exists.

But the second solution is an optimization disaster. No matter the value of the @User_Id parameter, the optimizer has to come up with a plan that works for any value of the parameter. As such, no matter the value of @User_Id, the plan will always use the suboptimal table scan. There is just no way around this issue, and this is not parameter sniffing as some might think. Is just correctness of the plan, even if the value at plan generation time is NOT NULL, the plan has to work even when the parameter is NULL, so it cannot use the index on Id.

Always, always, always, use the first form with the explicit IF.