ประเมินประสิทธิภาพการสืบค้นด้วยแผนการดําเนินการและ DMV

  • 10 นาที

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

อ่านแผนการดําเนินการ

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

สกรีนช็อตของแผนการดําเนินการจริงแบบกราฟิกใน SQL Server Management Studio ที่แสดงตัวดําเนินการลูกศรที่ระบุการไหลของข้อมูลและเปอร์เซ็นต์ต้นทุนสําหรับแต่ละขั้นตอน

แผนการดําเนินการมีสองประเภท:

  • แผนการดําเนินการโดยประมาณ: สร้างขึ้นโดยไม่ต้องเรียกใช้คิวรี แสดงตัวดําเนินการที่วางแผนไว้และจํานวนแถวโดยประมาณตามสถิติ ใช้แผนโดยประมาณเพื่อการวิเคราะห์อย่างรวดเร็วโดยไม่ส่งผลกระทบต่อฐานข้อมูล
  • แผนการดําเนินการจริง: บันทึกระหว่างการดําเนินการคิวรี ซึ่งรวมถึงแผนโดยประมาณบวกกับจํานวนแถวจริง เวลาดําเนินการจริง การให้สิทธิ์หน่วยความจํา และคําเตือน แผนจริงเผยให้เห็นความคลาดเคลื่อนระหว่างสิ่งที่เครื่องมือเพิ่มประสิทธิภาพคาดหวังกับสิ่งที่เกิดขึ้นจริง

เมื่อต้องการแสดงแผนโดยประมาณ ให้เรียกใช้ SET SHOWPLAN_XML ON ก่อนคิวรี หรือเลือก แสดงแผนการดําเนินการโดยประมาณ ใน SQL Server Management Studio (SSMS) หากต้องการบันทึกแผนจริง ให้เรียกใช้ SET STATISTICS XML ON หรือเลือก รวมแผนการดําเนินการจริง ใน SSMS ก่อนดําเนินการสืบค้น

แม้ว่าแผนโดยประมาณและแผนจริงจะดูคล้ายกัน แต่เมตริกรันไทม์ของแผนจริงก็มีความสําคัญต่อการวินิจฉัยปัญหาด้านประสิทธิภาพ ตัวอย่างเช่น ถ้าจํานวนแถวโดยประมาณสําหรับการสแกนตารางคือ 100 แต่จํานวนแถวจริงคือ 10,000 นั่นอาจบ่งชี้ถึงสถิติที่ล้าสมัยซึ่งนําไปสู่การเลือกแผนที่ไม่ถูกต้อง เครื่องมือเพิ่มประสิทธิภาพจะคอมไพล์แผนตามสถิติในครั้งแรกที่พบคิวรี หากสถิติเหล่านั้นไม่สะท้อนถึงการกระจายข้อมูลในปัจจุบันแผนอาจทํางานได้ไม่ดี

ระบุปัญหาทั่วไปในแผนการดําเนินการ

แผนการดําเนินการจะอ่านจากซ้ายไปขวา จากบนลงล่าง ตัวดําเนินการตัวแรกเข้าถึงตารางฐาน และตัวดําเนินการขั้นสุดท้ายจะสร้างผลลัพธ์แบบสอบถาม มองหาปัญหาที่พบบ่อยเหล่านี้:

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

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

