Frage

Für bestimmte Arten von sql-Abfragen, eine Hilfstabelle mit zahlen sehr nützlich sein kann.Es kann erstellt werden als Tabelle mit so vielen Zeilen, wie Sie benötigen für eine bestimmte Aufgabe oder als eine benutzerdefinierte Funktion, dass gibt die Anzahl der Zeilen benötigt, die in jeder Abfrage.

Was ist der optimale Weg, um erstellen Sie eine solche Funktion?

War es hilfreich?

Lösung

Heh...sorry, ich bin so spät reagiert zu einem alten post.Und, ja, ich hatte zu Antworten, da die beliebteste Antwort (zu der Zeit, die Rekursive CTE-Antwort mit dem link zu 14 verschiedene Methoden) auf diesen thread, ähmm...Leistung forderte am besten.

Zuerst die Artikel mit den 14 verschiedenen Lösungen gut zu sehen, die unterschiedliche Methoden zum erstellen einer Zahlen - /Tally-Tabelle auf die Fliegen, aber wie in dem Artikel darauf hingewiesen und in dem zitierten thread, es gibt eine sehr wichtig zitieren...

"Vorschläge in Bezug auf Effizienz und Leistung sind oft subjektiv.Unabhängig davon, wie einer query verwendet, die physische Umsetzung bestimmt die Effizienz einer Abfrage.Deshalb, anstatt sich auf voreingenommen-Richtlinien, ist es unerlässlich, das testen der Abfrage und bestimmen welche eine bessere Leistung."

Ironischerweise, die Artikel selbst enthält viele subjektive Aussagen und "voreingenommen Richtlinien" wie "eine rekursive CTE erzeugen kann, die eine Reihe listing ziemlich effizient" und "Das ist eine effiziente Methode der Verwendung der WHILE-Schleife aus einem newsgroup-posting von Itzik Ben-Gen" (was ich bin sicher, er veröffentlicht nur für Vergleichszwecke).C ' Mon folks...Einfach nur zu erwähnen Itzik den guten Namen können dazu führen, dass einige schlechte Schlampe in wirklich verwenden, die schreckliche Methode.Der Autor sollte das üben, was er Predigt, und sollte ein wenig performance zu testen, bevor er eine solche lächerlich falsche Aussagen vor allem in das Gesicht von jedem scalablility.

Mit dem Gedanken, tatsächlich tun einige Tests, bevor Sie irgendwelche subjektiven Behauptungen über das, was jeder code hat oder was jemand "gerne", hier einige code, den Sie tun können, Ihre eigene Tests mit.Setup-profiler für den SPID-führen Sie den test aus und überprüfen Sie es selbst heraus...tun Sie einfach "Search' N ''Replace" der Zahl 1000000 für Ihre "Lieblings" - Nummer und sehen...

--===== Test for 1000000 rows ==================================
GO
--===== Traditional RECURSIVE CTE method
   WITH Tally (N) AS 
        ( 
         SELECT 1 UNION ALL 
         SELECT 1 + N FROM Tally WHERE N < 1000000 
        ) 
 SELECT N 
   INTO #Tally1 
   FROM Tally 
 OPTION (MAXRECURSION 0);
GO
--===== Traditional WHILE LOOP method
 CREATE TABLE #Tally2 (N INT);
    SET NOCOUNT ON;
DECLARE @Index INT;
    SET @Index = 1;
  WHILE @Index <= 1000000 
  BEGIN 
         INSERT #Tally2 (N) 
         VALUES (@Index);
            SET @Index = @Index + 1;
    END;
GO
--===== Traditional CROSS JOIN table method
 SELECT TOP (1000000)
        ROW_NUMBER() OVER (ORDER BY (SELECT 1)) AS N
   INTO #Tally3
   FROM Master.sys.All_Columns ac1
  CROSS JOIN Master.sys.ALL_Columns ac2;
