statistik terkini, tetapi perkiraan salah


12

Ketika saya melakukannya, dbcc show_statistics ('Reports_Documents', PK_Reports_Documents)saya mendapatkan hasil berikut untuk ID Laporan 18698:

masukkan deskripsi gambar di sini

Untuk kueri ini:

SELECT * 
FROM Reports_Documents 
WHERE ReportID = 18698 option (recompile)

Saya mendapatkan rencana permintaan yang membuat Indeks Clustered Seek on PK_Reports_Documentsseperti yang diharapkan.

Tapi yang membuat saya bingung adalah nilai yang salah untuk Perkiraan Jumlah Baris:

masukkan deskripsi gambar di sini

Menurut ini :

Ketika kueri sampel nilai klausa WHERE sama dengan nilai histogram RANGE_HI_KEY, SQL Server akan menggunakan kolom EQ_ROWS dalam histogram untuk menentukan jumlah baris yang sama dengan

Ini juga seperti yang saya harapkan, namun sepertinya tidak demikian dalam kehidupan nyata. Saya juga mencoba beberapa RANGE_HI_KEYnilai lain yang ada dalam histogram yang disediakan oleh show_statisticsdan mengalami hal yang sama. Masalah ini dalam kasus saya tampaknya menyebabkan beberapa permintaan menggunakan rencana eksekusi yang sangat tidak optimal yang menghasilkan waktu eksekusi beberapa menit, sedangkan saya bisa menjalankannya dalam 1 detik dengan petunjuk kueri.

Semua dalam semua: Dapatkah seseorang menjelaskan kepada saya mengapa EQ_ROWSdari histogram tidak digunakan untuk Perkiraan Jumlah Baris dan dari mana perkiraan yang salah berasal?

Sedikit lebih banyak (mungkin membantu) info:

  • Statistik pembuatan otomatis aktif dan semua statistik diperbarui.
  • Tabel yang dipertanyakan memiliki sekitar 80 juta baris.
  • PK_Reports_Documentsadalah kombinasi PK yang terdiri dari ReportID INTdanDocumentID CHAR(8)

Kueri tampaknya memuat total 5 objek statistik yang berbeda, yang semuanya berisi ReportID+ beberapa kolom lain dari tabel. Mereka semua baru saja diperbarui. RANGE_HI_KEYdalam tabel di bawah ini adalah nilai kolom batas atas tertinggi dalam histogram.

+-------------------------------------------------------------------------+----------+--------------+--------------+---------------------+--------------+------------+----------+---------------------+----------------+
|                                  name                                   | stats_id | auto_created | user_created | Leading column Type | RANGE_HI_KEY | RANGE_ROWS | EQ_ROWS  | DISTINCT_RANGE_ROWS | AVG_RANGE_ROWS |
+-------------------------------------------------------------------------+----------+--------------+--------------+---------------------+--------------+------------+----------+---------------------+----------------+
| PK_Reports_Documents                                                    |        1 |            0 |            0 | Stationary          |        18722 | 0          | 2228,526 |                   0 | 1              |
| _dta_index_Reports_Documents_42_1629248859__K1_K63_K14_K13_K22_K23_72_6 |       62 |            0 |            0 | Stationary          |        18698 | 0          | 2228,526 |                   0 | 1              |
| _dta_stat_1629248859_1_1_59                                             |       76 |            0 |            1 | Stationary          |        18686 | 50,56393   | 1        |                   0 | 13397,04       |
| _dta_stat_1629248859_1_22_14_18_12_6                                    |       95 |            0 |            1 | Stationary          |        18698 | 0          | 2228,526 |                   0 | 1              |
| _dta_stat_1629248859_1_7_14_4_23_62                                     |       96 |            0 |            1 | Stationary          |        18698 | 56,63327   | 21641,5  |                   0 | 14526,44       |
+-------------------------------------------------------------------------+----------+--------------+--------------+---------------------+--------------+------------+----------+---------------------+----------------+

sp_updatestats dijadwalkan berjalan setiap malam untuk memperbarui statistik.

Jawaban:


10

Ada solusi sederhana untuk ini:

Hapus semua _dta_...statistik dan berhenti membabi buta menerapkan rekomendasi DTA.

Informasi lebih lanjut

Masalah khusus adalah bahwa ada beberapa set statistik untuk kolom tersebut. dtaStatistik tambahan dibuat dengan mengambil sampel data (perilaku default untuk statistik yang tidak terkait dengan indeks).

Seperti yang sering terjadi dengan statistik sampel, histogram yang dihasilkan tidak mencakup seluruh data yang tidak teridentifikasi. Kueri dalam pertanyaan tersebut terjadi untuk memilih nilai yang berada di luar histogram, menghasilkan estimasi 1 baris.

Perilaku yang tepat dari pengoptimal kueri ketika beberapa set statistik ada untuk kolom yang sama tidak sepenuhnya didokumentasikan. Itu cenderung lebih suka statistik 'pemindaian penuh' daripada sampel, tetapi juga lebih suka statistik yang baru-baru ini diperbarui daripada yang lebih lama.


Ini memang berhasil. Namun saya tidak membuat _dta_statistik, mereka sudah ada sejak saya pertama kali melihat DB. Saya tidak tahu menggunakan rekomendasi dapat memiliki efek buruk seperti itu ...
user1151923
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.