Apa yang dilakukan OPSI CEPAT dalam pernyataan SELECT?

Saya telah melakukan beberapa penggalian tentang apa yang dilakukan OPTION (FAST XXX)petunjuk kueri di dalam SELECTpernyataan dan saya masih bingung karenanya. Menurut MSDN:

Menentukan bahwa kueri dioptimalkan untuk pengambilan cepat number_rows pertama. Ini adalah bilangan bulat tidak negatif. Setelah number_rows pertama dikembalikan, kueri melanjutkan eksekusi dan menghasilkan set hasil lengkapnya.

Bagi saya itu tidak masuk akal tetapi pada dasarnya permintaan bisa mendapatkan baris XXX pertama sangat cepat kemudian sisanya dengan kecepatan normal?

Permintaan Microsoft Dynamics yang membuat saya berpikir tentang ini adalah:

select pjproj.project,pjproj.project_desc,pjproj.customer,pjproj.cpnyid
from pjproj WITH (NOLOCK)
where project like  '%'
order by project OPTION(FAST 500)

Adakah yang bisa menjelaskan dengan tepat apa yang dilakukan oleh petunjuk kueri ini dan lebih menguntungkan daripada tidak menggunakannya?

A FAST Nakan memberi tahu SQL Server untuk membuat rencana eksekusi dengan cepat mengembalikan jumlah baris yang didefinisikan sebagai N.

Perhatikan bahwa perkiraan akan sesuai Nkarena Anda memberi tahu sql server untuk mengambil Nbaris secepat mungkin.

mis. menjalankan kueri di bawah ini dengan fast 500:

-- total rows : 19972
 SELECT [BusinessEntityID]
      ,[TotalPurchaseYTD]
      ,[DateFirstPurchase]
      ,[BirthDate]
      ,[MaritalStatus]
      ,[YearlyIncome]
      ,[Gender]
      ,[TotalChildren]
      ,[NumberChildrenAtHome]
      ,[Education]
      ,[Occupation]
      ,[HomeOwnerFlag]
      ,[NumberCarsOwned]
  FROM [AdventureWorks2012].[Sales].[vPersonDemographics]
  order by BusinessEntityID
  option (fast 500)

Est vs Baris aktual dengan option (fast 500)

Est vs Baris aktual tanpa option (fast 500)

Sebuah kasus penggunaan akan ketika aplikasi melakukan caching (beban sejumlah besar data di latar belakang) dan ingin menunjukkan pengguna sepotong data secepat mungkin.

Kasus penggunaan lain yang menarik adalah di tanah SSIS yang Rob Farley gambarkan menggunakan FAST Nsebagai katalis mempercepat pengambilan data.

Dengan menambahkan petunjuk ini, rasanya seperti tongkat sihir telah dilambaikan ke seluruh permintaan, untuk membuatnya berjalan beberapa kali lebih cepat.

Lihat jawaban Remus Rusanu juga .

Saat Anda menggunakan petunjuk kueri ini OPSI (CEPAT n) optimizer memilih rencana eksekusi yang dapat mengembalikan jumlah rekaman dengan cara tercepat yang mungkin. Biasanya, pengoptimal mencoba memutuskan jalur yang secara efisien dapat mengembalikan set lengkap. Jadi, jika Anda ingin satu set baris kembali dengan cepat, Anda mungkin dapat menggunakan ini untuk mengambilnya, tetapi dalam kebanyakan kasus, menggunakan petunjuk ini akan menyebabkan set hasil lengkap kembali lebih lambat dibandingkan membiarkan pengoptimal menggunakan rencana untuk melakukan begitu.

Hanya untuk menguraikan kasus penggunaan: Anda mungkin memiliki dua tabel yang cukup besar yang harus Anda gabungkan bersama, tetapi Anda tahu hanya ada satu set data yang lebih kecil yang perlu Anda kerjakan dari salah satunya. Dalam hal ini, menggunakan FAST di atas tabel yang lebih besar tanpa harus membuat indeks tambahan / overhead dapat membantu alih-alih selada SQL membuat tabel hash raksasa di latar belakang.

Saya menemukan pertanyaan yang sama beberapa tahun yang lalu ketika menyelidiki masalah kinerja di Dynamics AX. Mengikuti penjelasan Microsoft, saya dapat melihat rencana eksekusi yang berbeda dipicu oleh petunjuk dan ini sesuai dengan jawaban lain yang diberikan di sini.

Dengan petunjuk itu, SQL Server mencoba untuk menemukan rencana eksekusi yang memungkinkan semacam streaming hasil, karena mereka keluar dari loop bersarang misalnya, bukannya rencana eksekusi yang mengharuskan semua catatan dibaca (dan berpotensi disortir) sebelum menjadi output.

Satu-satunya masalah dalam kasus saya adalah bahwa server SQL selalu mengambil (banyak) menit untuk mengembalikan hasil ketika menggunakan petunjuk, sedangkan permintaan mengembalikan hasil (seluruh hasil ditetapkan) dalam hitungan detik tanpa petunjuk ... tidak cukup apa sudah diduga. Saya pribadi akan menggunakan petunjuk ini dengan sangat hati-hati, dan tidak secara sistematis pada semua bentuk seperti di lingkungan Dynamics kami (well, tidak lagi).

Jadi, untuk menjawab OP: seperti banyak petunjuk, itu tidak selalu membantu meningkatkan kueri seperti yang seharusnya dilakukan (jadi ... tes, tes, tes!)