Apakah tampilan lebih cepat daripada permintaan sederhana?

Adalah

select *  from myView

lebih cepat dari kueri itu sendiri untuk membuat tampilan (agar memiliki hasil yang sama):

select * from ([query to create same resultSet as myView])

?

Tidak sepenuhnya jelas bagi saya jika tampilan menggunakan semacam caching membuatnya lebih cepat dibandingkan dengan permintaan sederhana.

Ya , tampilan dapat memiliki indeks yang dikelompokkan ditugaskan dan, ketika mereka melakukannya, mereka akan menyimpan hasil sementara yang dapat mempercepat permintaan yang dihasilkan.

Pembaruan: Setidaknya tiga orang telah memilih saya untuk hal ini. Dengan segala hormat, saya pikir mereka salah; Dokumentasi Microsoft sendiri membuatnya sangat jelas bahwa Views dapat meningkatkan kinerja.

Pertama, pandangan sederhana diperluas sehingga tidak berkontribusi langsung pada peningkatan kinerja - itu memang benar. Namun, tampilan yang diindeks dapat secara dramatis meningkatkan kinerja.

Biarkan saya langsung pergi ke dokumentasi:

Setelah indeks berkerumun unik dibuat pada tampilan, set hasil tampilan segera terwujud dan bertahan dalam penyimpanan fisik dalam database, menghemat overhead melakukan operasi mahal ini pada waktu pelaksanaan.

Kedua, pandangan yang diindeks ini dapat bekerja bahkan ketika mereka tidak direferensikan secara langsung oleh permintaan lain karena pengoptimal akan menggunakannya sebagai pengganti referensi tabel bila perlu.

Lagi-lagi, dokumentasi:

Tampilan yang diindeks dapat digunakan dalam eksekusi permintaan dalam dua cara. Kueri dapat mereferensikan tampilan yang diindeks secara langsung, atau, yang lebih penting, optimizer kueri dapat memilih tampilan jika menentukan bahwa tampilan dapat diganti untuk beberapa atau semua permintaan dalam rencana kueri berbiaya terendah. Dalam kasus kedua, tampilan yang diindeks digunakan sebagai pengganti tabel yang mendasari dan indeks biasa mereka. Tampilan tidak perlu direferensikan dalam kueri agar pengoptimal kueri menggunakannya selama eksekusi kueri. Ini memungkinkan aplikasi yang ada mendapat manfaat dari tampilan indeks yang baru dibuat tanpa mengubah aplikasi tersebut.

Dokumentasi ini, serta bagan yang menunjukkan peningkatan kinerja, dapat ditemukan di sini .

Pembaruan 2: jawabannya telah dikritik atas dasar bahwa itu adalah "indeks" yang memberikan keuntungan kinerja, bukan "Lihat." Namun, ini mudah dibantah.

Katakanlah kita adalah perusahaan perangkat lunak di negara kecil; Saya akan menggunakan Lithuania sebagai contoh. Kami menjual perangkat lunak di seluruh dunia dan menyimpan catatan kami di database SQL Server. Kami sangat sukses dan, dalam beberapa tahun, kami memiliki 1.000.000 catatan. Namun, kami sering perlu melaporkan penjualan untuk keperluan pajak dan kami menemukan bahwa kami hanya menjual 100 salinan perangkat lunak kami di negara asal kami. Dengan membuat tampilan indeks hanya catatan Lithuania, kita bisa menyimpan catatan yang kita butuhkan dalam cache yang diindeks seperti yang dijelaskan dalam dokumentasi MS. Ketika kami menjalankan laporan kami untuk penjualan Lithuania pada tahun 2008, permintaan kami akan mencari melalui indeks dengan kedalaman hanya 7 (Log2 (100) dengan beberapa daun yang tidak digunakan). Jika kita melakukan hal yang sama tanpa LIHAT dan hanya mengandalkan indeks ke dalam tabel, kita harus melintasi pohon indeks dengan kedalaman pencarian 21!