ตัวดําเนินการการค้นหาหลัก จะปรากฏขึ้นเมื่อกลไกจัดการค้นหาแถวผ่านดัชนีที่ไม่ใช่คลัสเตอร์ แต่ต้องการคอลัมน์เพิ่มเติมจากดัชนีคลัสเตอร์ สําหรับทุกแถวที่ตรงกัน เอ็นจิ้นจะทําการเดินทางไปกลับพิเศษไปยังดัชนีคลัสเตอร์เพื่อดึงคอลัมน์เหล่านั้น ถ้าตัวกรองส่งคืนหลายแถว การค้นหาเพิ่มเติมเหล่านั้นจะเพิ่มขึ้นอย่างรวดเร็ว ตัวอย่างเช่น ถ้าแอปพลิเคชันอีคอมเมิร์ซกรองใบสั่งตาม CustomerID แต่ยังเลือก OrderDate, TotalAmountและ ShippingAddressและดัชนีที่ไม่ใช่คลัสเตอร์ on CustomerID ไม่รวมคอลัมน์เหล่านั้น แผนจะแสดงการค้นหาคีย์สําหรับแต่ละใบสั่งที่ตรงกัน คุณสามารถกําจัดการค้นหาคีย์ได้โดยการเพิ่มคอลัมน์ที่ขาดหายไปเป็นคอลัมน์ที่รวมอยู่ในดัชนี โปรดทราบว่าคอลัมน์ที่รวมไว้จะเพิ่มขนาดดัชนี ซึ่งอาจทําให้การเขียนช้าลง ดังนั้นควรชั่งน้ําหนักประโยชน์ด้านประสิทธิภาพการอ่านเทียบกับค่าใช้จ่ายในการเขียน

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

คําแนะนําดัชนีที่ขาดหายไป จะปรากฏเป็นข้อความไฮไลต์สีเขียวที่ด้านบนของแผนการดําเนินการแบบกราฟิกใน SSMS เมื่อเครื่องมือเพิ่มประสิทธิภาพตรวจพบว่าดัชนีสามารถลดต้นทุนของคิวรีได้อย่างมาก ดัชนีจะแสดงคําแนะนําโดยตรงในแผน คลิกขวาที่คําแนะนําแล้วเลือก "รายละเอียดดัชนีที่ขาดหายไป " เพื่อสร้าง CREATE INDEX ใบแจ้งยอดที่คุณสามารถตรวจสอบและเรียกใช้ได้ คําแนะนําเหล่านี้เป็นหนึ่งในชัยชนะที่ง่ายที่สุดที่คุณจะได้รับจากการอ่านแผนการดําเนินการ

คําเตือน จะปรากฏเป็นสามเหลี่ยมสีเหลืองที่มีเครื่องหมายอัศเจรีย์ (⚠) บนตัวดําเนินการที่ได้รับผลกระทบ คําเตือนแต่ละรายการชี้ไปที่โอกาสในการเพิ่มประสิทธิภาพ คําเตือนทั่วไป ได้แก่ :

  • สถิติที่ขาดหายไป: เครื่องมือเพิ่มประสิทธิภาพไม่พบสถิติสําหรับคอลัมน์ ดังนั้นจึงคาดเดาจํานวนแถวแทนที่จะใช้การกระจายข้อมูลจริง หากต้องการแก้ไขปัญหานี้ ให้สร้างสถิติเกี่ยวกับคอลัมน์ที่ใช้ในคําค้นหาหรืออัปเดตสถิติที่มีอยู่หากคอลัมน์เก่า
  • การให้หน่วยความจํามากเกินไป: การสืบค้นร้องขอหน่วยความจํามากกว่าที่จําเป็น ซึ่งทําให้สิ้นเปลืองทรัพยากรที่การสืบค้นอื่นๆ สามารถใช้ได้ ปัญหานี้มักเกิดขึ้นเมื่อเครื่องมือเพิ่มประสิทธิภาพประเมินจํานวนแถวสูงเกินไป การอัปเดตสถิติหรือการเขียนแบบสอบถามใหม่เพื่อกรองแถวก่อนหน้านี้สามารถช่วยลดการให้สิทธิ์หน่วยความจําได้
  • ไม่มีเพรดิเคตรวม: ตารางสองตารางถูกรวมเข้าด้วยกันโดยไม่มีเงื่อนไขที่เหมาะสม ซึ่งสร้างผลิตภัณฑ์คาร์ทีเซียนที่ส่งคืนชุดค่าผสมแถวที่เป็นไปได้ทั้งหมด ตรวจสอบคิวรีของคุณเพื่อหาส่วนคําสั่งที่ขาดหายไปหรือไม่ถูกต้องON
  • การแปลงโดยนัย: ประเภทข้อมูลไม่ตรงกันบังคับให้กลไกจัดการแปลงค่าในขณะรันไทม์ ซึ่งสามารถเปลี่ยนการค้นหาดัชนีเป็นการสแกนได้ ตัวอย่างเช่น ถ้า WHERE ส่วนคําสั่งเปรียบเทียบ nvarchar พารามิเตอร์กับ varchar คอลัมน์ กลไกจัดการจะแปลงทุกแถวในคอลัมน์เป็น nvarchar ก่อนเปรียบเทียบ หากต้องการแก้ไข Conversion โดยนัย ให้จับคู่ประเภทข้อมูลในพารามิเตอร์การค้นหากับคําจํากัดความของคอลัมน์
  • เรียงลําดับหรือการรั่วไหลของแฮช: การดําเนินการเรียงลําดับหรือแฮชหมดหน่วยความจําที่ได้รับและส่งผลลัพธ์ระดับกลางไปยัง tempdb การดําเนินการเหล่านี้เป็นไดรเวอร์ที่พบบ่อยเป็นอันดับสองของ CPU สูงหลังจากการสแกน หากคุณเห็นคําเตือนการรั่วไหล แสดงว่าเครื่องมือเพิ่มประสิทธิภาพอาจประเมินจํานวนแถวต่ําเกินไปและขอหน่วยความจําน้อยเกินไป การเรียกใช้ UPDATE STATISTICS เพื่อรีเฟรชสถิติของตารางหรือการเขียนแบบสอบถามใหม่เพื่อลดจํานวนแถวก่อนการเรียงลําดับมักจะสามารถกําจัดการรั่วไหลได้