GO
--===== Itzik's CROSS JOINED CTE method
   WITH E00(N) AS (SELECT 1 UNION ALL SELECT 1),
        E02(N) AS (SELECT 1 FROM E00 a, E00 b),
        E04(N) AS (SELECT 1 FROM E02 a, E02 b),
        E08(N) AS (SELECT 1 FROM E04 a, E04 b),
        E16(N) AS (SELECT 1 FROM E08 a, E08 b),
        E32(N) AS (SELECT 1 FROM E16 a, E16 b),
   cteTally(N) AS (SELECT ROW_NUMBER() OVER (ORDER BY N) FROM E32)
 SELECT N
   INTO #Tally4
   FROM cteTally
  WHERE N <= 1000000;
GO
--===== Housekeeping
   DROP TABLE #Tally1, #Tally2, #Tally3, #Tally4;
GO

Während wir gerade dabei sind, hier die zahlen, die ich von SQL Profiler, um die Werte 100, 1000, 10000, 100000 und 1000000...

SPID TextData                                 Dur(ms) CPU   Reads   Writes
---- ---------------------------------------- ------- ----- ------- ------
  51 --===== Test for 100 rows ==============       8     0       0      0
  51 --===== Traditional RECURSIVE CTE method      16     0     868      0
  51 --===== Traditional WHILE LOOP method CR      73    16     175      2
  51 --===== Traditional CROSS JOIN table met      11     0      80      0
  51 --===== Itzik's CROSS JOINED CTE method        6     0      63      0
  51 --===== Housekeeping   DROP TABLE #Tally      35    31     401      0

  51 --===== Test for 1000 rows =============       0     0       0      0
  51 --===== Traditional RECURSIVE CTE method      47    47    8074      0
  51 --===== Traditional WHILE LOOP method CR      80    78    1085      0
  51 --===== Traditional CROSS JOIN table met       5     0      98      0
  51 --===== Itzik's CROSS JOINED CTE method        2     0      83      0
  51 --===== Housekeeping   DROP TABLE #Tally       6    15     426      0

  51 --===== Test for 10000 rows ============       0     0       0      0
  51 --===== Traditional RECURSIVE CTE method     434   344   80230     10
  51 --===== Traditional WHILE LOOP method CR     671   563   10240      9
  51 --===== Traditional CROSS JOIN table met      25    31     302     15
  51 --===== Itzik's CROSS JOINED CTE method       24     0     192     15
  51 --===== Housekeeping   DROP TABLE #Tally       7    15     531      0

  51 --===== Test for 100000 rows ===========       0     0       0      0
  51 --===== Traditional RECURSIVE CTE method    4143  3813  800260    154
  51 --===== Traditional WHILE LOOP method CR    5820  5547  101380    161
  51 --===== Traditional CROSS JOIN table met     160   140     479    211
  51 --===== Itzik's CROSS JOINED CTE method      153   141     276    204
  51 --===== Housekeeping   DROP TABLE #Tally      10    15     761      0

  51 --===== Test for 1000000 rows ==========       0     0       0      0
  51 --===== Traditional RECURSIVE CTE method   41349 37437 8001048   1601
  51 --===== Traditional WHILE LOOP method CR   59138 56141 1012785   1682
  51 --===== Traditional CROSS JOIN table met    1224  1219    2429   2101
  51 --===== Itzik's CROSS JOINED CTE method     1448  1328    1217   2095
  51 --===== Housekeeping   DROP TABLE #Tally       8     0     415      0

Wie Sie sehen können, die Rekursive CTE-Methode ist die zweitschlechteste nur die While-Schleife für die Dauer und die CPU-und hat 8 mal den Arbeitsspeicher in form von logischen Lesevorgänge als die While-Schleife.Es ist RBAR auf Steroide und sollten vermieden werden, bei der alle Kosten, die für jede einzelne Zeile Berechnungen nur als eine While-Schleife sollte vermieden werden. Es gibt Orte, wo die Rekursion ist sehr wertvoll, aber dies IST NICHT einer von Ihnen.