Jelas, View itu sendiri akan memberi kita keunggulan kinerja (3x) dibandingkan dengan penggunaan sederhana indeks saja. Saya sudah mencoba menggunakan contoh dunia nyata tetapi Anda akan perhatikan bahwa daftar sederhana penjualan Lithuania akan memberi kita keuntungan yang lebih besar.

Perhatikan bahwa saya hanya menggunakan b-tree lurus sebagai contoh. Sementara saya cukup yakin bahwa SQL Server menggunakan beberapa varian dari b-tree, saya tidak tahu detailnya. Meskipun demikian, intinya tetap berlaku.

Pembaruan 3: Pertanyaan telah muncul tentang apakah Tampilan Indexed hanya menggunakan indeks yang ditempatkan di tabel yang mendasarinya. Artinya, untuk parafrase: "tampilan yang diindeks hanya setara dengan indeks standar dan tidak menawarkan sesuatu yang baru atau unik untuk tampilan." Jika ini benar, tentu saja, maka analisis di atas akan salah! Biarkan saya memberikan kutipan dari dokumentasi Microsoft yang menunjukkan mengapa saya pikir kritik ini tidak valid atau benar:

Menggunakan indeks untuk meningkatkan kinerja kueri bukanlah konsep baru; namun, tampilan yang diindeks memberikan manfaat kinerja tambahan yang tidak dapat dicapai menggunakan indeks standar.

Bersama dengan kutipan di atas mengenai persistensi data dalam penyimpanan fisik dan informasi lain dalam dokumentasi tentang bagaimana indeks dibuat pada Views, saya pikir lebih aman untuk mengatakan bahwa Tampilan Terindeks bukan hanya Pilih SQL yang di-cache yang kebetulan menggunakan indeks didefinisikan pada tabel utama. Jadi, saya terus mendukung jawaban ini.

Secara umum, tidak. Tampilan terutama digunakan untuk kenyamanan dan keamanan, dan tidak akan (dengan sendirinya) menghasilkan keuntungan kecepatan apa pun.

Yang mengatakan, SQL Server 2000 dan di atas memang memiliki fitur yang disebut Indexed Views yang dapat sangat meningkatkan kinerja, dengan beberapa peringatan:

1. Tidak setiap tampilan dapat dibuat menjadi tampilan yang diindeks; mereka harus mengikuti serangkaian tertentu pedoman , yang (di antara pembatasan lainnya) berarti Anda tidak dapat mencakup unsur-unsur permintaan umum seperti COUNT, MIN, MAX, atau TOP.
2. Tampilan yang diindeks menggunakan ruang fisik dalam database, seperti halnya indeks pada sebuah tabel.

Artikel ini menjelaskan manfaat tambahan dan batasan tampilan indeks :

Kamu bisa…

• Definisi tampilan dapat merujuk satu atau lebih tabel dalam database yang sama.
• Setelah indeks berkerumun unik dibuat, indeks nonclustered tambahan dapat dibuat terhadap tampilan.
• Anda dapat memperbarui data di tabel yang mendasarinya - termasuk menyisipkan, memperbarui, menghapus, dan bahkan memotong.

Kamu tidak bisa ...

• Definisi tampilan tidak bisa mereferensikan tampilan lain, atau tabel di database lain.
• Itu tidak dapat berisi COUNT, MIN, MAX, TOP, gabungan luar, atau beberapa kata kunci atau elemen lainnya.
• Anda tidak dapat mengubah tabel dan kolom yang mendasarinya. Tampilan dibuat dengan opsi WITH SCHEMABINDING.
• Anda tidak selalu dapat memprediksi apa yang akan dilakukan pengoptimal kueri. Jika Anda menggunakan Edisi Perusahaan, secara otomatis akan mempertimbangkan indeks berkerumun unik sebagai opsi untuk kueri - tetapi jika menemukan indeks "lebih baik", itu akan digunakan. Anda dapat memaksa pengoptimal untuk menggunakan indeks melalui petunjuk DENGAN NOEXPAND - tetapi berhati-hatilah saat menggunakan petunjuk apa pun.

