Tout d'abord, mes excuses pour le retard dans ma réponse depuis mes derniers commentaires.
Le sujet a été soulevé dans les commentaires selon lesquels l'utilisation d'un CTE récursif (rCTE à partir de maintenant) s'exécute assez rapidement en raison du faible nombre de lignes. Bien que cela puisse paraître ainsi, rien ne pourrait être plus éloigné de la vérité.
CONSTRUIRE UNE TABLE ET UNE FONCTION TALLY
Avant de commencer les tests, nous devons créer une table de pointage physique avec l'index cluster approprié et une fonction de pointage de style Itzik Ben-Gan. Nous ferons également tout cela dans TempDB afin de ne laisser tomber accidentellement les goodies de personne.
Voici le code pour construire la table Tally et ma version de production actuelle du merveilleux code d'Itzik.
--===== Do this in a nice, safe place that everyone has
USE tempdb
;
--===== Create/Recreate a Physical Tally Table
IF OBJECT_ID('dbo.Tally','U') IS NOT NULL
DROP TABLE dbo.Tally
;
-- Note that the ISNULL makes a NOT NULL column
SELECT TOP 1000001
N = ISNULL(ROW_NUMBER() OVER (ORDER BY (SELECT NULL))-1,0)
INTO dbo.Tally
FROM sys.all_columns ac1
CROSS JOIN sys.all_columns ac2
;
ALTER TABLE dbo.Tally
ADD CONSTRAINT PK_Tally PRIMARY KEY CLUSTERED (N)
;
--===== Create/Recreate a Tally Function
IF OBJECT_ID('dbo.fnTally','IF') IS NOT NULL
DROP FUNCTION dbo.fnTally
;
GO
CREATE FUNCTION [dbo].[fnTally]
/**********************************************************************************************************************
Purpose:
Return a column of BIGINTs from @ZeroOrOne up to and including @MaxN with a max value of 1 Trillion.
As a performance note, it takes about 00:02:10 (hh:mm:ss) to generate 1 Billion numbers to a throw-away variable.
Usage:
--===== Syntax example (Returns BIGINT)
SELECT t.N
FROM dbo.fnTally(@ZeroOrOne,@MaxN) t
;
Notes:
1. Based on Itzik Ben-Gan's cascading CTE (cCTE) method for creating a "readless" Tally Table source of BIGINTs.
Refer to the following URLs for how it works and introduction for how it replaces certain loops.
http://www.sqlservercentral.com/articles/T-SQL/62867/
http://sqlmag.com/sql-server/virtual-auxiliary-table-numbers
2. To start a sequence at 0, @ZeroOrOne must be 0 or NULL. Any other value that's convertable to the BIT data-type
will cause the sequence to start at 1.
3. If @ZeroOrOne = 1 and @MaxN = 0, no rows will be returned.
5. If @MaxN is negative or NULL, a "TOP" error will be returned.
6. @MaxN must be a positive number from >= the value of @ZeroOrOne up to and including 1 Billion. If a larger
number is used, the function will silently truncate after 1 Billion. If you actually need a sequence with
that many values, you should consider using a different tool. ;-)
7. There will be a substantial reduction in performance if "N" is sorted in descending order. If a descending
sort is required, use code similar to the following. Performance will decrease by about 27% but it's still
very fast especially compared with just doing a simple descending sort on "N", which is about 20 times slower.
If @ZeroOrOne is a 0, in this case, remove the "+1" from the code.
DECLARE @MaxN BIGINT;
SELECT @MaxN = 1000;
SELECT DescendingN = @MaxN-N+1
FROM dbo.fnTally(1,@MaxN);
8. There is no performance penalty for sorting "N" in ascending order because the output is explicity sorted by
ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
Revision History:
Rev 00 - Unknown - Jeff Moden
- Initial creation with error handling for @MaxN.
Rev 01 - 09 Feb 2013 - Jeff Moden
- Modified to start at 0 or 1.
Rev 02 - 16 May 2013 - Jeff Moden
- Removed error handling for @MaxN because of exceptional cases.
Rev 03 - 22 Apr 2015 - Jeff Moden
- Modify to handle 1 Trillion rows for experimental purposes.
**********************************************************************************************************************/
(@ZeroOrOne BIT, @MaxN BIGINT)
RETURNS TABLE WITH SCHEMABINDING AS
RETURN WITH
E1(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) --10E1 or 10 rows
, E4(N) AS (SELECT 1 FROM E1 a, E1 b, E1 c, E1 d) --10E4 or 10 Thousand rows
,E12(N) AS (SELECT 1 FROM E4 a, E4 b, E4 c) --10E12 or 1 Trillion rows
SELECT N = 0 WHERE ISNULL(@ZeroOrOne,0)= 0 --Conditionally start at 0.
UNION ALL
SELECT TOP(@MaxN) N = ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) FROM E12 -- Values from 1 to @MaxN
;
GO
Au fait ... remarquez que vous avez construit un million et une table de pointage et ajouté un index clusterisé dans environ une seconde. Essayez cela avec un rCTE et voyez combien de temps cela prend! ;-)
CONSTRUIRE QUELQUES DONNÉES DE TEST
Nous avons également besoin de données de test. Oui, je suis d'accord que toutes les fonctions que nous allons tester, y compris le rCTE, s'exécutent en une milliseconde ou moins pour seulement 12 lignes, mais c'est le piège dans lequel beaucoup de gens tombent. Nous parlerons plus en détail de ce piège plus tard, mais pour l'instant, permet de simuler l'appel de chaque fonction 40 000 fois, ce qui correspond au nombre de fois où certaines fonctions de ma boutique sont appelées dans une journée de 8 heures. Imaginez combien de fois ces fonctions pourraient être appelées dans une grande entreprise de vente au détail en ligne.
Donc, voici le code pour construire 40000 lignes avec des dates aléatoires, chacune ayant un numéro de ligne uniquement à des fins de suivi. Je n'ai pas pris le temps de faire des heures entières car cela n'a pas d'importance ici.
--===== Do this in a nice, safe place that everyone has
USE tempdb
;
--===== Create/Recreate a Test Date table
IF OBJECT_ID('dbo.TestDate','U') IS NOT NULL
DROP TABLE dbo.TestDate
;
DECLARE @StartDate DATETIME
,@EndDate DATETIME
,@Rows INT
;
SELECT @StartDate = '2010' --Inclusive
,@EndDate = '2020' --Exclusive
,@Rows = 40000 --Enough to simulate an 8 hour day where I work
;
SELECT RowNum = IDENTITY(INT,1,1)
,SomeDateTime = RAND(CHECKSUM(NEWID()))*DATEDIFF(dd,@StartDate,@EndDate)+@StartDate
INTO dbo.TestDate
FROM dbo.fnTally(1,@Rows)
;
CONSTRUIRE QUELQUES FONCTIONS POUR FAIRE LA CHOSE DES 12 HEURES
Ensuite, j'ai converti le code rCTE en fonction et créé 3 autres fonctions. Ils ont tous été créés en tant que iTVF hautes performances (Inline Table Valued Functions). Vous pouvez toujours le dire car les iTVF n'ont jamais de BEGIN comme Scalar ou mTVF (Multi-Statement Table Valued Functions).
Voici le code pour construire ces 4 fonctions ... Je les ai nommées d'après la méthode qu'elles utilisent et pas ce qu'elles font juste pour faciliter leur identification.
--===== CREATE THE iTVFs
--===== Do this in a nice, safe place that everyone has
USE tempdb
;
-----------------------------------------------------------------------------------------
IF OBJECT_ID('dbo.OriginalrCTE','IF') IS NOT NULL
DROP FUNCTION dbo.OriginalrCTE
;
GO
CREATE FUNCTION dbo.OriginalrCTE
(@Date DATETIME)
RETURNS TABLE WITH SCHEMABINDING AS
RETURN
WITH Dates AS
(
SELECT DATEPART(HOUR,DATEADD(HOUR,-1,@Date)) [Hour],
DATEADD(HOUR,-1,@Date) [Date], 1 Num
UNION ALL
SELECT DATEPART(HOUR,DATEADD(HOUR,-1,[Date])),
DATEADD(HOUR,-1,[Date]), Num+1
FROM Dates
WHERE Num <= 11
)
SELECT [Hour], [Date]
FROM Dates
GO
-----------------------------------------------------------------------------------------
IF OBJECT_ID('dbo.MicroTally','IF') IS NOT NULL
DROP FUNCTION dbo.MicroTally
;
GO
CREATE FUNCTION dbo.MicroTally
(@Date DATETIME)
RETURNS TABLE WITH SCHEMABINDING AS
RETURN
SELECT [Hour] = DATEPART(HOUR,DATEADD(HOUR,t.N,@Date))
,[DATE] = DATEADD(HOUR,t.N,@Date)
FROM (VALUES (-1),(-2),(-3),(-4),(-5),(-6),(-7),(-8),(-9),(-10),(-11),(-12))t(N)
;
GO
-----------------------------------------------------------------------------------------
IF OBJECT_ID('dbo.PhysicalTally','IF') IS NOT NULL
DROP FUNCTION dbo.PhysicalTally
;
GO
CREATE FUNCTION dbo.PhysicalTally
(@Date DATETIME)
RETURNS TABLE WITH SCHEMABINDING AS
RETURN
SELECT [Hour] = DATEPART(HOUR,DATEADD(HOUR,-t.N,@Date))
,[DATE] = DATEADD(HOUR,-t.N,@Date)
FROM dbo.Tally t
WHERE N BETWEEN 1 AND 12
;
GO
-----------------------------------------------------------------------------------------
IF OBJECT_ID('dbo.TallyFunction','IF') IS NOT NULL
DROP FUNCTION dbo.TallyFunction
;
GO
CREATE FUNCTION dbo.TallyFunction
(@Date DATETIME)
RETURNS TABLE WITH SCHEMABINDING AS
RETURN
SELECT [Hour] = DATEPART(HOUR,DATEADD(HOUR,-t.N,@Date))
,[DATE] = DATEADD(HOUR,-t.N,@Date)
FROM dbo.fnTally(1,12) t
;
GO
CONSTRUISEZ LE HARNAIS D'ESSAI POUR TESTER LES FONCTIONS
Enfin, nous avons besoin d'un harnais de test. Je fais une vérification de base et teste ensuite chaque fonction de manière identique.
Voici le code du harnais de test ...
PRINT '--========== Baseline Select =================================';
DECLARE @Hour INT, @Date DATETIME
;
SET STATISTICS TIME,IO ON;
SELECT @Hour = RowNum
,@Date = SomeDateTime
FROM dbo.TestDate
CROSS APPLY dbo.fnTally(1,12);
SET STATISTICS TIME,IO OFF;
GO
PRINT '--========== Orginal Recursive CTE ===========================';
DECLARE @Hour INT, @Date DATETIME
;
SET STATISTICS TIME,IO ON;
SELECT @Hour = fn.[Hour]
,@Date = fn.[Date]
FROM dbo.TestDate td
CROSS APPLY dbo.OriginalrCTE(td.SomeDateTime) fn;
SET STATISTICS TIME,IO OFF;
GO
PRINT '--========== Dedicated Micro-Tally Table =====================';
DECLARE @Hour INT, @Date DATETIME
;
SET STATISTICS TIME,IO ON;
SELECT @Hour = fn.[Hour]
,@Date = fn.[Date]
FROM dbo.TestDate td
CROSS APPLY dbo.MicroTally(td.SomeDateTime) fn;
SET STATISTICS TIME,IO OFF;
GO
PRINT'--========== Physical Tally Table =============================';
DECLARE @Hour INT, @Date DATETIME
;
SET STATISTICS TIME,IO ON;
SELECT @Hour = fn.[Hour]
,@Date = fn.[Date]
FROM dbo.TestDate td
CROSS APPLY dbo.PhysicalTally(td.SomeDateTime) fn;
SET STATISTICS TIME,IO OFF;
GO
PRINT'--========== Tally Function ===================================';
DECLARE @Hour INT, @Date DATETIME
;
SET STATISTICS TIME,IO ON;
SELECT @Hour = fn.[Hour]
,@Date = fn.[Date]
FROM dbo.TestDate td
CROSS APPLY dbo.TallyFunction(td.SomeDateTime) fn;
SET STATISTICS TIME,IO OFF;
GO
Une chose à noter dans le faisceau de test ci-dessus est que je shunte toutes les sorties dans des variables "jetables". C'est pour essayer de garder les mesures de performances aussi pures que possible sans aucun résultat sur le disque ou l'écran.
UN MOT D'ATTENTION SUR LES STATISTIQUES FIXÉES
Aussi, un mot d'avertissement pour les testeurs potentiels ... Vous NE DEVEZ PAS utiliser SET STATISTICS lors du test des fonctions Scalar ou mTVF. Il ne peut être utilisé en toute sécurité que sur des fonctions iTVF comme celles de ce test. Il a été prouvé que SET STATISTICS rend les fonctions SCALAR exécutées des centaines de fois plus lentement qu'elles ne le font réellement sans lui. Oui, j'essaie d'incliner un autre moulin à vent, mais ce serait un article complet de plus long et je n'ai pas le temps pour ça. J'ai un article sur SQLServerCentral.com qui parle de tout cela, mais cela n'a aucun sens de publier le lien ici parce que quelqu'un sera complètement déformé à ce sujet.
LES RÉSULTATS DU TEST
Donc, voici les résultats du test lorsque j'exécute le faisceau de test sur mon petit ordinateur portable i5 avec 6 Go de RAM.
--========== Baseline Select =================================
Table 'Worktable'. Scan count 1, logical reads 82309, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'TestDate'. Scan count 1, logical reads 105, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
CPU time = 203 ms, elapsed time = 206 ms.
--========== Orginal Recursive CTE ===========================
Table 'Worktable'. Scan count 40001, logical reads 2960000, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'TestDate'. Scan count 1, logical reads 105, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
CPU time = 4258 ms, elapsed time = 4415 ms.
--========== Dedicated Micro-Tally Table =====================
Table 'Worktable'. Scan count 1, logical reads 81989, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'TestDate'. Scan count 1, logical reads 105, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
CPU time = 234 ms, elapsed time = 235 ms.
--========== Physical Tally Table =============================
Table 'Worktable'. Scan count 1, logical reads 81989, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'TestDate'. Scan count 1, logical reads 105, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Tally'. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
CPU time = 250 ms, elapsed time = 252 ms.
--========== Tally Function ===================================
Table 'Worktable'. Scan count 1, logical reads 81989, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'TestDate'. Scan count 1, logical reads 105, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
CPU time = 250 ms, elapsed time = 253 ms.
Le "BASELINE SELECT", qui ne sélectionne que les données (chaque ligne créée 12 fois pour simuler le même volume de retour), est arrivé à droite environ 1 / 5ème de seconde. Tout le reste est arrivé à environ un quart de seconde. Eh bien, tout sauf cette fonction rCTE sanglante. Cela a pris 4 et 1/4 secondes ou 16 fois plus longtemps (1600% plus lent).
Et regardez les lectures logiques (mémoire IO) ... Le rCTE a consommé 2 960 000 (presque 3 MILLIONS de lectures) alors que les autres fonctions n'en ont consommé qu'environ 82 100. Cela signifie que le rCTE a consommé plus de 34,3 fois plus d'E / S de mémoire que n'importe quelle autre fonction.
PENSÉES DE CLÔTURE
Résumons. La méthode rCTE pour faire cette "petite" chose à 12 lignes a utilisé 16 fois (1 600%) plus de CPU (et durée) et 34,3 fois (3 430%) plus d'E / S de mémoire que n'importe quelle autre fonction.
Hé ... je sais à quoi tu penses. "Big Deal! Ce n'est qu'une fonction."
Oui, d'accord, mais combien d'autres fonctions avez-vous? Combien d'autres endroits en dehors des fonctions avez-vous? Et en avez-vous qui fonctionnent avec plus de 12 lignes à chaque exécution? Et, y a-t-il une chance que quelqu'un dans le pétrin pour une méthode copie ce code rCTE pour quelque chose de beaucoup plus gros?
Ok, il faut être franc. Cela n'a absolument aucun sens pour les gens de justifier un code à performances réduites simplement en raison d'un nombre ou d'une utilisation de lignes supposés limités. Sauf lorsque vous achetez une boîte MPP pour peut-être des millions de dollars (sans parler des frais de réécriture du code pour le faire fonctionner sur une telle machine), vous ne pouvez pas acheter une machine qui exécute votre code 16 fois plus rapidement (SSD a gagné ne le fais pas non plus ... tout ce truc était dans la mémoire à haute vitesse quand nous l'avons testé). La performance est dans le code. De bonnes performances sont dans un bon code.
Pouvez-vous imaginer si tout votre code s'exécutait "seulement" 16 fois plus rapidement?
Ne justifiez jamais un code défectueux ou compromis par les performances sur de faibles nombres de lignes ou même sur une faible utilisation. Si vous le faites, vous devrez peut-être emprunter l'un des moulins à vent que j'ai été accusé d'incliner pour garder vos processeurs et vos disques suffisamment frais. ;-)
UN MOT SUR LE MOT "TALLY"
Oui je suis d'accord. Sémantiquement parlant, la table de pointage contient des nombres, pas des "décomptes". Dans mon article original sur le sujet (ce n'était pas l'article original sur la technique mais c'était mon premier dessus), je l'ai appelé "Tally" non pas à cause de ce qu'il contient, mais à cause de ce qu'il fait ... c'est utilisé pour "compter" au lieu de boucler et "Tally" quelque chose est de "Count" quelque chose. ;-) Appelez ça comme vous voulez ... Tableau des nombres, tableau de pointage, tableau des séquences, peu importe. Je m'en fiche. Pour moi, "Tally" signifie plus complet et, étant un bon DBA paresseux, ne contient que 5 lettres (2 sont identiques) au lieu de 7 et c'est plus facile à dire pour la plupart des gens. C'est aussi "singulier", qui suit ma convention de dénomination pour les tables. ;-) Il' s aussi comment l'appelait l'article qui contenait une page d'un livre des années 60. Je vais toujours y faire référence en tant que «tableau de pointage» et vous saurez toujours ce que moi ou quelqu'un d'autre veut dire. J'évite également la notation hongroise comme la peste, mais j'appelle la fonction "fnTally" pour que je puisse dire "Eh bien, si vous utilisiez la fonction d'eff-en Tally que je vous ai montrée, vous n'auriez pas de problème de performance" sans que ce soit réellement un Violation des RH. ;-) sans qu'il s'agisse en fait d'une violation des RH. ;-) sans qu'il s'agisse en fait d'une violation des RH. ;-)
Ce qui m'inquiète le plus, c'est que les gens apprennent à l'utiliser correctement au lieu de recourir à des choses comme les rCTE à performances réduites et d'autres formes de RBAR caché.