Heh...maaf saya telat banget membalas postingan lama. Dan, ya, saya harus menjawab karena jawaban paling populer (pada saat itu, jawaban CTE Rekursif dengan tautan ke 14 metode berbeda) di utas ini adalah, ummm... kinerja paling menantang.
Pertama, artikel dengan 14 solusi berbeda baik-baik saja untuk melihat metode berbeda dalam membuat tabel Numbers/Tally dengan cepat, tetapi seperti yang ditunjukkan dalam artikel dan di utas yang dikutip, ada sangat kutipan penting...
"Saran mengenai efisiensi dan kinerja seringkali subjektif. Terlepas dari bagaimana kueri digunakan, implementasi fisik menentukan efisiensi kueri. Oleh karena itu, daripada mengandalkan pedoman yang bias, Anda harus menguji kueri dan menentukan mana yang berkinerja lebih baik."
Ironisnya, artikel itu sendiri mengandung banyak pernyataan subjektif dan "pedoman bias" seperti "CTE rekursif dapat menghasilkan daftar nomor cukup efisien " dan "Ini adalah metode yang efisien menggunakan loop WHILE dari posting newsgroup oleh Itzik Ben-Gen" (yang saya yakin dia posting hanya untuk tujuan perbandingan). Ayo teman-teman... Menyebutkan nama baik Itzik saja bisa membuat beberapa orang jorok benar-benar menggunakan metode mengerikan itu. Penulis harus mempraktekkan apa yang dia khotbahkan dan harus melakukan sedikit pengujian kinerja sebelum membuat pernyataan yang sangat tidak benar, terutama dalam menghadapi skalabilitas apa pun.
Dengan pemikiran untuk benar-benar melakukan beberapa pengujian sebelum membuat klaim subjektif tentang apa yang dilakukan kode apa pun atau apa yang "disukai seseorang", berikut adalah beberapa kode yang dapat Anda gunakan untuk melakukan pengujian Anda sendiri. Siapkan profiler untuk SPID tempat Anda menjalankan tes dan periksa sendiri... lakukan saja "Search'n'Replace" dari nomor 1000000 untuk nomor "favorit" Anda dan lihat...
--===== 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
Sementara kami melakukannya, inilah angka yang saya dapatkan dari SQL Profiler untuk nilai 100, 1000, 10000, 100000, dan 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
Seperti yang Anda lihat, metode CTE Rekursif adalah yang terburuk kedua setelah Loop Sementara untuk Durasi dan CPU dan memiliki 8 kali tekanan memori dalam bentuk pembacaan logis daripada Loop Sementara . Ini RBAR pada steroid dan harus dihindari, dengan cara apa pun, untuk setiap perhitungan baris tunggal seperti Loop Sementara harus dihindari. Ada tempat di mana rekursi cukup berharga tetapi ini BUKAN salah satunya .
Sebagai bar samping, Mr. Denny benar-benar tepat... tabel Numbers atau Tally permanen berukuran benar adalah cara yang tepat untuk banyak hal. Apa yang dimaksud dengan ukuran yang benar? Yah, kebanyakan orang menggunakan tabel Tally untuk menghasilkan tanggal atau melakukan pemisahan pada VARCHAR(8000). Jika Anda membuat tabel Tally 11.000 baris dengan indeks berkerumun yang benar pada "N", Anda akan memiliki cukup baris untuk membuat tanggal lebih dari 30 tahun (saya bekerja dengan hipotek sedikit sehingga 30 tahun adalah nomor kunci bagi saya ) dan tentu saja cukup untuk menangani pemisahan VARCHAR(8000). Mengapa "ukuran yang tepat" begitu penting? Jika tabel Tally sering digunakan, tabel Tally mudah disimpan di cache yang membuatnya sangat cepat tanpa banyak tekanan pada memori sama sekali.
Last but not least, setiap orang tahu bahwa jika Anda membuat tabel Tally permanen, tidak masalah metode mana yang Anda gunakan untuk membuatnya karena 1) itu hanya akan dibuat sekali dan 2) jika itu seperti 11.000 baris tabel, semua metode akan berjalan "cukup baik". Jadi mengapa semua kekesalan di pihak saya tentang metode mana yang harus digunakan???
Jawabannya adalah bahwa beberapa pria/wanita malang yang tidak tahu lebih baik dan hanya perlu menyelesaikan pekerjaannya mungkin melihat sesuatu seperti metode CTE Rekursif dan memutuskan untuk menggunakannya untuk sesuatu yang jauh lebih besar dan lebih sering digunakan daripada membangun tabel Tally permanen dan saya mencoba melindungi orang-orang itu, server yang menjalankan kode mereka, dan perusahaan yang memiliki data di server tersebut . Ya... itu masalah besar. Itu juga harus untuk semua orang. Ajarkan cara yang benar untuk melakukan sesuatu alih-alih "cukup baik". Lakukan beberapa pengujian sebelum memposting atau menggunakan sesuatu dari pos atau buku... kehidupan yang Anda selamatkan sebenarnya bisa menjadi milik Anda sendiri, terutama jika menurut Anda CTE rekursif adalah cara yang tepat untuk melakukan hal seperti ini.;-)
Terima kasih telah mendengarkan...