As a side bar, HerrDenny ist absolut vor Ort...eine korrekte permanente Zahlen oder Tally-Tisch ist der Weg zu gehen für die meisten Dinge.Was bedeutet in der korrekten Größe zu bedeuten?Nun, die meisten Leute verwenden eine Tally-Tabelle zu generieren, Termine oder zu tun, spaltet auf VARCHAR(8000).Wenn Sie erstellen 11.000 row Tally-Tabelle mit dem richtigen gruppierten index "N", haben Sie genug Zeilen zu erstellen, die mehr als 30 Jahre im Wert von Terminen (ich arbeite mit Hypotheken ein gutes Stück, also 30 Jahre ist eine wichtige Zahl für mich) und sicher genug, um Griff ein VARCHAR(8000) aufgeteilt.Warum ist "right sizing" so wichtig?Wenn der Tally-Tabelle ist eine Menge verwendet, es passt problemlos in den cache, die macht es rasend schnell, ohne viel Druck auf die Speicher überhaupt.

Nicht zuletzt, jeder weiß, dass, wenn Sie eine permanente Aufzeichnung Tabelle, es spielt kaum eine Rolle, welche Methode Sie verwenden, um es zu bauen, weil 1) es kann nur noch einmal gemacht werden und 2) wenn es so etwas wie eine 11,000 Zeile der Tabelle, alle Methoden laufen "gut genug". Warum also all die indigination für meinen Teil darüber, welche Methode zu verwenden???

Die Antwort ist, dass einige Arme Kerl/gal, der nicht besser weiß und nur braucht, um seine oder Ihre Arbeit erledigen könnte etwas sehen, wie die Rekursive CTE-Methode und entscheiden, verwenden Sie es für etwas viel größeres und viel häufiger verwendet wird als der Bau einer permanenten Aufzeichnung Tisch und ich bin versucht zu schützen Sie die Menschen, den Server Ihren code ausgeführt wird, und die Firma, die besitzt die Daten auf diesen Servern.Yeah...es ist die große Sache.Es sollte für alle anderen auch.Lehren Sie den richtigen Weg, Dinge zu tun, anstelle von "gut genug".Tun einige Tests vor der Veröffentlichung, oder mit etwas aus ein post oder ein Buch...das Leben, das Sie sparen können, in der Tat, seien Sie Ihr eigener vor allem, wenn Sie denken, dass ein rekursiver CTE ist der Weg zu gehen für so etwas wie dieses.;-)

Vielen Dank fürs Zuhören...

Andere Tipps

Die optimale Funktion wäre, eine Tabelle zu verwenden, anstatt eine Funktion.Mit einer Funktion verursacht zusätzliche CPU-Last zu schaffen, die Werte für die Daten zurückgegeben werden, insbesondere wenn die Werte, die zurückgegeben werden, decken einen sehr großen Bereich.

In diesem Artikel gibt 14 verschiedene mögliche Lösungen mit Diskussion der einzelnen.Der wichtige Punkt ist, dass:

Vorschläge in Bezug auf Effizienz und Leistung sind oft subjektiv.Unabhängig davon, wie einer query verwendet, die physische Umsetzung bestimmt die Effizienz einer Abfrage.Deshalb, anstatt sich auf voreingenommen-Richtlinien, ist es unerlässlich, das testen der Abfrage und bestimmen welche eine bessere Leistung.

Ich persönlich mochte:

WITH Nbrs ( n ) AS (
    SELECT 1 UNION ALL
    SELECT 1 + n FROM Nbrs WHERE n < 500 )
SELECT n FROM Nbrs
OPTION ( MAXRECURSION 500 )

Diese Ansicht ist super schnell und enthält alle positiven int Werte.

