ทำความเข้าใจเกี่ยวกับสถิติแผนการดำเนินการและ 'ปัญหาสำคัญน้อยไปมาก'

ฉันพยายามที่จะเข้าใจ (แนวคิด) ความสัมพันธ์ระหว่างสถิติแผนการดำเนินการการดำเนินการตามขั้นตอนที่เก็บไว้

ฉันถูกต้องหรือไม่ในการบอกว่าสถิติจะถูกใช้เมื่อสร้างแผนการดำเนินการสำหรับขั้นตอนการจัดเก็บเท่านั้นและไม่ได้ใช้ในบริบทการดำเนินการจริง กล่าวอีกนัยหนึ่งหากเป็นจริงเมื่อมีการสร้างแผน (และสมมติว่ามีการใช้ซ้ำอย่างถูกต้อง) สถิติ "ทันสมัย" มีความสำคัญเพียงใด

ฉันได้รับแรงบันดาลใจเป็นพิเศษจากบทความที่ฉันอ่าน ( สถิติการประมาณแถวและคอลัมน์วันขึ้น ) ซึ่งอธิบายสถานการณ์ที่คล้ายกับที่ฉันเผชิญทุกวันกับฐานข้อมูลลูกค้าของเราหลายแห่ง

เรามีคอลัมน์วันที่ / เวลาจากน้อยไปหามากในหนึ่งในตารางที่ใหญ่ที่สุดของเราที่เราทำการสืบค้นเป็นประจำโดยใช้ขั้นตอนการจัดเก็บเฉพาะ

คุณจะป้องกันแผนการดำเนินการไม่ให้เพิ่มขึ้นได้อย่างไรเมื่อคุณเพิ่มหนึ่งแสนแถวต่อวัน?

หากเรากำลังอัปเดตสถิติบ่อยครั้งเพื่อต่อสู้กับปัญหานี้มันจะสมเหตุสมผลหรือไม่ที่จะใช้คำแนะนำ OPTION (RECOMPILE) ในการสืบค้นของโพรซีเดอร์นี้

คำแนะนำหรือคำแนะนำใด ๆ ที่จะได้รับการชื่นชม

อัปเดต : ฉันใช้ SQL Server 2012 (SP1)

ฉันถูกต้องหรือไม่ในการบอกว่าสถิติจะถูกใช้เมื่อสร้างแผนการดำเนินการสำหรับขั้นตอนการจัดเก็บเท่านั้นและไม่ได้ใช้ในบริบทการดำเนินการจริง

ไม่เกิดอะไรขึ้นคือแผนการดำเนินการสำหรับกระบวนงานที่เก็บไว้จะถูกแคช สมมติว่ามีหน่วยความจำเพียงพอที่จะดำเนินการเก็บแผนนั้นจะไม่เปลี่ยนแปลงเว้นแต่จะมีสิ่งใดสิ่งหนึ่งต่อไปนี้เกิดขึ้น (จากExecution Plan Caching และ Reuseในเอกสาร SQL Server โดยเน้นที่การเพิ่ม):

• การเปลี่ยนแปลงที่เกิดขึ้นกับตารางหรือมุมมองที่อ้างอิงโดยแบบสอบถาม (ALTER TABLE และ ALTER VIEW)
• การเปลี่ยนแปลงที่ทำกับโพรซีเดอร์เดียวซึ่งจะดร็อปแผนทั้งหมดสำหรับโพรซีเดอร์นั้นจากแคช (ALTER PROCEDURE)
• เปลี่ยนดัชนีใด ๆ ที่ใช้โดยแผนการดำเนินการ
• อัพเดตเกี่ยวกับสถิติที่ใช้โดยแผนการดำเนินการซึ่งสร้างขึ้นอย่างชัดเจนจากคำสั่งเช่นสถิติการอัพเดทหรือสร้างขึ้นโดยอัตโนมัติ
• วางดัชนีที่ใช้โดยแผนการดำเนินการ
• การเรียกที่ชัดเจนถึง sp_recompile
• การเปลี่ยนแปลงจำนวนมากกับคีย์ (สร้างโดยคำสั่ง INSERT หรือ DELETE จากผู้ใช้รายอื่นที่ปรับเปลี่ยนตารางที่อ้างอิงโดยการสืบค้น)
• สำหรับตารางที่มีทริกเกอร์หากจำนวนแถวในตารางที่แทรกหรือถูกลบเพิ่มขึ้นอย่างมีนัยสำคัญ
• การดำเนินการตามขั้นตอนที่เก็บไว้โดยใช้ตัวเลือก WITH RECOMPILE

ดังนั้นหากมีการอัปเดตสถิติแผนแคชจะพิจารณาสถิติใหม่โดยอัตโนมัติและคำนวณใหม่

คุณจะป้องกันแผนการดำเนินการไม่ให้เพิ่มขึ้นได้อย่างไรเมื่อคุณเพิ่มหนึ่งแสนแถวต่อวัน?

วิธีหนึ่งคือหากมีการอัปเดตจำนวนมากในตารางดังกล่าวข้างต้น แถวที่เปลี่ยนไปสองสามแสนแถวอาจเป็นไปตามเงื่อนไขนี้ แต่ถ้าคุณต้องการให้แน่ใจหรือมีการควบคุมที่ละเอียดยิ่งขึ้น: โดยการอัพเดทสถิติของคุณ คุณสามารถอนุญาตให้ SQL Server สร้างและจัดการสถิติโดยอัตโนมัติหรือทำได้ด้วยตนเอง คุณสามารถค้นหาข้อมูลเพิ่มเติมเกี่ยวกับวิธีการอย่างใดอย่างหนึ่งที่SQL Server Auto Update และ Auto สถิติที่สร้างตัวเลือก เมื่อ / ถ้าคุณทำการสร้างดัชนีรายสัปดาห์สิ่งนี้จะทริกเกอร์แผนการที่จะอัพเดตเช่นกัน ทำการทดสอบเพื่อดูว่าอะไรมีประโยชน์กับคุณมากที่สุดเนื่องจากการอัพเดตสถิติบ่อยเกินไปอาจไม่ให้ผลลัพธ์ที่แท้จริง

