การแสดงแผนการดำเนินการโดยประมาณจะสร้าง CXPACKET, PAGELATCH_SH และ LATCH_EX [ACCESS_METHODS_DATASET_PARENT] รอ

ผมใช้ Microsoft SQL Server 2016 SP2-CU6 (13.0.5292.0) ใน 4 vCPU VM กับmax degree of parallelismชุด2และชุดcost threshold for parallelism50

ในตอนเช้าเมื่อพยายามแสดงแผนการดำเนินการโดยประมาณสำหรับคิวรีแบบเลือก TOP 100ฉันพบว่าต้องรอเป็นจำนวนมากและการดำเนินการเพื่อแสดงแผนโดยประมาณใช้เวลาไม่กี่นาทีบ่อยครั้งในช่วง 5 - 7 นาที อีกครั้งนี้ไม่ได้ปฏิบัติจริงของแบบสอบถามนี้เป็นเพียงกระบวนการเพื่อแสดงแผนการดำเนินการโดยประมาณ

sp_WhoIsActiveจะแสดงPAGEIOLATCH_SHรอหรือLATCH_EX [ACCESS_METHODS_DATASET_PARENT]รอและเมื่อฉันเรียกใช้สคริปต์WaitingTasks.sql ของ Paul Randalในระหว่างการดำเนินการก็จะแสดงการCXPACKETรอด้วยเธรดผู้ทำงานที่แสดงการPAGEIOLATCH_SHรอ:

* ฟิลด์คำอธิบายทรัพยากร = exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen

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

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

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

ดังนั้น SQL Server จะใช้สถิติในการสร้างแผนใช้งานได้ถึงขีด จำกัด การแก้ไขและดำเนินการอัปเดตสถิติอัตโนมัติเป็นส่วนหนึ่งของการดำเนินการ

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

LastUpdate="2019-05-06T09:12:49.92"
LastUpdate="2019-05-06T09:12:58.3"
LastUpdate="2019-05-06T09:13:20.33"
LastUpdate="2019-05-06T09:13:09.67"
LastUpdate="2019-05-06T09:12:59.05"
LastUpdate="2019-05-06T09:12:39.56"

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

เมื่อฉันเห็นเวลาประมาณแผนที่ยาวนานใน SSMS นี่เป็นหนึ่งในสิ่งต่อไปนี้ตามลำดับโอกาส:

1. เครื่องมือเพิ่มประสิทธิภาพคิวรีตัดสินใจว่าต้องการสร้างหรืออัปเดตสถิติ
2. ขนาดของแผนโดยประมาณมีขนาดใหญ่มาก (เช่น> 10 MB) และใช้เวลานานในการแสดง SSMS
3. การรวบรวมแบบสอบถามเองใช้เวลานานจริง ๆ เนื่องจากการใช้งาน CPU ในการค้นหาแผนดีพอ
4. เซิร์ฟเวอร์อยู่ภายใต้การข่มขู่ที่รุนแรง ตัวอย่างเช่นฉันอาจต้องรอให้เกตเวย์พร้อมใช้งาน
5. ข้อบกพร่องต่าง ๆ ที่นำไปสู่การรวบรวมเวลาทำงานนานมาก

สำหรับสถานการณ์ของคุณคำตอบนั้นแน่นอนว่า SQL Server กำลังอัปเดตหรือสร้างสถิติ มีเงื่อนงำไม่กี่: ขนาดของแผนแบบสอบถามมีขนาดเล็กแผนแบบสอบถามค่อนข้างง่ายด้วยต้นทุนที่ต่ำและรวบรวม CPU อย่างมีนัยสำคัญต่ำกว่าเวลารวบรวม:

ผู้ให้ข้อมูลใหม่Josh Darnellชี้ให้เห็นถึงเงื่อนงำที่ดีพร้อมกับเวลาที่ปรับปรุงล่าสุดสำหรับสถิติใน XML

SQL Server 2019 แนะนำชนิดการรอใหม่WAIT_ON_SYNC_STATISTICS_REFRESHเมื่อแบบสอบถามกำลังรอการปรับปรุงสถิติ การวินิจฉัยปัญหานี้ในรุ่นนั้นง่ายกว่ามาก ก่อนหน้านั้นคุณต้องพึ่งเทคนิคทางอ้อม

วิธีแก้ปัญหารวมถึงการปรับปรุงสถิติในช่วงระยะเวลาการบำรุงรักษาหรือเปิดใช้งาน Auto Update Stats Async สำหรับฐานข้อมูล โปรดเข้าใจว่าตัวเลือกนั้นเต็มก่อนที่จะทำการเปลี่ยนแปลง แผนแบบสอบถามจะถูกสร้างขึ้นก่อนที่จะมีการอัปเดตสถิติแทนหลังจากอัปเดตสถิติแล้ว สำหรับภาระงานบางอย่างที่สามารถชนะอย่างมาก สำหรับคนอื่น ๆ มันสามารถทำอันตรายได้มากกว่าดี