แผนการดําเนินการเป็นเครื่องมือที่มีประสิทธิภาพในการทําความเข้าใจประสิทธิภาพของคิวรี พวกเขาแสดงให้คุณเห็นว่ากลไกจัดการดําเนินการสืบค้นอย่างไรและคอขวดอยู่ที่ไหน ด้วยการเรียนรู้ที่จะอ่านแผนการดําเนินการอย่างมีประสิทธิภาพ คุณจะสามารถระบุและแก้ไขปัญหาด้านประสิทธิภาพในคิวรีฐานข้อมูลของคุณได้อย่างรวดเร็ว

สืบค้น DMV สําหรับข้อมูลประสิทธิภาพรันไทม์

DMV เปิดเผยข้อมูลประสิทธิภาพแบบเรียลไทม์และสะสมจากกลไกฐานข้อมูล ฐานข้อมูล Azure SQL ต้องได้รับ VIEW DATABASE STATE อนุญาตในการคิวรี แม้ว่าแผนการดําเนินการจะแสดงให้คุณเห็นว่าการสืบค้นเดียวทํางานอย่างไร แต่ DMV จะแสดงให้คุณเห็นว่าเกิดอะไรขึ้นในการค้นหาทั้งหมด ซึ่งจะช่วยให้คุณค้นหาการค้นหาที่แพงที่สุดก่อน

ค้นหาคําค้นหาที่แพงที่สุด

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

sys.dm_exec_query_stats ส่งกลับสถิติประสิทธิภาพการรวมสําหรับแผนการสืบค้นที่แคชไว้ เข้าร่วมเพื่อดู sys.dm_exec_sql_text ข้อความคิวรีและ sys.dm_exec_query_plan ดึงแผนการดําเนินการ

แบบสอบถามต่อไปนี้จะค้นหาแบบสอบถาม 10 อันดับแรกตามเวลา CPU โดยเฉลี่ย:

SELECT TOP 10
    qs.total_worker_time / qs.execution_count AS avg_cpu_time,
    qs.execution_count,
    qs.total_logical_reads / qs.execution_count AS avg_logical_reads,
    SUBSTRING(st.text, (qs.statement_start_offset / 2) + 1,
        ((CASE qs.statement_end_offset
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE qs.statement_end_offset
        END - qs.statement_start_offset) / 2) + 1) AS query_text
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
ORDER BY avg_cpu_time DESC;