Setidaknya dalam SQL Server, paket kueri disimpan dalam cache paket untuk tampilan dan kueri SQL biasa, berdasarkan parameter kueri / tampilan. Untuk keduanya, mereka dikeluarkan dari cache ketika mereka sudah tidak digunakan untuk jangka waktu yang cukup lama dan ruang yang dibutuhkan untuk beberapa permintaan yang baru diajukan. Setelah itu, jika kueri yang sama dikeluarkan, itu dikompilasi ulang dan rencananya dimasukkan kembali ke dalam cache. Jadi tidak, tidak ada perbedaan, mengingat Anda menggunakan kembali permintaan SQL yang sama dan tampilan yang sama dengan frekuensi yang sama.

Jelas, secara umum, pandangan, pada dasarnya (bahwa seseorang mengira itu akan cukup sering digunakan untuk membuatnya menjadi tampilan) umumnya lebih mungkin untuk "digunakan kembali" daripada pernyataan SQL sewenang-wenang.

EDIT: Saya salah, dan Anda akan melihat jawaban Marks di atas.

Saya tidak dapat berbicara dari pengalaman dengan SQL Server , tetapi untuk sebagian besar database jawabannya adalah tidak. Satu-satunya manfaat potensial yang Anda peroleh, berdasarkan kinerja, dari menggunakan tampilan adalah bahwa hal itu berpotensi membuat beberapa jalur akses berdasarkan kueri. Tetapi alasan utama untuk menggunakan tampilan adalah untuk menyederhanakan kueri atau untuk membakukan cara mengakses beberapa data dalam tabel. Secara umum, Anda tidak akan mendapatkan manfaat kinerja. Tapi saya mungkin salah.

Saya akan memberikan contoh yang cukup rumit dan waktu untuk melihat sendiri.

Mungkin lebih cepat jika Anda membuat tampilan terwujud ( dengan skema mengikat ). Tampilan yang tidak terwujud mengeksekusi seperti kueri biasa.

Pemahaman saya adalah bahwa beberapa waktu yang lalu, tampilan akan lebih cepat karena SQL Server dapat menyimpan rencana eksekusi dan kemudian hanya menggunakannya daripada mencoba mencari satu dengan cepat. Saya pikir peningkatan kinerja saat ini mungkin tidak sebagus dulu, tapi saya harus menebak akan ada beberapa perbaikan marjinal untuk menggunakan tampilan.

Jelas tampilan lebih baik daripada permintaan bersarang untuk SQL Server. Tanpa tahu persis mengapa itu lebih baik (sampai saya membaca posting Mark Brittingham), saya telah menjalankan beberapa tes dan mengalami peningkatan kinerja yang hampir mengejutkan ketika menggunakan tampilan versus permintaan bersarang. Setelah menjalankan setiap versi kueri beberapa ratus kali berturut-turut, versi tampilan kueri selesai setengah waktu. Saya akan mengatakan itu cukup bukti bagi saya.

Saya mengharapkan dua pertanyaan untuk melakukan identik. Tampilan tidak lebih dari definisi kueri yang disimpan, tidak ada cache atau penyimpanan data untuk tampilan. Pengoptimal akan secara efektif mengubah permintaan pertama Anda menjadi permintaan kedua Anda saat Anda menjalankannya.

Semua tergantung pada situasinya. MS SQL Indexed views lebih cepat daripada view normal atau query tetapi viewed indexed tidak dapat digunakan dalam mirrored database invironment (MS SQL).

Tampilan dalam segala bentuk loop akan menyebabkan perlambatan serius karena tampilan diisi kembali setiap kali disebut dalam loop. Sama seperti kueri. Dalam situasi ini tabel sementara menggunakan # atau @ untuk menahan data Anda agar lebih cepat daripada tampilan atau kueri.

Jadi itu semua tergantung situasi.

Tidak ada perbedaan praktis dan jika Anda membaca BOL Anda akan menemukan bahwa SQL SELECT * tua biasa Anda * DARI X memang memanfaatkan caching paket, dll.

