Mengapa orang sangat membenci kursor SQL? [tertutup]

"Overhead" dengan kursor hanyalah bagian dari API. Kursor adalah cara kerja bagian RDBMS. Seringkali CREATE TABLE dan INSERT memiliki pernyataan SELECT, dan implementasinya adalah implementasi kursor internal yang jelas.

Menggunakan "operator berbasis set" tingkat yang lebih tinggi menggabungkan hasil kursor ke dalam satu set hasil, yang berarti lebih sedikit API yang bolak-balik.

Kursor sudah ada sebelum bahasa modern yang menyediakan koleksi kelas satu. C lama, COBOL, Fortran, dll., harus memproses baris satu per satu karena tidak ada pengertian "koleksi" yang dapat digunakan secara luas. Java, C#, Python, dll., memiliki struktur daftar kelas satu untuk menampung kumpulan hasil.

Masalah Lambat

Di beberapa kalangan, gabungan relasional adalah sebuah misteri, dan orang-orang akan menulis kursor bersarang daripada gabungan sederhana. Saya telah melihat operasi loop bersarang yang benar-benar epik ditulis sebagai banyak sekali kursor. Mengalahkan optimasi RDBMS. Dan berjalan sangat lambat.

Penulisan ulang SQL sederhana untuk menggantikan loop kursor bersarang dengan gabungan dan satu loop kursor datar dapat membuat program berjalan ke-100 kalinya. [Mereka mengira saya adalah dewa pengoptimalan. Yang saya lakukan hanyalah mengganti loop bersarang dengan gabungan. Masih menggunakan kursor.]

Kebingungan ini seringkali berujung pada tuduhan terhadap kursor. Namun, bukan kursornya, melainkan penyalahgunaan kursor itulah masalahnya.

Masalah Ukuran

Untuk kumpulan hasil yang benar-benar epik (yaitu, membuang tabel ke file), kursor sangat penting. Operasi berbasis kumpulan tidak dapat mewujudkan kumpulan hasil yang sangat besar sebagai satu kumpulan di memori.

Alternatif

Saya mencoba menggunakan lapisan ORM sebanyak mungkin. Tapi itu memiliki dua tujuan. Pertama, kursor dikelola oleh komponen ORM. Kedua, SQL dipisahkan dari aplikasi ke dalam file konfigurasi. Bukan berarti kursornya buruk. Pengkodean semua pembukaan, penutupan, dan pengambilan bukanlah pemrograman yang bernilai tambah.

Kursor membuat orang terlalu menerapkan pola pikir prosedural pada lingkungan berbasis himpunan.

Dan semuanya LAMBAT!!!

Dari SQLTeam:

Harap dicatat bahwa kursor adalah cara paling lambat untuk mengakses data di dalam SQL Server. Ini hanya boleh digunakan ketika Anda benar-benar perlu mengakses satu baris dalam satu waktu. Satu-satunya alasan yang dapat saya pikirkan adalah memanggil prosedur tersimpan di setiap baris. Dalam artikel Kinerja Kursor saya menemukan bahwa kursor lebih dari tiga puluh kali lebih lambat daripada yang disetel alternatif berbasis.

Ada jawaban di atas yang mengatakan "kursor adalah cara paling lambat untuk mengakses data di dalam SQL Server... kursor lebih dari tiga puluh kali lebih lambat daripada alternatif berbasis set."

Pernyataan ini mungkin benar dalam banyak keadaan, namun sebagai pernyataan menyeluruh, pernyataan ini bermasalah. Misalnya, saya telah memanfaatkan kursor dengan baik dalam situasi di mana saya ingin melakukan operasi pembaruan atau penghapusan yang memengaruhi banyak baris tabel besar yang menerima pembacaan produksi konstan. Menjalankan prosedur tersimpan yang melakukan pembaruan ini satu per satu baris akan menjadi lebih cepat daripada operasi berbasis set, karena operasi berbasis set bertentangan dengan operasi baca dan akhirnya menyebabkan masalah penguncian yang parah (dan dapat mematikan sistem produksi sepenuhnya, dalam kasus ekstrim).

Dengan tidak adanya aktivitas database lainnya, operasi berbasis set secara umum lebih cepat. Dalam sistem produksi, itu tergantung.

Kursor cenderung digunakan oleh pengembang SQL pemula di tempat di mana operasi berbasis set akan lebih baik. Khususnya ketika orang mempelajari SQL setelah mempelajari bahasa pemrograman tradisional, mentalitas "mengulangi catatan-catatan ini" cenderung membuat orang menggunakan kursor secara tidak tepat.

Kebanyakan buku SQL yang serius menyertakan bab yang memerintahkan penggunaan kursor; yang ditulis dengan baik memperjelas bahwa kursor memiliki tempatnya tetapi tidak boleh digunakan untuk operasi berbasis set.

Jelas ada situasi di mana kursor adalah pilihan yang tepat, atau setidaknya pilihan yang benar.

