INSERT INTO vs SELECT INTO


127

Apa perbedaan antara menggunakan

SELECT ... INTO MyTable FROM...

dan

INSERT INTO MyTable (...)
SELECT ... FROM ....

?

Dari BOL [ INSERT , SELECT ... INTO ], saya tahu bahwa menggunakan SELECT ... INTO akan membuat tabel penyisipan pada grup file default jika belum ada, dan bahwa pencatatan untuk pernyataan ini tergantung pada pemulihan model basis data.

  1. Pernyataan mana yang lebih disukai?
  2. Apakah ada implikasi kinerja lainnya?
  3. Apa kasus penggunaan yang baik untuk SELECT ... INTO over INSERT INTO ...?

Sunting: Saya sudah menyatakan bahwa saya tahu bahwa SELECT INTO ... membuat tabel di mana tidak ada. Yang ingin saya ketahui adalah bahwa SQL menyertakan pernyataan ini karena suatu alasan, apa itu? Apakah itu melakukan sesuatu yang berbeda di belakang layar untuk memasukkan baris, atau itu hanya gula sintaksis di atas CREATE TABLEdan INSERT INTO.


Satu faktor kecil: INSERT INTOmemiliki dua kata kunci (pilih & ke) tepat di depan yang membuat dunia tahu ini bukan pernyataan SQL biasa, sementara SELECT ... INTOmulai, setidaknya, terlihat seperti pernyataan SQL biasa. Alasan kecil untuk mendukung yang pertama.
Martin F

Jawaban:


122
  1. Mereka melakukan hal yang berbeda. Gunakan INSERTsaat tabel ada. Gunakan SELECT INTOsaat tidak.

  2. Iya. INSERTtanpa petunjuk tabel biasanya dicatat. SELECT INTOlog minimal dengan asumsi jejak bendera yang tepat diatur.

  3. Dalam pengalaman saya SELECT INTOpaling umum digunakan dengan set data menengah, seperti #temptabel, atau untuk menyalin seluruh tabel seperti untuk cadangan. INSERT INTOdigunakan ketika Anda memasukkan ke dalam tabel yang sudah ada dengan struktur yang dikenal.

EDIT

Untuk mengatasi hasil edit Anda, mereka melakukan hal yang berbeda. Jika Anda membuat tabel dan ingin mendefinisikan penggunaan struktur CREATE TABLEdan INSERT. Contoh masalah yang dapat dibuat: Anda memiliki tabel kecil dengan bidang varchar. String terbesar di tabel Anda sekarang adalah 12 byte. Kumpulan data nyata Anda akan membutuhkan hingga 200 byte. Jika Anda melakukannya SELECT INTOdari meja kecil Anda untuk membuat yang baru, nanti INSERTakan gagal dengan kesalahan pemotongan karena bidang Anda terlalu kecil.


4
Dua sen saya, saya pikir memperkenalkan kegagalan adalah hal yang baik. Saya ingin tahu apakah data saya tidak sesuai dengan format / ukuran data yang saya harapkan. Saya selalu mencoba mendefinisikan tabel saya menggunakan CREATE TABLEdan kemudian INSERT INTOJuga, lebih mudah untuk menguji SELECTpernyataan itu sendiri, tanpa mengeksekusi insert.
Doug Chamberlain

1
@Doug - Saya setuju. Saya hampir secara eksklusif menggunakan SELECT INTOuntuk membuat tabel temp atau untuk membuat cadangan cepat dari tabel yang sudah ada yang akan saya gunakan untuk mengunyah.
JNK

1
@ JNK - Dari BOL, SELECT INTO membuat tabel dengan struktur berdasarkan tipe data kolom dalam daftar pilih. Jadi, dalam contoh Anda, Anda bisa memperbaiki situasi dengan secara eksplisit melemparkan varchar ke ukuran yang cukup. Benar?
jowenece

2
@Jowenece - ya saya harap begitu. Jika saya akan kesulitan itu, saya akan pergi ke depan dan menggunakan CREATEpernyataan.
JNK

24
  1. Pernyataan mana yang lebih disukai? Tergantung pada apa yang Anda lakukan.

  2. Apakah ada implikasi kinerja lainnya? Jika tabel adalah tabel permanen, Anda dapat membuat indeks pada saat pembuatan tabel yang memiliki implikasi untuk kinerja baik secara negatif maupun positif. Pilih ke tidak membuat kembali indeks yang ada pada tabel saat ini dan dengan demikian penggunaan selanjutnya tabel mungkin lebih lambat dari yang seharusnya.

  3. Apa kasus penggunaan yang baik untuk SELECT ... INTO over INSERT INTO ...? Pilih ke digunakan jika Anda mungkin tidak tahu struktur tabel di muka. Lebih cepat menulis daripada membuat tabel dan menyisipkan pernyataan, sehingga digunakan untuk mempercepat pengembangan pada waktu-waktu tertentu. Sering kali lebih cepat digunakan ketika Anda membuat tabel temp cepat untuk menguji hal-hal atau tabel cadangan dari permintaan tertentu (mungkin catatan yang akan Anda hapus). Seharusnya jarang melihatnya digunakan dalam kode produksi yang akan berjalan beberapa kali (kecuali untuk tabel temp) karena akan gagal jika tabel sudah ada.