CREATE VIEW dbo.Numbers
WITH SCHEMABINDING
AS
    WITH Int1(z) AS (SELECT 0 UNION ALL SELECT 0)
    , Int2(z) AS (SELECT 0 FROM Int1 a CROSS JOIN Int1 b)
    , Int4(z) AS (SELECT 0 FROM Int2 a CROSS JOIN Int2 b)
    , Int8(z) AS (SELECT 0 FROM Int4 a CROSS JOIN Int4 b)
    , Int16(z) AS (SELECT 0 FROM Int8 a CROSS JOIN Int8 b)
    , Int32(z) AS (SELECT TOP 2147483647 0 FROM Int16 a CROSS JOIN Int16 b)
    SELECT ROW_NUMBER() OVER (ORDER BY z) AS n
    FROM Int32
GO

Verwendung SQL Server 2016+ generieren Sie zahlen, die Tabelle, die Sie verwenden könnten OPENJSON :

-- range from 0 to @max - 1
DECLARE @max INT = 40000;

SELECT rn = CAST([key] AS INT) 
FROM OPENJSON(CONCAT('[1', REPLICATE(CAST(',1' AS VARCHAR(MAX)),@max-1),']'));

LiveDemo


Idee entnommen aus Wie können wir OPENJSON zu generieren Reihe von zahlen?

edit:siehe Conrad ' s Kommentar weiter unten.

Jeff Moden Antwort ist großartig ...aber ich finde auf Postgres, dass das Itzik-Methode schlägt fehl, es sei denn, Sie entfernen Sie die E32-Reihe.

Etwas schneller ist, auf postgres (40ms vs 100ms) ist eine weitere Methode, die ich gefunden auf hier angepasst für postgres:

WITH 
    E00 (N) AS ( 
        SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL 
        SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 ),
    E01 (N) AS (SELECT a.N FROM E00 a CROSS JOIN E00 b),
    E02 (N) AS (SELECT a.N FROM E01 a CROSS JOIN E01 b ),
    E03 (N) AS (SELECT a.N FROM E02 a CROSS JOIN E02 b 
        LIMIT 11000  -- end record  11,000 good for 30 yrs dates
    ), -- max is 100,000,000, starts slowing e.g. 1 million 1.5 secs, 2 mil 2.5 secs, 3 mill 4 secs
    Tally (N) as (SELECT row_number() OVER (ORDER BY a.N) FROM E03 a)

SELECT N
FROM Tally

Wie bewege ich mich von SQL Server, Postgres Welt, verpasst haben, einen besseren Weg zu tun, tally Tabellen auf dieser Plattform ...INTEGER()?SEQUENZ()?

Noch viel später, würde ich mag zu tragen eine etwas andere "traditionelle" CTE (nicht touch-Basis-Tabellen, um die Lautstärke der Zeilen):

--===== Hans CROSS JOINED CTE method
WITH Numbers_CTE (Digit)
AS
(SELECT 0 UNION ALL SELECT 1 UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL SELECT 4 UNION ALL SELECT 5 UNION ALL SELECT 6 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9)
SELECT HundredThousand.Digit * 100000 + TenThousand.Digit * 10000 + Thousand.Digit * 1000 + Hundred.Digit * 100 + Ten.Digit * 10 + One.Digit AS Number
INTO #Tally5
FROM Numbers_CTE AS One CROSS JOIN Numbers_CTE AS Ten CROSS JOIN Numbers_CTE AS Hundred CROSS JOIN Numbers_CTE AS Thousand CROSS JOIN Numbers_CTE AS TenThousand CROSS JOIN Numbers_CTE AS HundredThousand

Diese CTE führt mehr Liest, dann Itzik CTE, aber weniger als die Traditionellen CTE.Jedoch, es konsequent führt weniger SCHREIBT dann die andere Abfragen. Wie Sie wissen, Schreibt konsequent sehr viel mehr teuer, dann Liest.

Die Dauer hängt stark von der Anzahl der Kerne (MAXDOP), aber, auf meine 8core, führt konsequent schneller (weniger Dauer in ms) an, dann die anderen Abfragen.

Ich bin mit:

Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 
May 14 2014 18:34:29 
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: )

auf Windows Server 2012 R2, 32 GB, Xeon X3450 @2.67 Ghz, 4 cores HT enabled.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top