Förorsakar radbrytning av null-kolumner i ISNULL tabellsökningar?

Ja det orsakar tabellskanningar. (även om det verkar bli optimerat om kolumnen faktiskt inte är nullbar)

SR0007 regeln är extremt dålig generell rådgivning eftersom den gör predikatet unsargable och innebär att alla index på kolumnen kommer att vara värdelösa. Även om det inte finns något index på kolumnen kan det fortfarande göra kardinalitetsuppskattningar felaktiga, vilket påverkar andra delar av planen.

Kategoriseringen av den i Microsoft.Performance kategorin är ganska underhållande eftersom den verkar ha skrivits av någon utan förståelse för frågeprestanda.

Den hävdar att motiveringen är

Medan själva uttrycket utvärderas till okänt din kod returnerar ett helt deterministiskt resultat när du förstår att någon = , <> , > , < etc jämförelse med NULL utvärdera som Okänd och att WHERE sats returnerar endast rader där uttrycket evalueras till true .

 
 Det är möjligt att de menar om ANSI_NULLS 
 är av men exemplet de ger i dokumentationen för WHERE ISNULL([c2],0)> 2; vs WHERE [c2]> 2; skulle ändå inte påverkas av den här inställningen. Denna inställning
 
 Exekveringsplaner som visar skanningar vs sök eller nedan
 CREATE TABLE #foo
  (
     x INT NULL UNIQUE
  )

INSERT INTO #foo
SELECT ROW_NUMBER() OVER (ORDER BY @@SPID)
FROM   sys.all_columns

SELECT *
FROM   #foo
WHERE  ISNULL(x, 10) = 10

SELECT *
FROM   #foo
WHERE  x = 10

SELECT *
FROM   #foo
WHERE  x = 10
        OR x IS NULL