GABUNG kueri vs beberapa kueri


180

Apakah BERGABUNG dengan kueri lebih cepat dari beberapa kueri? (Anda menjalankan permintaan utama Anda, dan kemudian Anda menjalankan banyak SELECT lain berdasarkan hasil dari permintaan utama Anda)

Saya bertanya karena BERGABUNG dengan mereka akan menyulitkan BANYAK desain aplikasi saya

Jika mereka lebih cepat, adakah yang bisa memperkirakan kurang lebih berapa banyak? Jika 1,5x saya tidak peduli, tetapi jika 10x saya kira saya lakukan.


Saya berasumsi mereka akan lebih cepat. Saya tahu bahwa satu INSERT dibandingkan dengan mengatakan 10 permintaan individu INSERT jauh lebih cepat.
alex

1
Mungkin penting apakah beberapa kueri Anda ada di dalam prosedur tersimpan jika berasal dari aplikasi (edit pertanyaan Anda dengan info ini). Yang pertama akan jauh lebih cepat daripada nanti.
colithium

Jawaban:


82

Ini terlalu samar untuk memberi Anda jawaban yang relevan dengan kasus spesifik Anda. Itu tergantung pada banyak hal. Jeff Atwood (pendiri situs ini) sebenarnya menulis tentang ini . Namun, untuk sebagian besar, jika Anda memiliki indeks yang tepat dan Anda melakukan GABUNGAN dengan benar, biasanya akan lebih cepat untuk melakukan 1 perjalanan daripada beberapa.


2
jika Anda bergabung dengan 3 atau lebih tabel pada kunci yang berbeda, seringkali basis data (mis. mysql) hanya dapat menggunakan satu indeks per tabel, artinya mungkin salah satu gabungan akan cepat (dan menggunakan indeks) sedangkan yang lain akan sangat lambat. Untuk beberapa kueri, Anda bisa mengoptimalkan indeks yang digunakan untuk setiap kueri.
user151975

4
Saya pikir ini tergantung pada definisi Anda tentang "lebih cepat" ... misalnya, 3 PK dalam bergabung dapat berbalik lebih cepat dari 4 round-trip, karena overhead jaringan, dan karena Anda perlu berhenti dan mempersiapkan dan mengirim setiap permintaan setelah kueri sebelumnya selesai. Namun, jika Anda melakukan benchmark server yang sedang dimuat, dalam banyak kasus, bergabung akan membutuhkan lebih banyak waktu CPU vs permintaan PK, dan seringkali menyebabkan lebih banyak overhead jaringan juga.
mindplay.dk

97

Untuk gabungan dalam, satu permintaan masuk akal, karena Anda hanya mendapatkan baris yang cocok. Untuk gabungan kiri, banyak kueri jauh lebih baik ... lihat patokan yang saya lakukan berikut:

  1. Permintaan tunggal dengan 5 Bergabung

    permintaan: 8.074508 detik

    ukuran hasil: 2268000

  2. 5 kueri berturut-turut

    waktu permintaan gabungan: 0,00262 detik

    ukuran hasil: 165 (6 + 50 + 7 + 12 + 90)

.

Perhatikan bahwa kami mendapatkan hasil yang sama dalam kedua kasus (6 x 50 x 7 x 12 x 90 = 2268000)

gabungan kiri menggunakan lebih banyak memori secara eksponensial dengan data yang berlebihan.

Batas memori mungkin tidak seburuk jika Anda hanya menggabungkan dua tabel, tetapi umumnya tiga atau lebih dan itu menjadi pertanyaan yang berbeda nilainya.

Sebagai catatan, server MySQL saya berada tepat di samping server aplikasi saya ... jadi waktu koneksi dapat diabaikan. Jika waktu koneksi Anda dalam hitungan detik, maka mungkin ada manfaatnya

jujur


31
Jika kita membuang fakta kecil yang menyebalkan bahwa tidak ada orang waras yang melakukan persilangan antara 5 tabel (karena alasan itu, dan dalam kebanyakan kasus itu tidak masuk akal ), "tolok ukur" Anda mungkin memiliki beberapa kelebihan . Tetapi gabungan kiri atau batin adalah norma, biasanya dengan kunci (membuat pengambilan lebih cepat), dan duplikasi data biasanya jauh, jauh lebih sedikit daripada yang Anda lakukan.
cao