สคริปต์นี้ช่วยให้คุณระบุได้ว่าคิวรีใดที่สมควรได้รับความสนใจจากคุณ สูง avg_logical_reads เมื่อเทียบกับขนาดชุดผลลัพธ์มักจะชี้ให้เห็นถึงดัชนีที่ขาดหายไปหรือแผนที่ไม่มีประสิทธิภาพ อย่างไรก็ตาม โปรดใช้ความระมัดระวังในการตีความผลลัพธ์เหล่านี้ คิวรีที่มีเวลา CPU เฉลี่ยสูงซึ่งทํางานเพียงวันละครั้งอาจมีความสําคัญน้อยกว่าคิวรีระดับปานกลางที่ทํางานหลายพันครั้งต่อชั่วโมง พิจารณาทั้งต้นทุนเฉลี่ยและจํานวนการดําเนินการเสมอเมื่อคุณจัดลําดับความสําคัญ คุณยังสามารถเรียงลําดับตาม avg_logical_reads เพื่อค้นหาคิวรีที่หนักหน่วงใน I/O ซึ่งมักจะบ่งชี้ว่าดัชนีขาดหายไปหรือวิธีการเข้าถึงที่ไม่มีประสิทธิภาพ

ตรวจสอบคิวรีที่กําลังดําเนินการอยู่

ในขณะที่คิวรีก่อนหน้านี้แสดงคิวรีในอดีตที่มีราคาแพงที่สุดในแคช sys.dm_exec_requests แผน จะให้สแนปช็อตของทุกคําขอที่กําลังทํางานอยู่ ประกอบด้วยคอลัมน์สําหรับเวลา CPU, การอ่าน, การเขียน, ประเภทการรอ, เวลารอ และรหัสเซสชันการบล็อก ใช้มุมมองนี้เพื่อค้นหาคิวรีที่ใช้งานอยู่ซึ่งใช้ทรัพยากรมากเกินไปหรือค้างอยู่ระหว่างรอการล็อก มุมมองนี้เป็นหนึ่งใน DMV ที่สําคัญที่สุดสําหรับการตรวจสอบและแก้ไขปัญหาประสิทธิภาพแบบเรียลไทม์

SELECT
    r.session_id,
    r.status,
    r.command,
    r.wait_type,
    r.wait_time,
    r.blocking_session_id,
    r.cpu_time,
    r.logical_reads,
    t.text AS query_text
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
WHERE r.session_id > 50
ORDER BY r.cpu_time DESC;

คิวรีนี้จะกรองเซสชันของระบบ (รหัสเซสชัน 1-50) และใบสั่งตามเวลา CPU คุณยังสามารถสั่งซื้อเพื่อค้นหา logical_reads คิวรี I/O ที่หนักหน่วง wait_typeคอลัมน์ และ wait_time ช่วยให้คุณระบุว่าคิวรีกําลังรอการล็อก I/O หรือรีซอร์สอื่นๆ หรือไม่

ค้นหาดัชนีที่ขาดหายไป

ก่อนหน้านี้เราได้เห็นว่าแผนการดําเนินการสามารถแสดงคําแนะนําดัชนีที่ขาดหายไปสําหรับคิวรีเดียวได้อย่างไร DMV ดัชนีที่ขาดหายไปจะช่วยให้คุณเห็นมุมมองที่กว้างขึ้นว่าเครื่องมือเพิ่มประสิทธิภาพจะใช้ดัชนีใดในการค้นหาทั้งหมดหากมีอยู่ มุมมองเหล่านี้เป็นวิธีที่ยอดเยี่ยมในการค้นหาโอกาสในการเพิ่มประสิทธิภาพที่ส่งผลต่อคิวรีหลายรายการ sys.dm_db_missing_index_details แสดงตาราง คอลัมน์ความเท่าเทียมกันและความไม่เท่าเทียมกัน และคอลัมน์ที่รวมอยู่ sys.dm_db_missing_index_group_stats ให้การวัดการปรับปรุงที่ประเมินการลดต้นทุน

