Kapan lebih baik membuat STATISTIK daripada membuat Indeks?

38

Saya telah menemukan banyak informasi tentang apa STATISTICS itu: bagaimana mereka dikelola, bagaimana mereka dapat dibuat secara manual atau otomatis dari permintaan atau indeks, dan sebagainya. Tapi, saya tidak mampu menemukan setiap bimbingan atau "praktek terbaik" informasi mengenai kapanuntuk membuatnya: situasi apa yang lebih diuntungkan dari objek STATISTIK yang dibuat secara manual daripada dari Indeks. Saya telah melihat statistik yang difilter secara manual dibuat membantu kueri pada tabel yang dipartisi (karena statistik yang dibuat untuk indeks mencakup seluruh tabel dan tidak per partisi - brillaint!), Tetapi tentunya harus ada skenario lain yang akan mendapat manfaat dari objek statistik sementara tidak membutuhkan detail indeks, juga tidak sebanding dengan biaya mempertahankan indeks atau meningkatkan kemungkinan pemblokiran / dead-lock.

@JonathanFite, dalam komentar, menyebutkan perbedaan antara indeks dan statistik:

Indeks akan membantu SQL menemukan data lebih cepat dengan membuat pencarian yang diurutkan secara berbeda dari tabel itu sendiri. Statistik membantu SQL menentukan berapa banyak memori / upaya yang diperlukan untuk memenuhi permintaan.

Itu info hebat, terutama karena itu membantu saya mengklarifikasi pertanyaan saya:

Bagaimana mengetahui ini (atau info teknis lainnya pada apa s dan bagaimana s terkait dengan perilaku dan sifat STATISTICS) bantuan menentukan kapan untuk memilih CREATE STATISTICSlebih CREATE INDEX, terutama saat membuat Indeks akan membuat terkait STATISTICSobjek? Skenario apa yang lebih baik dilayani dengan hanya memiliki info STATISTIK dan tidak memiliki Indeks?

Akan sangat membantu, jika mungkin, memiliki contoh skenario yang berfungsi di mana STATISTICSobjek lebih cocok daripada sebuah INDEX.


Karena saya seorang pembelajar / pemikir visual, saya pikir mungkin membantu untuk melihat perbedaan antara STATISTICSdan INDEX, berdampingan, sebagai cara yang mungkin untuk membantu menentukan kapan STATISTICSpilihan yang lebih baik.

Thingy           PROs                             CONs
-------          ----------                       -------------------
INDEX            * Can help sorts.                * Takes up space.
                 * Contains data (can             * Needs to be maintained (extra I/O).
                   "cover" a query).              * More chances for blocking / dead-locks.

STATISTICS       * Takes up very little space.    * Cannot help sorts.
                 * Lighter maintenance / won't    * Cannot "cover" queries.
                   slow down DML operations.
                 * Does not increase chances
                   of blocking / dead-locks.

Berikut ini adalah beberapa sumber yang saya temukan ketika mencari ini, yang bahkan menanyakan pertanyaan yang sama, tetapi tidak dijawab:

Indeks SQL Server vs Statistik

Pertanyaan SQL Server Statistics Kami terlalu malu untuk bertanya

Statistik. Mungkinkah histogram multikolom?

** Untuk lebih jelasnya, saya tidak punya jawaban untuk ini dan saya benar-benar mencari untuk mendapatkan umpan balik dari semoga beberapa orang untuk memberikan apa yang tampaknya ada informasi aneh yang hilang di sini di dalam jalinan.

Solomon Rutzky
sumber
1
Indeks akan membantu SQL menemukan data lebih cepat dengan membuat pencarian yang diurutkan secara berbeda dari tabel itu sendiri. Statistik membantu SQL menentukan berapa banyak memori / upaya yang diperlukan untuk memenuhi permintaan.
Jonathan Fite
@JonathanFite Terima kasih atas komentar itu. Saya telah memasukkannya ke dalam pertanyaan saya :).
Solomon Rutzky
Mengikuti komentar @ JonathanFite, sepertinya Statistik adalah yang terbaik untuk meningkatkan kinerja pada sistem ad hoc / tabel / pola kueri sementara Indeks lebih baik untuk pola kueri yang dapat diprediksi. Maksud saya ini lebih sebagai pertanyaan daripada pernyataan.
Dave