12
@ Hao mengatakan siapa? Saya baru saja melihat SMF dan phpBB dan melihat GABUNG di antara 3 tabel - jika Anda menambahkan plugin atau modifikasi, mereka dapat dengan mudah menambahkannya. Segala jenis aplikasi besar memiliki potensi untuk banyak BERGABUNG. Bisa dibilang ORM yang ditulis dengan salah penggunaannya bisa GABUNG tabel yang sebenarnya tidak perlu (bahkan mungkin setiap tabel).
Natalie Adams

5
@NathanAdams: Gabungan kiri dan dalam sama sekali tidak buruk. (Bahkan, jika Anda tidak bergabung dengan tabel di sana-sini, Anda melakukan SQL yang salah.) Apa yang saya bicarakan adalah cross joins , yang hampir selalu tidak diinginkan bahkan di antara dua tabel, apalagi 5 - dan yang akan menjadi satu-satunya cara untuk mendapatkan hasil "2268000" yang benar-benar palsu yang disebutkan di atas.
cao

2
Lihatlah hasilnya. "ukuran hasil: 2268000" versus "ukuran hasil: 165". Saya pikir perlambatan Anda dengan BERGABUNG adalah karena catatan Anda memiliki hubungan satu-ke-banyak satu sama lain, sedangkan jika mereka memiliki hubungan satu-ke-satu, GABUNG pasti akan jauh lebih cepat dan pasti tidak akan menghasilkan hasil ukuran lebih besar dari SELECT.
HoldOffHunger

3
@cHao Jelas Anda belum bertemu Magento pada saat komentar pertama Anda
vitoriodachef

26

Pertanyaan ini sudah lama, tetapi tidak memiliki beberapa tolok ukur. Saya membandingkan BERGABUNG dengan 2 pesaingnya:

  • N + 1 kueri
  • 2 pertanyaan, yang kedua menggunakan WHERE IN(...)atau setara

Hasilnya adalah jelas: pada MySQL, JOINadalah jauh lebih cepat. N + 1 kueri dapat menurunkan kinerja aplikasi secara drastis:

GABUNG vs DI MANA vs N +1

Yaitu, kecuali jika Anda memilih banyak catatan yang menunjukkan sejumlah kecil catatan asing yang berbeda. Berikut ini adalah patokan untuk kasus ekstrim:

GABUNG vs N +1 - semua catatan menunjuk ke catatan asing yang sama

Ini sangat tidak mungkin terjadi dalam aplikasi tipikal, kecuali jika Anda bergabung dengan hubungan-ke-banyak, dalam hal ini kunci asing ada di tabel lain, dan Anda menduplikasi data tabel utama berkali-kali.

Bawa pulang:

  • Untuk hubungan * ke satu, selalu gunakan JOIN
  • Untuk * -ke-banyak hubungan, kueri kedua mungkin lebih cepat

Lihat artikel saya di Media untuk informasi lebih lanjut.


22

Saya benar-benar datang ke pertanyaan ini mencari jawaban sendiri, dan setelah membaca jawaban yang diberikan saya hanya bisa setuju bahwa cara terbaik untuk membandingkan kinerja permintaan DB adalah untuk mendapatkan angka dunia nyata karena hanya ada banyak variabel yang harus diperhitungkan TETAPI, saya juga berpikir bahwa membandingkan angka-angka di antara keduanya tidak ada gunanya di hampir semua kasus. Yang saya maksud adalah bahwa angka-angka harus selalu dibandingkan dengan angka yang dapat diterima dan jelas tidak dibandingkan satu sama lain.

Saya bisa mengerti jika satu cara query membutuhkan waktu 0,02 detik dan yang lain membutuhkan waktu 20 detik, itu perbedaan yang sangat besar. Tetapi bagaimana jika satu cara query membutuhkan 0,0000000002 detik, dan yang lainnya membutuhkan 0,0000002 detik? Dalam kedua kasus satu cara adalah kekalahan 1000 kali lebih cepat daripada yang lain, tetapi apakah itu benar - benar masih "kekalahan" dalam kasus kedua?

Intinya seperti yang saya pribadi melihatnya: jika berkinerja baik, pilih solusi yang mudah.


4
Itu, tentu saja, tergantung pada apakah Anda berencana penskalaan atau tidak. Karena ketika facebook mulai, saya yakin mereka memiliki pertanyaan semacam itu, tetapi memiliki scaling dalam pikiran dan pergi untuk solusi yang lebih efisien walaupun mungkin lebih kompleks.
dudewad

