SQL Server-Index-Scan und Index-Suche mit der gleichen Leistung

Question

Ich habe vier Abfragen, die gerade jetzt versucht, eine Anzahl aus einer sehr großen Tabelle auszuwählen.

Die Abfragen sind im Wesentlichen das.

SELECT count(PrimaryKeyIntColumn) from dbo.TableName 

SELECT count(PrimaryKeyIntColumn) from dbo.TableName where PrimaryKeyIntColumn >= 0 

SELECT count(PrimaryKeyIntColumn) from dbo.TableName where PrimaryKeyIntColumn IS NOT NULL 

SELECT count(PrimaryKeyIntColumn) from dbo.TableName where PrimaryKeyIntColumn BETWEEN 1 and 2147483647 

Wenn ich den geschätzten Ausführungsplan angezeigt werden, sehe ich die erste ist eine nicht gruppierte Index Scan, der zweite ist ein Clustered Index Seek, der dritte ein Nonclustered-Index Scan ist, und der vierte ist ein Clustered-Index-Suche. Dies ist mehr oder weniger erwartet (ist nicht Null würde normalerweise SARGable sein, außer ein Primärschlüssel ist bereits nicht Nullable, so dass der Abfrageoptimierer wahrscheinlich nur es auswirft)

Das Problem ist, dass jede dieser Abfragen 25% einnimmt Abfragekosten relativ zu dem Batch von 4, wobei jeder Indexscan oder Indexsuchvorgang 95% der Kosten einnimmt. Grundsätzlich, soweit ich das beurteilen kann, gibt es in diesem speziellen Szenario keinen wirklichen Leistungsunterschied zwischen einem Index-Scan und einem Index-Suchlauf, obwohl dies der Fall sein sollte.

Der genaue Ausführungsplan SELECT 0% -> Compute Scalar 0% -> Stream-Aggregat 5% -> Index (Scannen | SEEK) 95%

Ich bin nicht wirklich sicher, was das Problem ist, aber die Suche scheint nicht ein wenig schneller als der Scan zu sein. Führen Sie jeden dieser Spins für Minuten, bevor ich ungeduldig werde und die Abfrage abbrechen.

Während ich weiß, dass ich die Zahlen auf andere Weise bekommen kann, ist das nicht wirklich das Endziel. Ich versuche, die Leistung für einige andere Abfragen herunter zu bekommen, und ich bin mir nicht sicher, warum, einen Suchlauf in einen Suchvorgang zu verwandeln nichts tut. Ich denke, wenn ich herausfinden kann, warum das passiert, könnte ich vielleicht zur Wurzel des Problems kommen.

Jede Hilfe wäre willkommen. Dies ist eine sehr große Tabelle mit über 100 Millionen Datenzeilen.

Es gibt eine ähnliche Frage hier: Poor clustered index seek performance?, aber es scheint nicht für mich anwendbar.

Answer 1

Es ist nicht wirklich ein Suchvorgang. Sie suchen nur den Anfang - und machen von dort einen Entfernungs-Scan. Da Ihre Reichweite (fast) identisch mit der ganzen Tabelle ist, gibt es keinen wirklichen Unterschied. Die Zählung muss 100M Datensätze entweder im gruppierten oder im Nonclustered-Index durchlaufen. Du kannst nicht erwarten, dass es schnell gehen würde. Und nein, es gibt keine rowcount für die Tabelle gespeichert, die Sie leicht lesen können.