SELECT
    mid.statement AS table_name,
    mid.equality_columns,
    mid.inequality_columns,
    mid.included_columns,
    migs.avg_total_user_cost * migs.avg_user_impact *
        (migs.user_seeks + migs.user_scans) AS improvement_measure
FROM sys.dm_db_missing_index_groups AS mig
INNER JOIN sys.dm_db_missing_index_group_stats AS migs
    ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details AS mid
    ON mig.index_handle = mid.index_handle
ORDER BY improvement_measure DESC;

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

Note

คําแนะนําดัชนีที่ขาดหายไปเป็นคําแนะนํา ไม่ใช่คําสั่ง ทดสอบผลกระทบของดัชนีใหม่ต่อทั้งประสิทธิภาพของคิวรีและค่าใช้จ่ายในการเขียนก่อนที่จะเพิ่มลงในการผลิตเสมอ

ตรวจสอบเซสชันที่ใช้งานอยู่และงานรอ

sys.dm_exec_sessions ให้ข้อมูลเกี่ยวกับเซสชันที่รับรองความถูกต้องทั้งหมด รวมถึงเวลาลงชื่อเข้าใช้ ชื่อโฮสต์ ชื่อโปรแกรม และ CPU และการอ่านสะสม รวมเข้ากับ sys.dm_os_waiting_tasks เพื่อดูว่างานใดกําลังรออยู่และทรัพยากรใดที่กําลังรออยู่ มุมมองเหล่านี้มีความสําคัญเมื่อคุณวินิจฉัยการบล็อกและการแย่งชิงทรัพยากรในหน่วยต่อมา

รวมทุกอย่างเข้าด้วยกัน

แผนการดําเนินการและ DMV ให้ภาพที่สมบูรณ์ของพฤติกรรมการสืบค้น เริ่มต้นด้วย DMV เพื่อระบุคําถามที่แพงที่สุด จากนั้นเจาะลึกแผนการดําเนินการเพื่อทําความเข้าใจ ว่าเหตุใด จึงมีราคาแพง เป็นดัชนีที่ขาดหายไปทําให้เกิดการสแกนหรือไม่? สถิติที่ล้าสมัยทําให้เกิดข้อผิดพลาดในการประมาณแถว? การค้นหาคีย์ที่คุณสามารถกําจัดได้? วิธีการที่เป็นระบบนี้ ตั้งแต่มุมมองทั้งระบบไปจนถึงการวิเคราะห์คิวรีแต่ละรายการ เป็นวิธีที่มีประสิทธิภาพที่สุดในการค้นหาและแก้ไขคอขวดด้านประสิทธิภาพ

ประเด็นสําคัญ

แผนการดําเนินการเผยให้เห็นกลยุทธ์ของเครื่องมือเพิ่มประสิทธิภาพสําหรับคิวรี และแผนจริงรวมถึงเมตริกรันไทม์ที่แสดงความคลาดเคลื่อนระหว่างจํานวนแถวโดยประมาณและจํานวนแถวจริง เมื่อคุณอ่านแผน ให้มุ่งเน้นไปที่ชนิดของตัวดําเนินการ (ค้นหาเทียบกับการสแกน) การประมาณการจํานวนแถว คําเตือน และตัวดําเนินการการค้นหาหลัก DMV ให้ข้อมูลประสิทธิภาพทั่วทั้งระบบ: ใช้ sys.dm_exec_query_stats เพื่อค้นหาคิวรี sys.dm_exec_requests ที่มีราคาแพงที่สุด สําหรับคิวรีที่กําลังทํางานอยู่ และ DMV ดัชนีที่ขาดหายไปสําหรับโอกาสในการเพิ่มประสิทธิภาพ เริ่มต้นอย่างกว้างขวางด้วย DMV เพื่อระบุว่าปัญหาที่ใหญ่ที่สุดอยู่ที่ใด จากนั้นเจาะลึกแผนการดําเนินการแต่ละรายการเพื่อทําความเข้าใจว่าทําไม