Jawaban:

19

Pertanyaan Anda berputar di sekitar - Kapan sebaiknya membuat statistik vs buat indeks (yang membuat statistik).

Dari catatan internal server sql saya (SQLSkills class- IE1 dan IE2) dan buku internal SQL Server , di bawah ini adalah pemahaman saya yang terbatas :

Statistik SQL Server hanyalah objek sistem yang berisi informasi penting tentang nilai kunci indeks dan nilai kolom biasa.

SQL Server menggunakan model berbasis biaya untuk memilih rencana eksekusi "cukup baik" secepat mungkin. Perkiraan cardanility (memperkirakan jumlah baris yang akan diproses pada setiap langkah eksekusi kueri) adalah faktor paling penting dalam optimasi kueri yang inturn mempengaruhi strategi bergabung, persyaratan hibah memori, pemilihan utas pekerja serta pilihan indeks saat mengakses data .

SQL Server tidak akan menggunakan indeks nonclustered ketika memperkirakan bahwa tidak ada yang besar. dari operasi loopup KEY atau RID akan diperlukan, sehingga mempertahankan statistik pada indeks (dan pada kolom) yang akan membantu dalam estimasi tersebut.

Ada 2 hal penting tentang statistik:

  1. Histogram menyimpan info tentang distribusi data untuk kolom statistik (indeks) paling kiri HANYA. Itu juga menyimpan info tentang kepadatan multi kolom dari nilai-nilai kunci. Jadi pada dasarnya, histogram menyimpan distribusi data hanya untuk kolom statistik paling kiri.

  2. SQL Server akan mempertahankan paling banyak 200 langkah dalam histogram terlepas dari ukuran tabel. Interval yang dicakup oleh setiap langkah histogram bertambah saat tabel tumbuh yang mengarah ke statistik "kurang akurat" untuk tabel besar.

    Ingat bahwa selektivitas indeks adalah metrik yang berbanding terbalik dengan kepadatan, yaitu semakin tinggi nilai kolom, semakin tinggi selektivitasnya.

Ketika kueri tertentu tidak berjalan terlalu sering, Anda dapat memilih untuk membuat statistik tingkat kolom daripada indeks. Statistik tingkat kolom membantu Pengoptimal Kueri menemukan rencana eksekusi yang lebih baik, meskipun rencana eksekusi tersebut tidak optimal karena pemindaian indeks yang terlibat. Pada saat yang sama, statistik tidak menambahkan overhead selama operasi modifikasi data, dan mereka membantu menghindari pemeliharaan indeks. Pendekatan ini hanya berfungsi untuk kueri yang jarang dieksekusi.

Merujuk:

Catatan: Seseorang seperti Paul White atau Aaron Bertrand dapat berpadu untuk memberikan lebih banyak warna pada pertanyaan bagus Anda .

Kin Shah
sumber
"SQL Server tidak akan menggunakan indeks nonclustered ketika memperkirakan bahwa sejumlah besar operasi loopup KEY atau RID akan diperlukan" Jadi, dapatkah QO menggunakan objek statistik berdasarkan indeks secara independen dari indeks? Artinya, jika indeksnya tidak optimal, tetapi kolom utama ada di kueri, maka statistiknya masih relevan. Jadi, apakah akan digunakan? Atau apakah info ini menyiratkan bahwa mungkin ada kasus ketika indeks kemungkinan tidak akan digunakan, tetapi karena statistik masih memiliki nilai, maka tidak ada alasan nyata untuk membuat indeks, lakukan saja statistik?
Solomon Rutzky
8

Saya akan mengatakan Anda perlu indeks ketika Anda harus dapat membatasi jumlah data / sampai ke data yang benar dengan cepat berdasarkan bidang (s).

Anda memerlukan statistik saat Anda membutuhkan pengoptimal untuk memahami sifat data untuk dapat melakukan operasi dengan cara terbaik.

