Ein einfacher Test der Effizienz von drei Paging-Methoden

Ich habe gerade einen Vergleich von Seiten mit einer größeren Datenmenge und unterschiedlichen Standorten durchgeführt.

Tabelle erstellen:

CREATE TABLE [TestTable] (
 [ID] [int] IDENTITY (1, 1) NOT NULL ,
 [FirstName] [nvarchar] (100) COLLATE Chinese_PRC_CI_AS NULL ,
 [LastName] [nvarchar] (100) COLLATE Chinese_PRC_CI_AS NULL ,
 [Country] [nvarchar] (50) COLLATE Chinese_PRC_CI_AS NULL ,
 [Note] [nvarchar] (2000) COLLATE Chinese_PRC_CI_AS NULL 
) ON [PRIMARY]
GO

Daten einfügen: (1 Million)

SET IDENTITY_INSERT TestTable ON
declare @i int
set @i=1
while @i<=1000000
begin
    insert into TestTable([id], FirstName, LastName, Country,Note) values(@i, &#39;FirstName_XXX&#39;,&#39;LastName_XXX&#39;,&#39;Country_XXX&#39;,&#39;Note_XXX&#39;)
    set @i=@i+1
end
SET IDENTITY_INSERT TestTable OFF

Paginierungslösung eins: (Verwenden Sie Not In und SELECT TOP für die Paginierung)

Erklärungsformular:

SELECT TOP 页大小 *
FROM TestTable
WHERE (ID NOT IN
          (SELECT TOP 页大小*页数 id
         FROM 表
         ORDER BY id))
ORDER BY ID

Paging-Lösung zwei: (ID größer als verwenden und TOP-Paging auswählen)

SELECT TOP 页大小 *
FROM TestTable
WHERE (ID >
          (SELECT MAX(id)
         FROM (SELECT TOP 页大小*页数 id
                 FROM 表
                 ORDER BY id) AS T))
ORDER BY ID

Paging-Lösung drei: (Paging mit gespeicherter SQL-Cursor-Prozedur verwenden)

create  procedure XiaoZhengGe
@sqlstr nvarchar(4000), --查询字符串
@currentpage int, --第N页
@pagesize int --每页行数
as
set nocount on
declare @P1 int, --P1是游标的id
 @rowcount int
exec sp_cursoropen @P1 output,@sqlstr,@scrollopt=1,@ccopt=1,@rowcount=@rowcount output
select ceiling(1.0*@rowcount/@pagesize) as 总页数--,@rowcount as 总行数,@currentpage as 当前页 
set @currentpage=(@currentpage-1)*@pagesize+1
exec sp_cursorfetch @P1,16,@currentpage,@pagesize 
exec sp_cursorclose @P1
set nocount off

Testergebnisse:

Bei den Tests handelt es sich jeweils um 10 Elemente pro Seite, und die drei Zahlen geben die Zeit in Sekunden an, die die drei Lösungen benötigen, um Ergebnisse zu liefern:

Seite 2: 18, 10, 29

Seite 500: 12, 8, 21

Seite 50000: 16, 18, 22

Seite 500000: 24, 16, 22

Der Hauptzweck dieses Tests besteht darin, die Seitenumblättereffizienz verschiedener Teile großer Datenmengen zu testen. Ich dachte, es sollte ein lineares Ergebnis sein, fand die Änderung aber seltsam. Nach mehrmaligem Testen tritt der Fehler innerhalb von 1 oder 2 Sekunden auf. Es wird geschätzt, dass SQL Server auch für das Umblättern entsprechend unterschiedlicher Positionen optimiert ist. Nach einem Blick auf die Abfrageanalyse liegt der Hauptaufwand immer noch in der Reihenfolge nach, die immer noch der Primärschlüssel ist. Wenn es sich nicht um den Primärschlüssel handelt oder es sich um eine Zeichenfolge handelt, ist er wahrscheinlich langsamer.

Da es noch andere Dinge zu tun gibt, wurden keine weiteren Tests durchgeführt. Interessierte Freunde können weiterhin verschiedene Tests mit 100.000 Elementen, ohne Index und String-Inhalt durchführen.

Das obige ist der detaillierte Inhalt vonEin einfacher Test der Effizienz von drei Paging-Methoden. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!