La manière de loin la plus rapide et la plus simple d’ imprimer «tous les nombres premiers (1-100)» consiste à adopter pleinement le fait que les nombres premiers sont un ensemble de valeurs connues, finies et immuables («connues» et «finies» au sein d’une gamme particulière, bien sûr). À cette petite échelle, pourquoi gaspiller le CPU à chaque fois pour calculer un tas de valeurs connues depuis très longtemps et prendre peu de mémoire pour stocker?
SELECT tmp.[Prime]
FROM (VALUES (2), (3), (5), (7), (11), (13),
(17), (19), (23), (29), (31), (37), (41),
(43), (47), (53), (59), (61), (67), (71),
(73), (79), (83), (89), (97)) tmp(Prime)
Bien sûr, si vous devez calculer les nombres premiers entre 1 et 100, ce qui suit est assez efficace:
;WITH base AS
(
SELECT tmp.dummy, ROW_NUMBER() OVER (ORDER BY (SELECT 1)) AS [num]
FROM (VALUES (0), (0), (0), (0), (0), (0), (0)) tmp(dummy)
), nums AS
(
SELECT (ROW_NUMBER() OVER (ORDER BY (SELECT 1)) * 2) + 1 AS [num]
FROM base b1
CROSS JOIN base b2
), divs AS
(
SELECT [num]
FROM base b3
WHERE b3.[num] > 4
AND b3.[num] % 2 <> 0
AND b3.[num] % 3 <> 0
)
SELECT given.[num] AS [Prime]
FROM (VALUES (2), (3)) given(num)
UNION ALL
SELECT n.[num] AS [Prime]
FROM nums n
WHERE n.[num] % 3 <> 0
AND NOT EXISTS (SELECT *
FROM divs d
WHERE d.[num] <> n.[num]
AND n.[num] % d.[num] = 0
);
Cette requête ne teste que les nombres impairs car les nombres pairs ne seront de toute façon pas premiers. Il est également spécifique à la plage de 1 à 100.
Maintenant, si vous avez besoin d'une plage dynamique (similaire à ce qui est montré dans l'exemple de code dans la question), alors ce qui suit est une adaptation de la requête ci-dessus qui est encore assez efficace (elle a calculé la plage de 1 - 100 000 - 9592 entrées - en un peu moins d'une seconde):
DECLARE @RangeStart INT = 1,
@RangeEnd INT = 100000;
DECLARE @HowMany INT = CEILING((@RangeEnd - @RangeStart + 1) / 2.0);
;WITH frst AS
(
SELECT tmp.thing1
FROM (VALUES (0), (0), (0), (0), (0), (0), (0), (0), (0), (0)) tmp(thing1)
), scnd AS
(
SELECT 0 AS [thing2]
FROM frst t1
CROSS JOIN frst t2
CROSS JOIN frst t3
), base AS
(
SELECT TOP( CONVERT( INT, CEILING(SQRT(@RangeEnd)) ) )
ROW_NUMBER() OVER (ORDER BY (SELECT 1)) AS [num]
FROM scnd s1
CROSS JOIN scnd s2
), nums AS
(
SELECT TOP (@HowMany)
(ROW_NUMBER() OVER (ORDER BY (SELECT 1)) * 2) +
(@RangeStart - 1 - (@RangeStart%2)) AS [num]
FROM base b1
CROSS JOIN base b2
), divs AS
(
SELECT [num]
FROM base b3
WHERE b3.[num] > 4
AND b3.[num] % 2 <> 0
AND b3.[num] % 3 <> 0
)
SELECT given.[num] AS [Prime]
FROM (VALUES (2), (3)) given(num)
WHERE given.[num] >= @RangeStart
UNION ALL
SELECT n.[num] AS [Prime]
FROM nums n
WHERE n.[num] BETWEEN 5 AND @RangeEnd
AND n.[num] % 3 <> 0
AND NOT EXISTS (SELECT *
FROM divs d
WHERE d.[num] <> n.[num]
AND n.[num] % d.[num] = 0
);
Mes tests (en utilisant SET STATISTICS TIME, IO ON;
) montrent que cette requête fonctionne mieux que les deux autres réponses données (jusqu'à présent):
GAMME: 1 - 100
Query Logical Reads CPU Milliseconds Elapsed Milliseconds
------- ---------------- ---------------- -----------------
Solomon 0 0 0
Dan 396 0 0
Martin 394 0 1
GAMME: 1-10 000
Query Logical Reads CPU Milliseconds Elapsed Milliseconds
------- ---------------- ---------------- -----------------
Solomon 0 47 170
Dan 77015 2547 2559
Martin n/a
GAMME: 1 - 100 000
Query Logical Reads CPU Milliseconds Elapsed Milliseconds
------- ---------------- ---------------- -----------------
Solomon 0 984 996
Dan 3,365,469 195,766 196,650
Martin n/a
GAMME: 99 900 - 100 000
REMARQUE : Afin d'exécuter ce test, j'ai dû corriger un bogue dans le code de Dan - @startnum
n'était pas pris en compte dans la requête, donc il a toujours commencé à 1
. J'ai remplacé la Dividend.num <= @endnum
ligne par Dividend.num BETWEEN @startnum AND @endnum
.
Query Logical Reads CPU Milliseconds Elapsed Milliseconds
------- ---------------- ---------------- -----------------
Solomon 0 0 1
Dan 0 157 158
Martin n/a
GAMME: 1 - 100 000 (re-test partiel)
Après avoir corrigé la requête de Dan pour le test 99,900 - 100,000, j'ai remarqué qu'il n'y avait plus de lectures logiques répertoriées. J'ai donc retesté cette plage avec ce correctif toujours appliqué et j'ai constaté que les lectures logiques avaient à nouveau disparu et que les temps étaient légèrement meilleurs (et oui, le même nombre de lignes a été renvoyé).
Query Logical Reads CPU Milliseconds Elapsed Milliseconds
------- ---------------- ---------------- -----------------
Dan 0 179,594 180,096