Seharusnya ada beberapa keuntungan sepele dalam menyimpan rencana eksekusi, tetapi akan diabaikan.

Tujuan tampilan adalah untuk menggunakan kueri berulang-ulang. Untuk itu, SQL Server, Oracle, dll. Biasanya akan menyediakan versi "cached" atau "compile" dari pandangan Anda, sehingga meningkatkan kinerjanya. Secara umum, ini harus berkinerja lebih baik daripada permintaan "sederhana", meskipun jika permintaan itu benar-benar sangat sederhana, manfaatnya dapat diabaikan.

Sekarang, jika Anda melakukan kueri yang kompleks, buat tampilan.

Dalam temuan saya, menggunakan tampilan sedikit lebih cepat daripada permintaan normal. Prosedur tersimpan saya memakan waktu sekitar 25 menit (bekerja dengan set rekaman yang lebih besar berbeda dan beberapa bergabung) dan setelah menggunakan tampilan (non-cluster), kinerjanya hanya sedikit lebih cepat tetapi tidak signifikan sama sekali. Saya harus menggunakan beberapa teknik / metode optimisasi kueri untuk membuatnya berubah secara dramatis.

Pilih dari Tampilan atau dari tabel tidak akan masuk akal.

Tentu saja jika Tampilan tidak memiliki gabungan yang tidak perlu, bidang, dll. Anda dapat memeriksa rencana pelaksanaan kueri, gabungan, dan indeks yang digunakan untuk meningkatkan kinerja Tampilan.

Anda bahkan dapat membuat indeks pada tampilan untuk persyaratan pencarian yang lebih cepat. http://technet.microsoft.com/en-us/library/cc917715.aspx

Tetapi jika Anda mencari seperti '% ...%' dari mesin sql tidak akan mendapat manfaat dari indeks pada kolom teks. Jika Anda dapat memaksa pengguna untuk melakukan pencarian seperti '...%' maka itu akan menjadi cepat

merujuk jawaban di forum asp: https://forums.asp.net/t/1697933.aspx?Which+adalah lebih cepat+ketika+menggunakanSELECT+ query+VIEW+ atauTabel+

Melawan semua harapan, pandangan jauh lebih lambat dalam beberapa keadaan.

Saya menemukan ini baru-baru ini ketika saya memiliki masalah dengan data yang ditarik dari Oracle yang perlu dipijat ke dalam format lain. Mungkin baris sumber 20k. Meja kecil. Untuk melakukan ini, kami mengimpor data oracle tidak berubah sebanyak yang saya bisa ke dalam tabel dan kemudian menggunakan tampilan untuk mengekstrak data. Kami memiliki pandangan sekunder berdasarkan pandangan tersebut. Mungkin 3-4 level tampilan.

Salah satu pertanyaan terakhir, yang diekstraksi mungkin 200 baris akan memakan waktu hingga 45 menit! Permintaan itu didasarkan pada kaskade pandangan. Mungkin 3-4 level.

Saya bisa mengambil setiap tampilan yang dipermasalahkan, memasukkan sql ke dalam satu query bersarang, dan menjalankannya dalam beberapa detik.

Kami bahkan menemukan bahwa kami bahkan dapat menulis setiap tampilan ke tabel temp dan kueri bahwa di tempat tampilan dan itu masih jauh lebih cepat daripada hanya menggunakan tampilan bersarang.

Apa yang lebih aneh adalah bahwa kinerjanya baik-baik saja sampai kita mencapai batas tertentu dari baris sumber yang ditarik ke dalam database, performanya baru saja jatuh dari tebing selama beberapa hari - hanya beberapa baris sumber yang diperlukan.

Jadi, menggunakan kueri yang menarik dari tampilan yang menarik dari tampilan jauh lebih lambat daripada permintaan bersarang - yang tidak masuk akal bagi saya.

Saya berlari melintasi utas ini dan hanya ingin membagikan pos ini dari Brent Ozar sebagai sesuatu yang perlu dipertimbangkan ketika menggunakan grup ketersediaan.

Laporan bug Brent Ozar