ปรับแต่งประสิทธิภาพของแบบสอบถาม


12

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

คำตอบ:


8

สำหรับการประเมินผลอย่างรวดเร็วได้รับแผนปฏิบัติการออกจาก SSMS และในแผน Explorer ที่

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

มีเอกสารอ้างอิงมากมายให้ใช้ฟรีที่นั่นแผนการดำเนินการ SQL Serverของ Grant Fitchley เป็นการเริ่มต้นที่ดี ฉันพบว่าการโพสต์บล็อกและ ebook ของ Joe Changเกี่ยวกับแผนการดำเนินการนั้นมีประโยชน์มาก


5

ส่วนใหญ่สิ่งที่ฉันทำก็แค่เรียกใช้คิวรีและค้นหาวิธีที่มันดำเนินการกับข้อมูลในโลกแห่งความจริง หากมีปัญหาฉันจะดูแผนการดำเนินการ

สำหรับแผนการดำเนินการแบรด McGehee มีบทความที่น่าสนใจในเรื่องนี้

ในนั้นเขาพูดว่า:

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

* Index or table scans: May indicate a need for better or additional indexes.

* Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement.

* Filter: Remove any functions in the WHERE clause, dont include wiews[sic] in your Transact-SQL code, may need additional indexes.

* Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently? 

ไม่สามารถหลีกเลี่ยงสิ่งเหล่านี้ได้เสมอไป แต่ยิ่งคุณหลีกเลี่ยงสิ่งเหล่านี้ได้มากเท่าไหร่ประสิทธิภาพของแบบสอบถามก็จะยิ่งมากขึ้นเท่านั้น


0
SET STATISTICS IO ON

โดยทั่วไป "จำนวนการอ่านเชิงตรรกะ" ควรต่ำที่สุด แตะสองสามหน้าเพื่อให้แบบสอบถามเสร็จสมบูรณ์ยิ่งแผนการดีขึ้นเท่าที่ควร (เร็วขึ้น) จะเร็วขึ้นส่งผลกระทบต่อ CPU, RAM และดิสก์ IO น้อยลง

สิ่งนี้จะแนะนำคุณเมื่อมีการเปลี่ยนดัชนีหรือการกู้แฟคตอริ่งใหม่ของ SQL จะช่วยได้จริง การดูที่ "เวลา excecution มิลลิวินาที" จะแตกต่างกันแม้ว่าจะมี SQL และแผนคิวรีเดียวกัน - การอ่านแบบลอจิคัลจะยังคงสอดคล้องกับแผนคิวรีใด ๆ

นอกจากนี้ "การอ่านทางกายภาพ" ควรต่ำมาก (และต้องเป็นศูนย์และคงศูนย์ไว้สำหรับการเรียกใช้ครั้งต่อไป) ถ้าสิ่งนี้ไม่ทำสิ่งนี้ให้ดูที่การใช้หน่วยความจำเซิร์ฟเวอร์ SQL ของคุณ (อายุการใช้งานหน้า ฯลฯ )


แต่สำหรับเคียวรีที่รันเมื่อไม่มีในแคชเคียวรีการอ่านแบบฟิสิคัลจะมากกว่าศูนย์ใช่ไหม? ฉันหมายความว่าคุณจะไม่สามารถหลีกเลี่ยงได้เสมอเนื่องจากไม่ใช่แคชแบบสอบถามทั้งหมด (โดยเฉพาะคิวรีเฉพาะกิจ) ที่ถูกแคช ฉันถูกไหม?
Thomas Stringer

@ Surfer513 เพื่อดูแลแคชข้อมูลคุณสามารถออก CHECKPOINT ตามด้วย DBCC DROPCLEANBUFFERS เพื่อล้างบัฟเฟอร์พูล (data cache) โปรดทราบว่านี่จะล้างบัฟเฟอร์สำหรับทุกคนดังนั้นให้ใช้ตามนั้น (ในระบบทดสอบ)
StanleyJohns

@StanleyJohns ทำไมคุณต้องการล้าง data / query cache
Thomas Stringer

วิธีนี้ IO ทางกายภาพจะเหมือนกันในแต่ละครั้งโดยให้ความสอดคล้องที่จำเป็นสำหรับการทดสอบ ซึ่งจะช่วยในการปรับแต่งแบบสอบถาม
StanleyJohns

ฉันจะไม่สนใจสถานะทางกายภาพของ IO เพราะมันอยู่ภายใต้การควบคุมของโครงสร้างพื้นฐานและจะรวมการบัฟเฟอร์ของ SAN และ OS Logical IO's เป็นการวัดจำนวน WORK ที่คำสั่ง SQL ต้องทำ ถ้า SQL ทำ IO แบบลอจิคัลให้น้อยลงมันจะทำงานน้อยลง
Guy
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.