Warum gibt es auch nach dem Deaktivieren von Read-Ahead und dem Löschen des Puffers logisches Lesen?

Ich muss die Gesamtzeit ermitteln, die für die Ausführung der Abfrage in SQL-SERVER 2016 benötigt wird, wenn sich alle Datenseiten nur auf der Festplatte befinden sollen. Um dies zu erreichen, habe ich alle Puffer im SQL-Server mit den folgenden Befehlen gelöscht:

DBCC FREEPROCCACHE WITH NO_INFOMSGS
GO
DBCC DROPCLEANBUFFERS
GO
DBCC FREESESSIONCACHE
GO
DBCC FREESYSTEMCACHE ('ALL') WITH MARK_IN_USE_FOR_REMOVAL
GO 
DBCC FLUSHPROCINDB (@dbId)
GO

Danach stellte ich wieder fest, dass logische Lesevorgänge vorhanden waren, und lernte dann Read-Ahead kennen, sodass ich das Vorauslesen durch das Trace-Flag deaktivierte

DBCC TRACEON(652,-1)
GO

und auch das Prefetch-Flag

DBCC TRACEON(8744,-1)
GO

Jetzt habe ich noch logische Lesevorgänge, aber physische Lesevorgänge sind deutlich höher als nur das Löschen des Puffers. Gibt es eine Möglichkeit, 0 logische Lesevorgänge zu erzielen, oder ist mein Verständnis des logischen Lesevorgangs falsch?

Bitte führen Sie mich durch, ich bin neu in der SQL-Server-Welt

Ein logischer Lesevorgang wird gezählt, wenn während der Abfrageausführung eine einzelne Seite aus dem Puffercache abgerufen wird. Dies wird unabhängig davon gezählt, ob zum Zwischenspeichern der Seite ein physischer oder ein Vorauslesen verwendet wurde oder ob die Seite bereits im Puffercache vorhanden war. Folglich ist das logische Lesen ein Maß dafür, wie oft Seiten während der Ausführung der Abfrage tatsächlich im Speicher berührt wurden.

Ein physischer Lesevorgang wird gezählt, wenn die Speicher-Engine eine oder mehrere Seiten aus dem Speicher liest, da sich die angeforderte Seite noch nicht im Cache befindet. Dies schließt physische E / A aus, die durch Vorauslesescans ausgeführt werden.

Ein Vorauslesen wird gezählt, wenn die Speicher-Engine während aufeinanderfolgender Scans einen oder mehrere vollständige Bereiche (jeder Bereich umfasst 8 zusammenhängende Seiten) aus dem Speicher liest. Beim Vorauslesen werden Daten aggressiv vorab in den Speicher abgerufen, sodass die Seiten wahrscheinlich bereits zwischengespeichert werden, wenn sie von der Abfrage benötigt werden. Die Anzahl der von Read-Ahead-Scans gelesenen Extents variiert je nach SQL Server-Version und -Version sowie nach Fragmentierung. Ich habe gesehen, dass Read-Ahead-Scans bei Scans in Enterprise Edition mit der neuesten SQL Server-Version bis zu 4 MB gleichzeitig mit einem einzigen Scatter-Gather-E / A lesen.

Beachten Sie, dass sich die SQL Server- Speicher-Engine bei einem kalten Cache anders verhält (z. B. nach einem Neustart oder DBCC DROPCLEANBUFFERS). Wenn der Cache noch nicht aufgewärmt ist (Zielseiten des Puffermanagers wurden erfüllt), führt die Speicher-Engine vollständige 64-KB-Lesevorgänge anstelle einzelner 8-KB-Seitenlesevorgänge durch, um Seiten in den Cache einzulesen. Dies erwärmt den Cache viel schneller als sonst.

Ich konzentriere mich zum Zwecke der Abfrage- und Indexoptimierung lieber auf logische als auf physische Lesevorgänge, da dies ein besseres Maß für die von der Abfrage geleistete Arbeit ist. Es ist nur zufällig, ob Daten zwischengespeichert werden oder nicht. Das Testen mit einem kalten Cache ist meiner Meinung nach eher ein Maß für die Speicherleistung als für die Abfrageleistung und nicht repräsentativ für das, was unter einer Produktionsauslastung mit einem warmen Cache auftreten wird.

Es wird immer logische Lesevorgänge geben. SQL Server gibt niemals Daten direkt von der Festplatte an Sie zurück. Befindet sich die benötigte Seite bereits im Pufferpool, erfolgt ein logischer Lesevorgang. Ist dies nicht der Fall, wird es in den Pufferpool verschoben, und es erfolgt auch ein logischer Lesevorgang. Sie erhalten immer den Lesevorgang aus dem Cache.

Außerdem verstehe ich den Sinn Ihres Tests nicht. Ist es nur eine Weltuntergangsanalyse? Wenn Sie einfach die Zeit messen, um Daten zurückzugeben, wenn Sie aus einem leeren Cache starten, warum messen Sie dann nicht einfach die Zeit? Warum machst du dir Sorgen um logische / physische Lesevorgänge? Wenn Sie nicht glauben, dass die von Ihnen ausgegebenen Befehle den Plan-Cache / Puffer-Pool löschen, können Sie diese Dinge unmittelbar vor der Ausgabe Ihrer Abfrage über DMVs überprüfen.

Logische Lesevorgänge können bei der Bewertung der Abfrageleistung sehr irreführend sein. Eine Zunahme der logischen Lesevorgänge bedeutet keine Abnahme der Leistung, manchmal ist das Gegenteil der Fall.

http://www.sql-server-performance.com/2018/logical-reads/