Étant donné le tableau de tas suivant avec 400 lignes numérotées de 1 à 400:
DROP TABLE IF EXISTS dbo.N;
GO
SELECT
SV.number
INTO dbo.N
FROM master.dbo.spt_values AS SV
WHERE
SV.[type] = N'P'
AND SV.number BETWEEN 1 AND 400;
et les paramètres suivants:
SET NOCOUNT ON;
SET STATISTICS IO, TIME OFF;
SET STATISTICS XML OFF;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
L' SELECT
instruction suivante se termine en environ 6 secondes ( démo , plan ):
DECLARE @n integer = 400;
SELECT
c = COUNT_BIG(*)
FROM dbo.N AS N
CROSS JOIN dbo.N AS N2
CROSS JOIN dbo.N AS N3
WHERE
N.number <= @n
AND N2.number <= @n
AND N3.number <= @n
OPTION
(OPTIMIZE FOR (@n = 1));
Remarque: @La OPTIMIZE FOR
clause est uniquement destinée à produire une repro de taille raisonnable qui capture les détails essentiels du problème réel, y compris une erreur de cardinalité qui peut survenir pour diverses raisons.
Lorsque la sortie d'une seule ligne est écrite dans une table, cela prend 19 secondes ( démo , plan ):
DECLARE @T table (c bigint NOT NULL);
DECLARE @n integer = 400;
INSERT @T
(c)
SELECT
c = COUNT_BIG(*)
FROM dbo.N AS N
CROSS JOIN dbo.N AS N2
CROSS JOIN dbo.N AS N3
WHERE
N.number <= @n
AND N2.number <= @n
AND N3.number <= @n
OPTION
(OPTIMIZE FOR (@n = 1));
Les plans d'exécution semblent identiques à l'exception de l'insert d'une ligne.
Tout le temps supplémentaire semble être consommé par l'utilisation du processeur.
Pourquoi la INSERT
déclaration est-elle si lente?