Ketika saya melakukannya, dbcc show_statistics ('Reports_Documents', PK_Reports_Documents)
saya mendapatkan hasil berikut untuk ID Laporan 18698:
Untuk kueri ini:
SELECT *
FROM Reports_Documents
WHERE ReportID = 18698 option (recompile)
Saya mendapatkan rencana permintaan yang membuat Indeks Clustered Seek on PK_Reports_Documents
seperti yang diharapkan.
Tapi yang membuat saya bingung adalah nilai yang salah untuk Perkiraan Jumlah Baris:
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_KEY
nilai lain yang ada dalam histogram yang disediakan oleh show_statistics
dan 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_ROWS
dari 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_Documents
adalah kombinasi PK yang terdiri dariReportID INT
danDocumentID 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_KEY
dalam 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.
_dta_
statistik, mereka sudah ada sejak saya pertama kali melihat DB. Saya tidak tahu menggunakan rekomendasi dapat memiliki efek buruk seperti itu ...