Rumus untuk mengestimasi baris menjadi sedikit konyol ketika filter "lebih besar dari" atau "kurang dari", tetapi itu adalah angka yang bisa Anda dapatkan.
Angka-angka
Menggunakan langkah 193, berikut adalah angka yang relevan:
RANGE_ROWS = 6624
EQ_ROWS = 16
AVG_RANGE_ROWS = 16.1956
RANGE_HI_KEY dari langkah sebelumnya = 1999-10-13 10: 47: 38.550
RANGE_HI_KEY dari langkah saat ini = 1999-10-13 10: 51: 19.317
Nilai dari klausa WHERE = 1999-10-13 10: 48: 38.550
Formula
1) Temukan ms antara dua rentang tombol hi
SELECT DATEDIFF (ms, '1999-10-13 10:47:38.550', '1999-10-13 10:51:19.317')
Hasilnya adalah 220767 ms.
2) Sesuaikan jumlah baris
Kita perlu menemukan baris per milidetik, tetapi sebelum kita melakukannya, kita harus mengurangi AVG_RANGE_ROWS dari RANGE_ROWS:
6624 - 16.1956 = 6607.8044 baris
3) Hitung baris per ms dengan jumlah baris yang disesuaikan:
6607.8044 baris / 220767 ms = .0299311 baris per ms
4) Hitung ms antara nilai dari klausa WHERE dan langkah saat ini RANGE_HI_KEY
SELECT DATEDIFF (ms, '1999-10-13 10:48:38.550', '1999-10-13 10:51:19.317')
Ini memberi kita 160767 ms.
5) Hitung baris pada langkah ini berdasarkan pada baris per detik:
.0299311 baris / ms * 160767 ms = 4811,9332 baris
6) Ingat bagaimana kami mengurangi AVG_RANGE_ROWS sebelumnya? Saatnya untuk menambahkannya kembali. Sekarang kita selesai menghitung angka yang terkait dengan baris per detik, kita juga dapat menambahkan EQ_ROWS dengan aman:
4811.9332 + 16.1956 + 16 = 4844.1288
Digabungkan, itulah perkiraan 4844.13 kami.
Menguji formula
Saya tidak dapat menemukan artikel atau posting blog tentang mengapa AVG_RANGE_ROWS dikurangkan sebelum baris per ms dihitung. Saya adalah mampu untuk mengkonfirmasi mereka dicatat dalam perkiraan, tetapi hanya pada milidetik terakhir - secara harfiah.
Dengan menggunakan database WideWorldImporters , saya melakukan beberapa pengujian tambahan dan menemukan penurunan estimasi baris menjadi linier hingga akhir langkah, di mana 1x AVG_RANGE_ROWS tiba-tiba diperhitungkan.
Inilah kueri sampel saya:
SELECT PickingCompletedWhen
FROM Sales.Orders
WHERE PickingCompletedWhen >= '2016-05-24 11:00:01.000000'
Saya memperbarui statistik untuk PickingCompletedWhen, kemudian mendapat histogram:
DBCC SHOW_STATISTICS([sales.orders], '_WA_Sys_0000000E_44CA3770')
Untuk melihat bagaimana penurunan baris yang diperkirakan saat kami mendekati RANGE_HI_KEY, saya mengumpulkan sampel di seluruh langkah. Penurunannya linear, tetapi berperilaku seolah-olah sejumlah baris sama dengan nilai AVG_RANGE_ROWS hanya bukan bagian dari tren ... sampai Anda menekan RANGE_HI_KEY dan tiba-tiba mereka turun seperti utang yang tidak tertagih dihapuskan. Anda dapat melihatnya dalam data sampel, terutama dalam grafik.
Perhatikan penurunan yang stabil dalam baris hingga kami menekan RANGE_HI_KEY dan kemudian BOOM potongan AVG_RANGE_ROWS terakhir tiba-tiba dikurangi. Sangat mudah untuk melihat grafik.
Singkatnya, perlakuan aneh AVG_RANGE_ROWS membuat penghitungan estimasi baris lebih rumit, tetapi Anda selalu dapat mendamaikan apa yang sedang dilakukan CE.
Bagaimana dengan Backon Eksponensial?
Exponential Backoff adalah metode yang digunakan Cardinality Estimator baru (seperti SQL Server 2014) untuk mendapatkan perkiraan yang lebih baik saat menggunakan beberapa statistik kolom tunggal. Karena pertanyaan ini adalah tentang satu stat satu kolom, itu tidak melibatkan rumus EB.