Pengoptimal sering kali tidak dapat menggunakan aljabar relasional untuk mengubah masalah ketika metode kursor digunakan. Seringkali kursor adalah cara yang bagus untuk menyelesaikan suatu masalah, namun SQL adalah bahasa deklaratif, dan terdapat banyak informasi dalam database, mulai dari batasan, hingga statistik dan indeks yang berarti bahwa pengoptimal memiliki banyak opsi untuk menyelesaikan masalah. masalah, sedangkan kursor secara eksplisit mengarahkan solusinya.

Di Oracle PL/SQL, kursor tidak akan menghasilkan kunci tabel dan dimungkinkan untuk menggunakan pengumpulan massal/pengambilan massal.

Di Oracle 10 kursor implisit yang sering digunakan

  for x in (select ....) loop
    --do something 
  end loop;

mengambil secara implisit 100 baris sekaligus. Pengumpulan massal/pengambilan massal secara eksplisit juga dimungkinkan.

Namun kursor PL/SQL adalah pilihan terakhir, gunakan kursor tersebut ketika Anda tidak dapat menyelesaikan masalah dengan SQL berbasis set.

Alasan lainnya adalah paralelisasi, lebih mudah bagi database untuk memparalelkan pernyataan berbasis himpunan besar daripada kode imperatif baris demi baris. Ini adalah alasan yang sama mengapa pemrograman fungsional menjadi semakin populer (Haskell, F#, Lisp, C# LINQ, MapReduce ...), pemrograman fungsional membuat paralelisasi lebih mudah. Jumlah CPU per komputer meningkat sehingga paralelisasi menjadi semakin menjadi masalah.

Secara umum, karena pada database relasional, performa kode yang menggunakan kursor jauh lebih buruk daripada operasi berbasis set.

Jawaban di atas belum cukup menekankan pentingnya mengunci. Saya bukan penggemar kursor karena sering mengakibatkan kunci tingkat tabel.

Untuk apa nilainya, saya telah membaca bahwa "satu" tempat kursor akan melakukan kinerja mitranya yang berbasis set berada dalam total berjalan. Pada tabel kecil, kecepatan menjumlahkan baris berdasarkan urutan kolom mendukung operasi berbasis himpunan, tetapi seiring bertambahnya ukuran baris tabel, kursor akan menjadi lebih cepat karena kursor dapat dengan mudah membawa nilai total yang berjalan ke lintasan berikutnya. lingkaran. Sekarang di mana Anda harus melakukan running total adalah argumen yang berbeda...

Di luar masalah kinerja (bukan), menurut saya kegagalan terbesar kursor adalah sulitnya melakukan debug. Terutama dibandingkan dengan kode di sebagian besar aplikasi klien di mana proses debug cenderung relatif mudah dan fitur bahasa cenderung lebih mudah. Faktanya, saya berpendapat bahwa hampir semua hal yang dilakukan seseorang dalam SQL dengan kursor mungkin seharusnya terjadi di aplikasi klien.

Bisakah Anda memposting contoh kursor atau tautan ke pertanyaan? Mungkin ada cara yang lebih baik daripada CTE rekursif.

Selain komentar lain, kursor bila digunakan secara tidak benar (yang sering kali) menyebabkan kunci halaman/baris yang tidak perlu.

Anda mungkin bisa menyimpulkan pertanyaan Anda setelah paragraf kedua, daripada menyebut orang "gila" hanya karena mereka memiliki sudut pandang yang berbeda dari Anda dan mencoba mengejek para profesional yang mungkin memiliki alasan bagus untuk merasakan apa yang mereka rasakan.

Mengenai pertanyaan Anda, walaupun ada situasi di mana kursor mungkin diperlukan, menurut pengalaman saya, pengembang memutuskan bahwa kursor "harus" digunakan JAUH lebih sering daripada yang sebenarnya terjadi. Kemungkinan seseorang melakukan kesalahan karena terlalu banyak menggunakan kursor vs. tidak menggunakannya pada saat yang seharusnya JAUH lebih tinggi menurut saya.

pada dasarnya 2 blok kode yang melakukan hal yang sama. mungkin ini contoh yang agak aneh tapi itu membuktikan maksudnya. SQLServer 2005:

SELECT * INTO #temp FROM master..spt_values
DECLARE @startTime DATETIME

BEGIN TRAN 

SELECT @startTime = GETDATE()
UPDATE #temp
SET number = 0
select DATEDIFF(ms, @startTime, GETDATE())

ROLLBACK 

BEGIN TRAN 
DECLARE @name VARCHAR

DECLARE tempCursor CURSOR
    FOR SELECT name FROM #temp

OPEN tempCursor

FETCH NEXT FROM tempCursor 
INTO @name

SELECT @startTime = GETDATE()
WHILE @@FETCH_STATUS = 0
BEGIN

    UPDATE #temp SET number = 0 WHERE NAME = @name
    FETCH NEXT FROM tempCursor 
    INTO @name

END 
select DATEDIFF(ms, @startTime, GETDATE())
CLOSE tempCursor
DEALLOCATE tempCursor

ROLLBACK 
DROP TABLE #temp

pembaruan tunggal membutuhkan waktu 156 mdtk sedangkan kursor membutuhkan waktu 2016 mdtk.