หากเรากำลังอัปเดตสถิติบ่อยครั้งเพื่อต่อสู้กับปัญหานี้มันจะสมเหตุสมผลหรือไม่ที่จะใช้คำแนะนำ OPTION (RECOMPILE) ในการสืบค้นของโพรซีเดอร์นี้

คุณไม่จำเป็นต้องใช้RECOMPILEเนื่องจากตามข้อความที่ตัดตอนมาด้านบนคุณจะเห็นว่าแผนการดำเนินการได้รับการอัปเดตอย่างเหมาะสมทุกครั้งที่มีสถิติใหม่ คุณอาจจะพอใจกับการอัพเดทสถิติเมื่อสิ้นสุดวัน (ถ้าคุณกังวลจริงๆ) แต่ฉันไม่คิดว่ามันเป็นความต้องการที่ชัดเจนตามสิ่งที่คุณพูดจนถึงตอนนี้ อีกครั้งแม้ว่าฉันจะทดสอบเพื่อดูว่าสิ่งนี้มีผลกระทบต่อประสิทธิภาพของขั้นตอนการจัดเก็บของคุณและวางแผนตามนั้นอย่างไร

ฉันถูกต้องในการบอกว่าสถิติจะใช้เฉพาะเมื่อสร้างแผนการดำเนินการ

ไม่สถิติที่ล้าสมัยอาจทำให้การรวบรวมซ้ำของคำสั่งที่ได้รับผลกระทบดีที่สุด

เรามีคอลัมน์วันที่ / เวลาจากน้อยไปหามากในหนึ่งในตารางที่ใหญ่ที่สุดของเราที่เราทำการสืบค้นเป็นประจำ

ย่อยที่ดีที่สุดแผนดำเนินการที่เกิดจากค่ากริยาเป็นนอก (เฉพาะด้านบน) ช่วงของค่าที่เก็บไว้ในสถิติ histogram ที่สอดคล้องกันเป็นที่รู้จักกันเป็นปัญหาที่สำคัญจากน้อยไปมาก การสร้างสถิติใหม่เป็นวิธีแก้ปัญหาที่เป็นไปได้ แต่อาจต้องใช้ทรัพยากรมาก ทางเลือก ได้แก่ :

• ธง Trace 2389 และ 2390 สิ่งนี้ต้องการให้ดัชนีมีคอลัมน์ที่มีปัญหาเป็นคีย์นำ มันไม่ทำงานกับตารางที่แบ่งพาร์ติชันและจะมีผลบังคับใช้ใน SQL Server 2014 เท่านั้นหากมีการใช้ตัวประมาณค่า cardinality ดั้งเดิม อาจจำเป็นต้องมีการตั้งค่าสถานะการสืบค้นกลับ 4139ถ้าวัตถุสถิติเป็นแบรนด์นิ่ง

• อัปเกรดเป็น SQL Server 2014 ตัวประมาณค่า cardinality ใหม่มีตรรกะในการประมาณค่าเกินกว่าฮิสโตแกรมโดยใช้ข้อมูลความหนาแน่นเฉลี่ย สิ่งนี้มีความแม่นยำน้อยกว่าค่าสถานะการติดตาม 2389/2390 ในบางสถานการณ์ที่สำคัญ

• เปิดใช้งานบ่อยมากขึ้นการปรับปรุงสถิติอัตโนมัติสำหรับตารางขนาดใหญ่ที่มีร่องรอยธง 2371 ด้วยแฟล็กการติดตามนี้แทนการอัพเดตหลังการเปลี่ยนแปลง 20% + 500 จำเป็นต้องทำการแก้ไขเท่านั้น SQRT(1000 * Table rows)นี่ไม่ใช่วิธีการแก้ปัญหาตามที่กล่าวไว้ก่อนหน้านี้เนื่องจากการอัปเดตอาจยังไม่ได้รับการเรียกใช้บ่อยพอ

หากแหล่งที่มาของปัญหาของคุณไม่ได้มีการรวบรวมแผนบ่อยมากขึ้นอยู่กับค่าที่เกินกว่าฮิสโตแกรม แต่เพิ่มเติมเกี่ยวกับผลกระทบของการแคชเป็นครั้งคราวเช่นแผนไม่ดีอันเป็นผลมาจากพารามิเตอร์การดมกลิ่นคุณสามารถพิจารณา:

• ปิดการใช้งานการดมพารามิเตอร์โดยใช้การตั้งค่าสถานะการติดตาม 4136
• การใช้OPTIMIZE FOR (@parameter = value)เพื่อรวบรวมแผนสำหรับค่าตัวแทนที่รู้จัก
• การใช้OPTIMIZE FOR (@parameter UNKNOWN)เพื่อปรับให้เหมาะสมโดยใช้การแจกแจงเฉลี่ย
• ใช้OPTIMIZE FOR UNKNOWN(เช่นเดียวกับ 4136 แต่ต่อแบบสอบถาม)
• ใช้OPTION (RECOMPILE)เพื่อรวบรวมทุกครั้งดมค่าเฉพาะ หากค่ารันไทม์ส่วนใหญ่อยู่ภายในฮิสโตแกรมค่านี้อาจมีผลบังคับใช้

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับพารามิเตอร์การดมกลิ่นการฝังและตัวเลือกการคอมไพล์ใหม่ให้ดูบทความของฉันบน SQLperformance.com