@deweward Masuk akal. Itu semua tergantung pada apa yang Anda butuhkan, pada akhirnya.
Valentin Flachsel

4
Haha ya ... karena di google 1 nanosecond hilang secara harfiah sama dengan sekitar 10 miliar triliun dolar ... tapi itu hanya rumor.
dudewad

2
@deweward Sebenarnya, ketika Facebook dimulai, saya jamin mereka pergi dengan solusi yang lebih sederhana. Zuckerberg mengatakan dia memprogram versi pertama hanya dalam 2 minggu. Para pemula harus bergerak cepat untuk bersaing dan yang bertahan biasanya tidak perlu khawatir tentang penskalaan sampai mereka benar-benar membutuhkannya. Kemudian mereka melakukan refactor setelah jutaan dolar investasi dan dapat merekrut programmer rockstar yang berspesialisasi dalam kinerja. Untuk Anda, saya berharap Facebook sering mencari solusi yang lebih kompleks untuk peningkatan kinerja menit sekarang, tetapi kemudian kebanyakan dari kita tidak memprogram Facebook.
dallin

15

Lakukan tes cepat memilih satu baris dari tabel 50.000 baris dan bergabung dengan satu baris dari tabel 100.000 baris. Pada dasarnya tampak seperti:

$id = mt_rand(1, 50000);
$row = $db->fetchOne("SELECT * FROM table1 WHERE id = " . $id);
$row = $db->fetchOne("SELECT * FROM table2 WHERE other_id = " . $row['other_id']);

vs.

