Does SQL Server read all of a COALESCE function even if the first argument is not NULL?
Nope. Here's a simple test:
SELECT COALESCE(1, (SELECT 1/0)) -- runs fine
SELECT COALESCE(NULL, (SELECT 1/0)) -- throws error
If the second condition is evaluated, an exception is thrown for divide-by-zero.
Per the MSDN Documentation this is related to how COALESCE is viewed by the interpreter - it's just an easy way to write a CASE statement.
CASE is well known to be one of the only functions in SQL Server that (mostly) reliably short circuits.
There are some exceptions when comparing to scalar variables and aggregations as shown by Aaron Bertrand in another answer here (and this would apply both to CASE and COALESCE):
DECLARE @i INT = 1;
SELECT CASE WHEN @i = 1 THEN 1 ELSE MIN(1/0) END;
will generate a division by zero error.
This should be considered a bug, and as a rule COALESCE will parse from left to right.
How about this one - as reported to me by Itzik Ben-Gan, who was told about it by Jaime Lafargue?
DECLARE @i INT = 1;
SELECT CASE WHEN @i = 1 THEN 1 ELSE MIN(1/0) END;
Result:
Msg 8134, Level 16, State 1, Line 2
Divide by zero error encountered.
There are trivial workarounds of course, but the point is still that CASE does not always guarantee left-to-right evaluation / short-circuiting. I reported the bug here and it was closed as "by design." Paul White subsequently filed this Connect item, and it was closed as Fixed. Not because it was fixed per se, but because they updated Books Online with a more accurate description of the scenario where aggregates can change the evaluation order of a CASE expression. I recently blogged more about this here.
EDIT just an addendum, while I agree that these are edge cases, that most of the time you can rely on left-to-right evaluation and short-circuiting, and that these are bugs that contradict the documentation and will probably eventually be fixed (this isn't definite - see the follow-up conversation on Bart Duncan's blog post to see why), I have to disagree when folks say that something is always true even if there is a single edge case that disproves it. If Itzik and others can find solitary bugs like this, it makes it at least in the realm of possibility that there are other bugs as well. And since we don't know the rest of the OP's query, we can't say for certain that he will rely on this short-circuiting but end up being bitten by it. So to me, the safer answer is:
While you can usually rely on CASE to evaluate left-to-right and short-circuit, as described in the documentation, it is not accurate to say that you can always do so. There are two demonstrated cases on this page where it is not true, and neither bug has been fixed in any publicly available version of SQL Server.
EDIT here is another case (I need to stop doing that) where a CASE expression does not evaluate in the order you would expect, even though no aggregates are involved.
The documentation makes it reasonably clear that the intention is for CASE to short-circuit. As Aaron mentions, there have been several reported instances where this has been shown to not always be true. So far, most of these have been acknowledged as bugs and fixed.
There are other issues with CASE (and therefore COALESCE) where side-effecting functions or sub-queries are used. Consider:
SELECT COALESCE((SELECT CASE WHEN RAND() <= 0.5 THEN 999 END), 999);
SELECT ISNULL((SELECT CASE WHEN RAND() <= 0.5 THEN 999 END), 999);
The COALESCE form often returns null, as described in a bug report by Hugo Kornelis.
The demonstrated issues with optimizer transforms and common-expression-tracking mean that it is impossible to guarantee that CASE will short-circuit in all circumstances.
I think you can be reasonably confident that CASE will short-circuit in general (particularly if a reasonably-skilled person inspects the execution plan, and that execution plan is 'enforced' with a plan guide or hints) but if you need an absolute guarantee, you have to write SQL that does not include the expression at all.