Bergabung dengan asumsi penahanan di pengukur Cardinality baru menurunkan kinerja permintaan di SQL Server 2014 dan yang lebih baru

PENTING: Artikel ini diterjemahkan oleh perangkat lunak penerjemahan mesin Microsoft, dan mungkin telah diedit oleh Masyarakat Microsoft melalui teknologi CTF dan bukan oleh seorang penerjemah profesional. Microsoft menawarkan baik artikel yang diterjemahkan oleh manusia maupun artikel hasil editan terjemahan oleh mesin/komunitas, sehingga Anda dapat mengakses semua artikel di Sentra Pengetahuan yang kami miliki dalam berbagai bahasa. Namun artikel hasil editan mesin atau bahkan komunitas tidak selalu sempurna. Artikel ini dapat mengandung kesalahan dalam hal kosa kata, sintaksis atau tatabahasa, sangat mirip dengan penutur asing yang membuat kekeliruan ketika berbicara dalam bahasa Anda. Microsoft tidak bertanggung jawab atas ketidakakuratan, kesalahan atau kerugian apa pun akibat dari kekeliruan dalam penerjemahan isi atau penggunaannya oleh pelanggan kami. Microsoft juga akan senantiasa memperbarui perangkat lunak penerjemahan mesin dan alat untuk menyempurnakan Editan Hasil Penerjemahan Mesin.

Klik disini untuk melihat versi Inggris dari artikel ini: 3189675
Gejala
Pertimbangkan skenario berikut ini:

  • Anda menggunakan Microsoft SQL Server 2014 atau versi yang lebih baru.
  • Anda menjalankan permintaan yang berisi bergabung dan non-bergabung filter predikat.
  • Anda menyusun permintaan dengan menggunakan baru Pengukur cardinality (Baru CE).
Dalam skenario ini, Anda mengalami penurunan kinerja permintaan.

Masalah ini tidak terjadi apabila Anda menyusun permintaan dengan menggunakan CE warisan.
Pemecahan masalah
Pada SQL Server 2014 dan versi yang lebih baru, Anda dapat menggunakan bendera pelacakan 9476 untuk memaksa CE baru menggunakanPenahanan sederhana asumsi daripada default Penahanan Baseasumsi." (Lihat "Informasi lebih lanjut"bagian.)

Mengaktifkan bendera pelacakan dapat meningkatkan permintaan rencana pilihan tanpa harus sepenuhnya kembali ke model Legacy CE apabila kondisi berikut ini benar:

  • Anda mengalami pilihan rencana kurang permintaan yang menyebabkan keseluruhan kinerja rusak untuk permintaan yang berisi bergabung dan non-bergabung filter predikat.
  • Anda dapat memverifikasi ketidaktepatan signifikan dalam perkiraan "Gabung cardinality" (yaitu, yang sebenarnya versus perkiraan jumlah baris yang berbeda secara signifikan).
  • Ketidaktepatan ini tidak ada ketika Anda menyusun permintaan dengan menggunakan Legacy CE.

Anda dapat mengaktifkan bendera pelacakan ini secara global, tingkat sesi, atau pada tingkat permintaan.

Catatan Menggunakan bendera pelacakan salah dapat menurunkan kinerja beban kerja Anda. Untuk informasi selengkapnya, lihat bagian "Pendahuluan" dari artikel Pangkalan Pengetahuan Microsoft berikut ini:

2801413 Mengaktifkan mempengaruhi rencana SQL Server permintaan Pengoptimal perilaku yang dapat dikendalikan oleh bendera pelacakan yang berbeda pada tingkat permintaan spesifik

Informasi lebih lanjut
Pada SQL Server 2014, pengukur Cardinality baru diperkenalkan database kompatibilitas mundur tingkat 120 dan lebih besar. CE baru perubahan asumsi beberapa dari CE warisan dalam model yang digunakan oleh Pengoptimal permintaan ketika memperkirakan cardinality operator yang berbeda dan predikat.

Salah satu dari perubahan ini berkaitan dengan bergabung dengan asumsi penahanan.

Model Legacy CE menganggap bahwa pengguna selalu meminta data yang ada. Ini berarti bahwa, untuk predikat gabungan yang melibatkan operasi equijoin untuk dua Daftar Tabel, kolom bergabung ada sisi bergabung. Depan tambahan non-bergabung filter predikat terhadap Daftar Tabel Gabung, Legacy CE menganggap beberapa tingkat korelasi predikat Gabung dan non-bergabung filter predikat. Hal ini tersirat korelasi disebut penahanan sederhana.

Selain itu, CE baru menggunakan penahanan Base korelasi. Model baru CE menganggap bahwa pengguna mungkin meminta data yang tidak ada. Ini berarti bahwa predikat filter pada Daftar Tabel terpisah mungkin tidak dapat berhubungan dengan satu sama lain. Oleh karena itu, kami menggunakan pendekatan probabilistik.

Untuk banyak skenario praktis, menggunakan asumsi penahanan Base membuat perkiraan yang lebih baik. Hal ini, bergantian, membuat permintaan lebih efisien rencana pilihan. Namun, dalam beberapa situasi, menggunakan asumsi penahanan sederhana akan memberikan hasil yang lebih baik. Jika hal ini terjadi, Anda mungkin mengalami kurang efisien permintaan rencana pilihan saat Anda menggunakan CE baru daripada Legacy CE.

Peringatan: Artikel ini telah diterjemahkan secara otomatis

Properti

ID Artikel: 3189675 - Tinjauan Terakhir: 09/07/2016 22:09:00 - Revisi: 1.0

Microsoft SQL Server 2016 Enterprise, Microsoft SQL Server 2016 Developer, Microsoft SQL Server 2016 Web, Microsoft SQL Server 2016 Standard, Microsoft SQL Server 2016 Express, Microsoft SQL Server 2014 Enterprise, Microsoft SQL Server 2014 Developer, Microsoft SQL Server 2014 Web, Microsoft SQL Server 2014 Standard, Microsoft SQL Server 2014 Express

  • kbmt KB3189675 KbMtid
Tanggapan