Kadang-kadang digunakan secara tidak tepat oleh orang-orang yang tidak tahu apa yang mereka lakukan. Dan mereka dapat menyebabkan kerusakan pada db sebagai hasilnya. Saya sangat merasa tidak pantas untuk menggunakan SELECT INTO untuk apa pun selain meja sekali pakai (cadangan sementara, tabel temp yang akan hilang di akhir proc yang disimpan, dll.). Tabel permanen membutuhkan pemikiran nyata mengenai desainnya dan SELECT INTO membuatnya mudah untuk tidak memikirkan apa pun, bahkan mendasar seperti kolom apa dan tipe data apa.

Secara umum, saya lebih suka menggunakan tabel buat dan masukkan pernyataan - Anda memiliki lebih banyak kontrol dan lebih baik untuk proses berulang. Selanjutnya, jika tabel adalah tabel permanen, itu harus dibuat dari skrip buat tabel terpisah (yang ada di kontrol sumber) karena membuat objek permanen tidak boleh, secara umum, dalam kode adalah menyisipkan / menghapus / memperbarui atau memilih dari meja. Perubahan objek harus ditangani secara terpisah dari perubahan data karena objek memiliki implikasi di luar kebutuhan penyisipan / pembaruan / pilih / hapus tertentu. Anda perlu mempertimbangkan tipe data terbaik, pikirkan kendala FK, PK dan kendala lainnya, pertimbangkan persyaratan audit, pikirkan pengindeksan, dll.


5

Perbedaan utama adalah bahwa SELECT INTO MyTable akan membuat tabel baru yang disebut MyTable dengan hasilnya, sementara INSERT INTO mensyaratkan bahwa MyTable sudah ada.

Anda akan menggunakan SELECT INTO hanya dalam kasus di mana tabel tidak ada dan Anda ingin membuatnya berdasarkan hasil kueri Anda. Dengan demikian, kedua pernyataan ini benar-benar tidak dapat dibandingkan. Mereka melakukan hal yang sangat berbeda.

Secara umum, SELECT INTO digunakan lebih sering untuk satu tugas, sedangkan INSERT INTO digunakan secara teratur untuk menambahkan baris ke tabel.

Suntingan:
Meskipun Anda bisa menggunakan CREATE TABLE dan INSERT INTO untuk menyelesaikan apa yang SELECT INTO lakukan, dengan SELECT INTO Anda tidak harus mengetahui definisi tabel sebelumnya. SELECT INTO mungkin termasuk dalam SQL karena membuat tugas-tugas seperti pelaporan ad hoc atau menyalin tabel menjadi lebih mudah.


CREATE TABLE dan SELECT INTO adalah hal yang sama (tidak perlu INSERT INTO sebagai tambahan untuk menyelesaikan apa yang SELECT INTO lakukan) dan SELECT INTO tidak direkomendasikan menurut saya. Lihat dba.stackexchange.com/questions/156105/… .
Rick

4

Setiap pernyataan memiliki use case yang berbeda. Mereka tidak bisa dipertukarkan.

SELECT...INTO MyTable...menciptakan yang baru di MyTablemana seseorang tidak ada sebelumnya.

INSERT INTO MyTable...SELECT...digunakan saat MyTablesudah ada.


4
Anda tidak menjawab pertanyaan saya dan saya sudah menyatakan jawaban Anda.
jowenece

5
Jawaban atas pertanyaan Anda tersirat. Untuk membuatnya lebih jelas, tidak ada pernyataan "disukai" karena masing-masing memiliki kasus penggunaan yang berbeda. Pernyataan tidak bisa dipertukarkan. Gunakan versi pertama ketika Anda ingin membuat tabel baru yang tidak ada. Gunakan versi kedua saat tabel sudah ada.
Joe Stefanelli

2
Mengapa saya ingin melakukan itu vs membuat tabel temp dan kemudian memasukkannya ke dalamnya? Apakah ada keuntungannya?
jowenece

4

Sebenarnya SELECT ... INTO tidak hanya membuat tabel tetapi akan gagal jika sudah ada, jadi pada dasarnya satu-satunya waktu Anda akan menggunakannya adalah ketika tabel yang Anda masukkan tidak ada.

Sehubungan dengan EDIT Anda:

Saya pribadi terutama menggunakan SELECT ... INTO ketika saya membuat tabel temp. Bagi saya itu adalah kegunaan utama. Namun saya juga menggunakannya ketika membuat tabel baru dengan banyak kolom dengan struktur yang mirip dengan tabel lain dan kemudian mengeditnya untuk menghemat waktu.