Apa yang telah saya ketahui, statistik yang difilter membantu ketika Anda memiliki kemiringan dalam data Anda yang sangat memengaruhi rencana, misalnya dalam stack overflow beberapa pengguna memiliki jumlah posting yang sangat besar, jadi hanya menggunakan rata-rata posting per pengguna bukanlah estimasi terbaik. Jadi Anda bisa membuat statistik yang difilter pada userId berdasarkan pada nama pengguna dan kemudian SQL Server harus tahu bahwa ketika nama pengguna ini ada dalam kueri, ini adalah id pengguna yang akan didapatnya, dan ia harus bisa mengetahui, bahwa bidang yang diindeks dalam tabel posting akan memiliki sejumlah besar baris dengan id itu karena histogram ada di sana. Dengan rata-rata, itu tidak mungkin dilakukan.

James Z
sumber
1
Hai, dan terima kasih telah menjawab. Jadi, kapan saya perlu / ingin pengoptimal untuk lebih memahami sifat data, namun tidak membatasi data atau ingin mendapatkannya lebih cepat, atau perlu untuk "menutupi" kueri? Sama untuk contoh indeks yang difilter Anda. Saya mendapatkan apa yang Anda katakan dalam hal memecahkan kasus tepi dari rata-rata, tetapi mengapa statistik yang difilter lebih baik daripada indeks yang difilter pada bidang yang sama? Inilah perbedaan yang saya coba dapatkan.
Solomon Rutzky
Seperti dalam contoh, Anda tidak dapat membuat indeks yang difilter pada nama pengguna ke tabel posting karena tidak ada di sana. Anda bisa membuatnya berdasarkan id pengguna, tapi itu tidak ada dalam klausa where.
James Z
Tetapi tidak akan UserIDberada dalam kondisi BERGABUNG, bahkan jika tidak dalam WHERE? Dan bukankah itu cukup bagus untuk mengambil Indeks yang difilter?
Solomon Rutzky
@srutzky Mungkin lebih mungkin di versi terbaru, tetapi secara umum saya tidak akan bergantung pada itu ... dalam kebanyakan kasus, predikat harus sama persis. Saya lupa jika mereka memperbaikinya tetapi pada satu titik indeks yang disaring WHERE BitColumn = 0tidak akan dipilih untuk permintaan sederhana WHERE BitColumn <> 1. (Dan untuk menjadi jelas, kolom bit tidak dapat dibatalkan.) Saya pikir ada kasus serupa seperti IntColumn > 10tidak cocok IntColumn >= 11.
Aaron Bertrand
Indeks yang difilter tidak dapat digunakan jika ada kemungkinan seseorang lain kali menggunakan paket tersebut, indeks yang difilter tidak cocok lagi. Saya tidak dapat memikirkan gabungan apa pun yang dapat menggunakan indeks yang difilter. Bahkan variabel tidak dapat digunakan karena nilai lain kali bisa menjadi sesuatu yang tidak cocok.
James Z
4

Dari 70-461 buku Pelatihan oleh Itzik Ben-Gan

Hanya ada beberapa kemungkinan alasan untuk membuat statistik secara manual. Salah satu contoh adalah ketika predikat kueri berisi beberapa kolom yang memiliki hubungan lintas-kolom; statistik pada banyak kolom dapat membantu meningkatkan rencana kueri. Statistik pada banyak kolom berisi kepadatan lintas-kolom yang tidak tersedia dalam statistik satu kolom. Namun, jika kolom sudah dalam indeks yang sama, objek statistik multikolom sudah ada, jadi Anda tidak harus membuat satu tambahan secara manual.

Kentaro
sumber
Terima kasih telah memposting ini. Ini menjawab sebagian dari pertanyaan saya tetapi masih menyisakan pertanyaan: Jika saya memerlukan statistik multi-kolom, mengapa saya hanya membuat STATISTIK daripada Indeks, yang akan menyertakan STATISTIK plus info tambahan yang dapat membantu kueri lebih lanjut ( ies)?
Solomon Rutzky
1
Saya pikir penjelasan Kin akan lebih jauh menjelaskan apa yang Anda cari. Mungkin tumpukan yang sering dimasukkan, tetapi jarang ditanyakan?
Kentaro