ในระหว่างการตรวจสอบแบบสอบถามที่ช้านั้นปรากฏว่าแผนการดำเนินการนั้นไม่ดีเท่าที่ควร เมื่อยืนยันแล้วว่ามีสถิติที่เกี่ยวข้องซึ่งจริง ๆ แล้วล้าสมัยฉันได้สร้างสถิติขึ้นมาใหม่และปัญหาประสิทธิภาพได้รับการแก้ไขอย่างมีประสิทธิภาพ
ฐานข้อมูลนี้เปิดใช้งานสถิติการอัพเดทอัตโนมัติ (โดยค่าเริ่มต้น) ฉันเข้าใจว่ามีเกณฑ์สำหรับการอัปเดตสถิติอัตโนมัติโดยพิจารณาจากการแก้ไขแถว 20% + 500 (อัปเดต / แทรก / ลบ) เกณฑ์นี้ดูเหมือนจะเกินกว่าระดับสูงของดัชนีหลายรายการเช่นนั้นปรากฏว่ามี (A) ปัญหาเกี่ยวกับการอัปเดตอัตโนมัติหรือ (B) มีกลยุทธ์การอัปเดตมากกว่าที่ฉันพบได้ในออนไลน์ เอกสาร
ฉันซาบซึ้งที่งานที่กำหนดเวลาไว้สามารถตั้งค่าเพื่ออัปเดตสถิติและนี่น่าจะเป็นแนวทางที่เราใช้หากไม่พบวิธีแก้ไขปัญหาอื่น ๆ อัปเดตอัตโนมัติสำหรับสถิติบางอย่าง - ทำความเข้าใจว่าทำไมอาจช่วยเราในการตัดสินใจว่าจะต้องอัปเดตสถิติใดโดยภารกิจที่กำหนดเวลาไว้
หมายเหตุเพิ่มเติมบางส่วน:
1) ปัญหาถูกบันทึกไว้ในฐานข้อมูลที่ข้อมูลถูกสร้างขึ้นโดยการทดสอบโหลดและเนื่องจากมีการเพิ่มข้อมูลจำนวนมากในช่วงเวลาสั้น ๆ ดังนั้นหากการอัปเดตอัตโนมัติเกิดขึ้นเป็นระยะ ๆ (เช่นวันละครั้งที่ ส่วนใหญ่) สิ่งนี้อาจอธิบายพฤติกรรมที่สังเกตได้บางอย่าง นอกจากนี้การทดสอบโหลดของเรามักจะเน้นที่ฐานข้อมูลอย่างหนักดังนั้นฉันสงสัยว่า SQL จะชะลอการอัปเดตสถิติขณะที่มีการโหลดจำนวนมากหรือไม่และไม่อัปเดตสถิติด้วยเหตุผลบางประการ
2) ในการพยายามสร้างปัญหานี้อีกครั้งด้วยสคริปต์ทดสอบที่มี INSERT ต่อเนื่องคำสั่ง SELECT และ DELETE จะไม่เกิดปัญหาขึ้น ฉันสงสัยว่าความแตกต่างที่นี่เป็นที่งบเหล่านี้แต่ละคนมีผลต่อแถวจำนวนมากต่อคำสั่ง SQL ในขณะที่สคริปต์ทดสอบโหลดของเราจะมีแนวโน้มที่จะแทรกแถวเป็นรายบุคคล
3) DB ในคำถามถูกตั้งค่าเป็นรูปแบบการกู้คืน 'แบบง่าย'
ลิงก์ที่เกี่ยวข้องบางส่วน:
ฉันยังได้ยกปัญหานี้ผ่านการเชื่อมต่อของ Microsoft:
อัพเดท 2011-06-30:
ในการตรวจสอบเพิ่มเติมฉันเชื่อว่าสถิติที่ล้าสมัยเกินระดับเกณฑ์ (เช่น 500 แถว + 20%) เป็นสถิติที่ไม่ได้ถูกใช้โดยการสอบถามปัญหาดังนั้นพวกเขาอาจจะได้รับการปรับปรุงเมื่อมีการเรียกใช้แบบสอบถาม ที่ต้องการพวกเขา สำหรับสถิติที่มีการใช้โดยแบบสอบถามเหล่านี้จะถูกปรับปรุงอย่างสม่ำเสมอ ปัญหาที่เหลืออยู่ก็คือสถิติเหล่านี้ทำให้เข้าใจผิดอย่างผิดพลาดต่อเครื่องมือเพิ่มประสิทธิภาพแผนแบบสอบถามหลังจากแทรกเพียงไม่กี่อันเท่านั้น (เช่นทำให้เกิด 9 ล้านดังกล่าวข้างต้นพยายามหาตำแหน่งที่ประมาณ 1)
ลางสังหรณ์ของฉันในเวลานี้คือปัญหาเกี่ยวข้องกับตัวเลือกหลักที่ไม่ดีของคีย์หลักคือตัวระบุเฉพาะที่สร้างขึ้นโดยใช้ NEWID () และสิ่งนี้จึงสร้างดัชนีที่มีการแยกส่วนอย่างรวดเร็ว - โดยเฉพาะอย่างยิ่งปัจจัยเติมเริ่มต้นใน SQL เซิร์ฟเวอร์เป็น 100% ลางสังหรณ์ของฉันก็คือว่าสิ่งนี้ส่งผลให้เกิดสถิติที่ทำให้เข้าใจผิดหลังจากแทรกแถวค่อนข้างน้อย - น้อยกว่าเกณฑ์สำหรับการคำนวณสถิติ ทั้งหมดนี้อาจเป็นปัญหาที่ไม่ใช่เพราะฉันได้สร้างข้อมูลจำนวนมากโดยไม่ต้องสร้างดัชนีใหม่ส่วนทางดังนั้นสถิติที่ไม่ดีอาจเป็นผลมาจากการกระจายตัวของดัชนีที่สูงมาก ฉันคิดว่าฉันต้องเพิ่มรอบการบำรุงรักษา SQL Server ลงในการทดสอบโหลดของฉันเพื่อให้ได้แนวคิดที่ดีขึ้นเกี่ยวกับประสิทธิภาพของระบบจริงในระยะเวลานาน
อัพเดท 2012-01-10:
อีกปัจจัยที่ต้องพิจารณา มีการเพิ่มการตั้งค่าสถานะการสืบค้นกลับสองอันลงใน SQL Server 2005 (และยังคงปรากฏอยู่ในปี 2551) เพื่อระบุข้อบกพร่องเฉพาะที่เกี่ยวข้องกับการเกิดขึ้นของสถิติล้าสมัยและ / หรือทำให้เข้าใจผิด ธงในคำถามคือ:
DBCC TRACEON(2389)
DBCC TRACEON(2390)MSDN: บันทึกทางเว็บของ Ian Jose: ปุ่มขึ้นและสถิติอัตโนมัติที่แก้ไขอย่างรวดเร็ว ในคอลัมน์จากน้อยไปมาก, Fabiano Amorim
แน่นอนคุณควรระวังให้มากเมื่อตัดสินใจเปิดใช้งานการตั้งค่าสถานะเหล่านี้เนื่องจากอาจมีผลกระทบที่เป็นอันตราย