$id = mt_rand(1, 50000);
$db->fetchOne("SELECT table1.*, table2.*
    FROM table1
    LEFT JOIN table1.other_id = table2.other_id
    WHERE table1.id = " . $id);

Metode dua pilihan mengambil 3,7 detik untuk 50.000 membaca sedangkan JOIN mengambil 2,0 detik pada komputer lambat di rumah saya. INNER JOIN dan LEFT JOIN tidak membuat perbedaan. Mengambil beberapa baris (misalnya, menggunakan IN SET) menghasilkan hasil yang serupa.


1
Mungkin perbedaannya akan berubah jika memilih halaman baris (seperti 20 atau 50) seolah-olah untuk kotak tampilan web yang khas, dan membandingkan satu LEFT JOIN dengan dua pertanyaan - memilih 2 atau 3 pengidentifikasi dengan beberapa kriteria WHERE dan kemudian menjalankan yang lain PILIH kueri dengan IN ().
JustAMartin

Apakah id kolom dan other_id diindeks?
Aarish Ramesh

11

Pertanyaan sebenarnya adalah: Apakah catatan-catatan ini memiliki hubungan satu-ke-satu atau hubungan satu-ke-banyak ?

Jawaban TLDR:

Jika satu-ke-satu, gunakan JOINpernyataan.

Jika satu-ke-banyak, gunakan satu (atau banyak) SELECTpernyataan dengan optimasi kode sisi-server.

Mengapa dan Cara Menggunakan SELECT untuk Optimasi

SELECT(dengan beberapa kueri alih-alih bergabung) pada kelompok besar catatan berdasarkan hubungan satu-ke-banyak menghasilkan efisiensi yang optimal, karena JOINmemiliki masalah kebocoran memori yang eksponensial. Raih semua data, lalu gunakan bahasa skrip sisi server untuk mengurutkannya:

SELECT * FROM Address WHERE Personid IN(1,2,3);

Hasil:

Address.id : 1            // First person and their address
Address.Personid : 1
Address.City : "Boston"

Address.id : 2            // First person's second address
Address.Personid : 1
Address.City : "New York"

Address.id : 3            // Second person's address
Address.Personid : 2
Address.City : "Barcelona"

Di sini, saya mendapatkan semua catatan, dalam satu pernyataan pilih. Ini lebih baik daripada JOIN, yang akan mendapatkan sekelompok kecil catatan ini, satu per satu, sebagai sub-komponen dari permintaan lain. Lalu saya menguraikannya dengan kode sisi server yang terlihat seperti ...

<?php
    foreach($addresses as $address) {
         $persons[$address['Personid']]->Address[] = $address;
    }
?>

Kapan Tidak Menggunakan GABUNG untuk Optimasi

JOIN'ing sekelompok besar catatan berdasarkan pada hubungan satu-ke-satu dengan satu catatan tunggal menghasilkan efisiensi yang optimal dibandingkan dengan beberapa SELECTpernyataan, satu demi satu, yang hanya mendapatkan jenis catatan berikutnya.

Tetapi JOINtidak efisien ketika mendapatkan catatan dengan hubungan satu-ke-banyak.

Contoh: Basis data Blog memiliki 3 tabel minat, Blogpost, Tag, dan Komentar.

SELECT * from BlogPost
LEFT JOIN Tag ON Tag.BlogPostid = BlogPost.id
LEFT JOIN Comment ON Comment.BlogPostid = BlogPost.id;

Jika ada 1 blogpost, 2 tag, dan 2 komentar, Anda akan mendapatkan hasil seperti:

Row1: tag1, comment1,
Row2: tag1, comment2,
Row3: tag2, comment1,
Row4: tag2, comment2,

Perhatikan bagaimana setiap rekaman digandakan. Oke, jadi, 2 komentar dan 2 tag adalah 4 baris. Bagaimana jika kita memiliki 4 komentar dan 4 tag? Anda tidak mendapatkan 8 baris - Anda mendapatkan 16 baris:

Row1: tag1, comment1,
Row2: tag1, comment2,
Row3: tag1, comment3,
Row4: tag1, comment4,
Row5: tag2, comment1,
Row6: tag2, comment2,
Row7: tag2, comment3,
Row8: tag2, comment4,
Row9: tag3, comment1,
Row10: tag3, comment2,
Row11: tag3, comment3,
Row12: tag3, comment4,
Row13: tag4, comment1,
Row14: tag4, comment2,
Row15: tag4, comment3,
Row16: tag4, comment4,

Tambahkan lebih banyak tabel, lebih banyak catatan, dll., Dan masalah akan dengan cepat mengembang ke ratusan baris yang semuanya penuh dengan sebagian besar data yang berlebihan.

Berapa biaya duplikat ini bagi Anda? Memori (di server SQL dan kode yang mencoba untuk menghapus duplikat) dan sumber daya jaringan (antara SQL server dan server kode Anda).

Sumber: https://dev.mysql.com/doc/refman/8.0/en/nested-join-optimization.html ; https://dev.mysql.com/doc/workbench/en/wb-relationship-tools.html


Anda melewatkan intinya. Ini bukan tentang satu-ke-satu (satu | banyak). Ini tentang apakah set baris masuk akal dipasangkan bersama. Anda meminta hanya dua set data terkait tangensial. Jika Anda meminta komentar dan, misalnya, info kontak penulisnya, itu lebih masuk akal sebagai gabungan, meskipun orang mungkin dapat menulis lebih dari satu komentar.
cao

@ cHao: Terima kasih atas komentar Anda. Jawaban saya di atas adalah ringkasan dari Dokumentasi MySQL yang ditemukan di sini: dev.mysql.com/doc/workbench/en/wb-relationship-tools.html
HoldOffHunger

Itu bukan dokumentasi MySQL. Ini dokumentasi untuk alat GUI tertentu untuk bekerja dengan database MySQL. Dan itu tidak menawarkan panduan apa pun ketika bergabung adalah (atau tidak) tepat.
cHao

@ cHao: Maaf, maksud saya dokumentasi MySQL (R) untuk MySQL WorkBench (TM), bukan MySQL Server (TM).
HoldOffHunger

Selain kesedihan, relevansinya tidak jelas. Keduanya menyebutkan hubungan satu-ke-satu dan satu-ke-banyak, tetapi di situlah kesamaan berakhir. Either way, masalahnya adalah tentang hubungan antara set data. Bergabunglah dengan dua set yang tidak terkait, Anda akan mendapatkan setiap kombinasi dari keduanya. Pecah data terkait menjadi beberapa pilihan, dan sekarang Anda telah melakukan beberapa pertanyaan untuk keuntungan yang meragukan, dan mulai melakukan pekerjaan MySQL untuk itu.
cao

8

Buat kueri dan gabungkan yang terpisah, lalu tentukan waktu masing-masing - tidak ada yang lebih membantu daripada angka dunia nyata.

Kemudian bahkan lebih baik - tambahkan "JELASKAN" ke awal setiap permintaan. Ini akan memberi tahu Anda berapa banyak subqueries yang digunakan MySQL untuk menjawab permintaan Anda akan data, dan berapa banyak baris yang dipindai untuk setiap permintaan.


7

Bergantung pada kompleksitas untuk database dibandingkan dengan kompleksitas pengembang, mungkin lebih mudah untuk melakukan banyak panggilan SELECT.

Coba jalankan beberapa statistik basis data terhadap JOIN dan beberapa SELECTS. Lihat apakah di lingkungan Anda GABUNG lebih cepat / lebih lambat dari SELECT.

Kemudian lagi, jika mengubahnya menjadi BERGABUNG akan berarti hari tambahan / minggu / bulan pekerjaan dev, saya akan tetap dengan beberapa SELECT

Bersulang,

BLT


5

Dalam pengalaman saya, saya telah menemukan itu biasanya lebih cepat untuk menjalankan beberapa permintaan, terutama ketika mengambil set data yang besar.

Ketika berinteraksi dengan database dari aplikasi lain, seperti PHP, ada argumen satu perjalanan ke server lebih banyak.

Ada cara lain untuk membatasi jumlah perjalanan yang dilakukan ke server dan masih menjalankan beberapa kueri yang seringkali tidak hanya lebih cepat tetapi juga membuat aplikasi lebih mudah dibaca - misalnya mysqli_multi_query.

Saya bukan pemula dalam hal SQL, saya pikir ada kecenderungan untuk pengembang, terutama junior untuk menghabiskan banyak waktu mencoba untuk menulis gabungan yang sangat pintar karena mereka terlihat pintar, sedangkan sebenarnya ada cara pintar untuk mengekstrak data yang terlihat sederhana.

Paragraf terakhir adalah pendapat pribadi, tetapi saya harap ini membantu. Saya setuju dengan yang lain meskipun yang mengatakan Anda harus melakukan benchmark. Tidak ada pendekatan yang merupakan peluru perak.


Ya, kami juga harus memperhitungkan tidak hanya untuk pertanyaan itu sendiri tetapi juga untuk pemrosesan data di dalam aplikasi. Jika mengambil data dengan gabungan luar, ada beberapa redundansi (kadang-kadang bisa menjadi sangat besar) yang harus disortir oleh aplikasi (biasanya di beberapa perpustakaan ORM), sehingga dalam ringkasan SELECT tunggal dengan permintaan JOIN mungkin mengkonsumsi lebih banyak CPU dan waktu daripada dua
SELECT

4

Apakah Anda harus menggunakan gabung adalah yang pertama dan terpenting tentang apakah gabung masuk akal . Hanya pada titik itu kinerja bahkan sesuatu untuk dipertimbangkan, karena hampir semua kasus lain akan menghasilkan kinerja yang jauh lebih buruk .

Perbedaan kinerja sebagian besar akan dikaitkan dengan seberapa terkait info yang Anda tanyakan. Bergabung bekerja, dan mereka cepat ketika data terkait dan Anda mengindeks barang dengan benar, tetapi mereka sering menghasilkan redundansi dan terkadang lebih banyak hasil daripada yang dibutuhkan. Dan jika set data Anda tidak terkait langsung, menempelkannya dalam satu permintaan tunggal akan menghasilkan apa yang disebut produk Cartesian (pada dasarnya, semua kemungkinan kombinasi baris), yang hampir tidak pernah seperti yang Anda inginkan.

Ini sering disebabkan oleh hubungan banyak ke satu. Misalnya, jawaban HoldOffHunger menyebutkan satu permintaan untuk posting, tag, dan komentar. Komentar terkait dengan posting, seperti halnya tag ... tetapi tag tidak terkait dengan komentar.

+------------+     +---------+     +---------+
|  comment   |     |   post  |     |  tag    |
|------------|*   1|---------|1   *|---------|
| post_id    |-----| post_id |-----| post_id |
| comment_id |     | ...     |     | tag_id  |
| user_id    |     |         |     | ...     |
| ...        |     |         |     | ...     |
+------------+     +---------+     +---------+

Dalam hal ini, jelas lebih baik untuk ini menjadi setidaknya dua pertanyaan terpisah. Jika Anda mencoba bergabung dengan tag dan komentar, karena tidak ada hubungan langsung antara keduanya, Anda berakhir dengan setiap kemungkinan kombinasi tag dan komentar. many * many == manymany. Selain itu, karena pos dan tag tidak terkait, Anda dapat melakukan dua kueri secara paralel, yang mengarah ke potensi keuntungan.

Mari kita pertimbangkan skenario yang berbeda: Anda ingin komentar dilampirkan ke posting, dan info kontak komentator.

 +----------+     +------------+     +---------+
 |   user   |     |  comment   |     |   post  |
 |----------|1   *|------------|*   1|---------|
 | user_id  |-----| post_id    |-----| post_id |
 | username |     | user_id    |     | ...     |
 | ...      |     | ...        |     +---------+
 +----------+     +------------+

Di sinilah Anda harus mempertimbangkan bergabung. Selain sebagai permintaan yang jauh lebih alami, kebanyakan sistem basis data (termasuk MySQL) memiliki banyak orang pintar yang menaruh banyak kerja keras dalam mengoptimalkan permintaan seperti itu. Untuk kueri yang terpisah, karena setiap kueri bergantung pada hasil yang sebelumnya, kueri tidak dapat dilakukan secara paralel, dan total waktu menjadi tidak hanya waktu eksekusi aktual kueri, tetapi juga waktu yang dihabiskan untuk mengambil hasil, memilah melalui mereka untuk ID untuk kueri berikutnya, menghubungkan baris bersama, dll.


Jika Anda mengambil banyak kolom pengguna dalam skenario kedua (dan pengguna yang sama mengomentari lebih dari satu kali), ini masih menyisakan pertanyaan, apakah kolom tersebut terbaik diambil dalam kueri yang terpisah.
Adrian Baker

@AdrianBaker: Seperti yang saya katakan, banyak orang pintar yang menempatkan banyak kerja keras. Jika saya akan mengoptimalkan server SQL saya, ide pertama saya adalah menggunakan kompresi, yang akan menghilangkan sejumlah besar redundansi tanpa mengubah kode banyak sekali. Optimalisasi tingkat berikutnya akan mencakup pengorganisasian hasil ke dalam tabel dan mengirimkannya bersama dengan tuple id baris, yang kemudian dapat dengan mudah dikumpulkan oleh perpustakaan klien di sisinya sesuai kebutuhan.
cHao

Kedua pengoptimalan tersebut dapat bekerja sangat baik dengan bergabung untuk mengurangi atau bahkan menghilangkan redundansi, tetapi tidak banyak yang dapat membantu dengan kueri seri inheren yang harus Anda lakukan untuk mengambil catatan terkait.
cHao

3

Apakah akan lebih cepat dalam hal throughput? Mungkin. Tetapi juga berpotensi mengunci lebih banyak objek basis data sekaligus (tergantung pada basis data dan skema Anda) dan dengan demikian mengurangi konkurensi. Dalam pengalaman saya, orang sering disesatkan oleh argumen "round-trip basis data yang lebih sedikit" ketika pada kenyataannya pada sebagian besar sistem OLTP di mana basis data berada pada LAN yang sama, hambatan sebenarnya jarang pada jaringan.



1

Ada beberapa faktor yang berarti tidak ada jawaban biner. Pertanyaan tentang apa yang terbaik untuk kinerja tergantung pada lingkungan Anda. Omong-omong, jika pilihan tunggal Anda dengan pengidentifikasi bukan sub-detik, ada sesuatu yang salah dengan konfigurasi Anda.

Pertanyaan sebenarnya untuk ditanyakan adalah bagaimana Anda ingin mengakses data. Pilihan tunggal mendukung pengikatan lambat. Misalnya jika Anda hanya menginginkan informasi karyawan, Anda dapat memilih dari tabel Karyawan. Hubungan kunci asing dapat digunakan untuk mengambil sumber daya terkait di lain waktu dan sesuai kebutuhan. Para pemilih akan sudah memiliki kunci untuk ditunjukkan sehingga mereka harus sangat cepat, dan Anda hanya perlu mengambil apa yang Anda butuhkan. Latensi jaringan harus selalu diperhitungkan.

Bergabung akan mengambil semua data sekaligus. Jika Anda membuat laporan atau mengisi kisi, ini mungkin yang Anda inginkan. Gabungan yang dikompilasi dan dioptimalkan hanya akan lebih cepat daripada pilihan tunggal dalam skenario ini. Ingat, bergabung Ad-hoc mungkin tidak secepat - Anda harus mengkompilasi mereka (ke dalam proc yang disimpan). Jawaban kecepatan tergantung pada rencana eksekusi, yang merinci langkah apa yang diambil DBMS untuk mengambil data.


0

Ya, satu permintaan menggunakan GABUNG akan lebih cepat. Meskipun tanpa mengetahui hubungan tabel yang Anda tanyakan, ukuran dataset Anda, atau di mana kunci utama berada, hampir tidak mungkin untuk mengatakan seberapa jauh lebih cepat.

Mengapa tidak menguji kedua skenario, maka Anda akan tahu pasti ...

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.