Veroorzaakt het verpakken van nullable-kolommen in ISNULL tabelscans?

Ja, het veroorzaakt tabelscans. (hoewel het lijkt te worden geoptimaliseerd als de kolom niet echt nullable is)

De SR0007 regel is extreem slecht algemeen advies omdat het het predikaat unsargable maakt en betekent dat eventuele indexen op de kolom nutteloos zijn. Zelfs als er geen index in de kolom staat, kan het zijn dat kardinaliteitsschattingen onnauwkeurig worden en andere delen van het plan beïnvloeden.

De categorisering ervan in de Microsoft.Performance categorie is best grappig omdat het lijkt te zijn geschreven door iemand die geen verstand heeft van queryprestaties.

Het beweert dat de grondgedachte is

Hoewel de uitdrukking zelf evalueert tot unknown uw code geeft een volledig deterministisch resultaat als u eenmaal begrijpt dat een = , <> , > , < enz. vergelijking met NULL evalueren als Unknown en dat de WHERE clausule retourneert alleen rijen waar de uitdrukking evalueert tot true .

Het is mogelijk dat ze bedoelen als ANSI_NULLS is uitgeschakeld, maar het voorbeeld dat ze geven in de documentatie van WHERE ISNULL([c2],0) > 2; vs WHERE [c2] > 2; zou hoe dan ook niet worden beïnvloed door deze instelling. Deze instelling

Uitvoeringsplannen met scans versus zoeken of lager

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