1
Saya terutama melihat penggunaan SELECT..INTO untuk tabel temp juga, tetapi apakah ada alasan untuk lebih suka membuat tabel temp dengan pernyataan CREATE TABLE? Misalnya - perolehan kinerja?
jowenece

3
@ jowenece Saya pikir terutama untuk kesederhanaan ... Juga katakan Anda memiliki permintaan dinamis. Saya tidak tahu strukturnya, Anda tidak bisa membuat tabel sebelumnya, dan lebih mudah untuk menggunakan SELECT ... INTO daripada membuat tabel secara dinamis.
AJC

3

SELECT INTO biasanya digunakan untuk menghasilkan tabel temp atau untuk menyalin tabel lain (data dan / atau struktur).

Dalam kode sehari-hari Anda menggunakan INSERT karena tabel Anda seharusnya sudah ada untuk dibaca, UPDATEd, DELETEd, JOINed dll. Catatan: kata kunci INTO adalah opsional dengan INSERT

Yaitu, aplikasi biasanya tidak akan membuat dan menjatuhkan tabel sebagai bagian dari operasi normal kecuali jika itu adalah tabel sementara untuk beberapa lingkup penggunaan terbatas dan spesifik.

Tabel yang dibuat oleh SELECT INTO tidak akan memiliki kunci atau indeks atau kendala tidak seperti tabel nyata, bertahan, sudah ada

2 tidak dapat dibandingkan secara langsung karena mereka hampir tidak memiliki tumpang tindih dalam penggunaan


2

Saya hanya ingin membahas poin kedua dari pertanyaan yang terkait dengan kinerja, karena tidak ada orang lain yang membahas hal ini. Select Into jauh lebih cepat daripada menyisipkan ke dalam, ketika datang ke tabel dengan dataset besar. Saya lebih suka memilih ketika saya harus membaca tabel yang sangat besar. masukkan ke dalam untuk sebuah tabel dengan 10 juta baris mungkin memakan waktu berjam-jam sementara pilih ke dalam akan melakukan ini dalam beberapa menit, dan untuk yang kehilangan indeks pada tabel baru yang bersangkutan Anda dapat membuat ulang indeks dengan permintaan dan masih dapat menghemat lebih banyak waktu bila dibandingkan dengan Masukkan ke dalam.


Itu benar, tapi itu terutama karena SQL Server tahu bahwa tidak ada pertengkaran untuk tabel tujuan. Kinerja untuk insert into #temp with(tablock) select * from ..kira-kira sama dengan kinerja untukselect * into #temp from ...
Brian

1

Pilih ke dalam buat tabel baru untuk Anda pada saat itu dan kemudian masukkan catatan di dalamnya dari tabel sumber. Tabel yang baru dibuat memiliki struktur yang sama dengan tabel sumber. Jika Anda mencoba menggunakan pilih ke dalam untuk tabel yang ada, itu akan menghasilkan kesalahan, karena akan mencoba membuat tabel baru dengan nama yang sama. Masukkan ke dalam membutuhkan tabel untuk ada di database Anda sebelum Anda memasukkan baris di dalamnya.


1

Perbedaan sederhana antara pilih Ke dan Sisipkan Ke adalah: -> Pilih Ke tidak perlu tabel yang ada. Jika Anda ingin menyalin data tabel A, Anda cukup ketik Select * INTO [tablename] dari A. Di sini, tablename dapat berupa tabel yang ada atau tabel baru akan dibuat yang memiliki struktur yang sama seperti tabel A.

-> Masukkan Ke perlu tabel yang ada. MASUK KE [nama tab] SELECT * FROM A ;. Di sini tablename adalah tabel yang sudah ada.

Select Into biasanya lebih populer untuk menyalin data terutama data cadangan.

Anda dapat menggunakan sesuai kebutuhan Anda, itu benar-benar pilihan pengembang yang harus digunakan dalam skenarionya.

Performa bijak Masukkan INTO cepat.

Referensi :

https://www.w3schools.com/sql/sql_insert_into_select.asp https://www.w3schools.com/sql/sql_sql_select_into.asp


-2

Pilih ke dalam untuk dataset besar mungkin hanya baik untuk satu pengguna menggunakan satu koneksi tunggal ke database melakukan tugas operasi massal. Saya tidak merekomendasikan untuk menggunakan

SELECT * INTO table

karena ini membuat satu transaksi besar dan membuat kunci skema untuk membuat objek, mencegah pengguna lain untuk membuat objek atau mengakses objek sistem hingga SELECT INTOoperasi selesai.

Sebagai bukti konsep membuka 2 sesi, pada sesi pertama coba gunakan

select into temp table from a huge table 

dan di bagian kedua coba

create a temp table 

dan periksa kunci, pemblokiran, dan durasi sesi kedua untuk membuat objek tabel temp. Rekomendasi saya itu selalu merupakan praktik yang baik untuk membuat dan menyisipkan pernyataan dan jika diperlukan untuk penebangan minimal menggunakan jejak jejak 610

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.