เมื่อพยายามทำความเข้าใจว่าคำสั่ง SQL ทำงานอย่างไรบางครั้งขอแนะนำให้ดูที่แผนอธิบาย กระบวนการใดที่ควรดำเนินการในการตีความ (เหมาะสม) ของแผนอธิบาย สิ่งที่ควรจะโดดเด่นคือ "โอ้มันทำงานได้ดีขนาดนี้เลยเหรอ" กับ "โอ้ไม่ไม่ถูกต้อง"
เมื่อพยายามทำความเข้าใจว่าคำสั่ง SQL ทำงานอย่างไรบางครั้งขอแนะนำให้ดูที่แผนอธิบาย กระบวนการใดที่ควรดำเนินการในการตีความ (เหมาะสม) ของแผนอธิบาย สิ่งที่ควรจะโดดเด่นคือ "โอ้มันทำงานได้ดีขนาดนี้เลยเหรอ" กับ "โอ้ไม่ไม่ถูกต้อง"
คำตอบ:
ฉันสั่นทุกครั้งที่เห็นความคิดเห็นว่าการสแกนตารางแบบเต็มไม่ดีและการเข้าถึงดัชนีนั้นดี การสแกนแบบเต็มตารางการสแกนช่วงดัชนีการสแกนดัชนีแบบเต็มอย่างรวดเร็วการวนซ้ำแบบซ้อนการรวมการรวมการรวมแฮช ฯลฯ เป็นเพียงกลไกการเข้าถึงที่นักวิเคราะห์ต้องเข้าใจและรวมกับความรู้เกี่ยวกับโครงสร้างฐานข้อมูลและวัตถุประสงค์ของแบบสอบถามใน เพื่อให้ได้ข้อสรุปที่มีความหมาย
การสแกนแบบเต็มเป็นวิธีที่มีประสิทธิภาพที่สุดในการอ่านบล็อกส่วนข้อมูลจำนวนมาก (ตารางหรือพาร์ติชันตาราง (ย่อย)) และในขณะที่มักจะสามารถบ่งชี้ปัญหาด้านประสิทธิภาพได้ แต่ในบริบทเท่านั้น ไม่ว่าจะเป็นกลไกที่มีประสิทธิภาพในการบรรลุเป้าหมายของข้อความค้นหาหรือไม่ การพูดในฐานะคลังข้อมูลและ BI ค่าสถานะคำเตือนอันดับหนึ่งของฉันสำหรับประสิทธิภาพคือวิธีการเข้าถึงตามดัชนีและการวนซ้ำที่ซ้อนกัน
ดังนั้นสำหรับกลไกในการอ่านแผนอธิบายเอกสาร Oracle จึงเป็นแนวทางที่ดี: http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009
อ่านคู่มือการปรับแต่งประสิทธิภาพด้วย
นอกจากนี้ยังมี Google สำหรับ "cardinality feedback" ซึ่งเป็นเทคนิคที่สามารถใช้แผนอธิบายเพื่อเปรียบเทียบการประมาณค่าคาร์ดินาลลิตี้ในขั้นตอนต่างๆในข้อความค้นหากับคาร์ดินัลลิตีจริงที่พบในระหว่างการดำเนินการ Wolfgang Breitling เป็นผู้เขียนวิธีการนี้ฉันเชื่อว่า
ดังนั้นบรรทัดล่าง: ทำความเข้าใจกลไกการเข้าถึง ทำความเข้าใจกับฐานข้อมูล เข้าใจเจตนาของแบบสอบถาม หลีกเลี่ยงกฎง่ายๆ
เรื่องนี้ใหญ่เกินไปที่จะตอบในคำถามเช่นนี้ คุณควรใช้เวลาสักครู่เพื่ออ่านคู่มือการปรับแต่งประสิทธิภาพของ Oracle
สองตัวอย่างด้านล่างแสดงการสแกนแบบเต็มและการสแกนอย่างรวดเร็วโดยใช้ดัชนี
ควรให้ความสำคัญกับต้นทุนและความสำคัญของหัวใจ ดูตัวอย่างการใช้ดัชนีช่วยลดต้นทุนในการเรียกใช้แบบสอบถาม
มันซับซ้อนกว่าเล็กน้อย (และฉันไม่มีที่จับ 100%) แต่โดยพื้นฐานแล้ว Cost เป็นหน้าที่ของ CPU และต้นทุน IO และ Cardinality คือจำนวนแถวที่ Oracle คาดว่าจะแยกวิเคราะห์ การลดทั้งสองอย่างนี้เป็นสิ่งที่ดี
อย่าลืมว่าค่าใช้จ่ายของแบบสอบถามสามารถขึ้นอยู่กับแบบสอบถามของคุณและโมเดลเครื่องมือเพิ่มประสิทธิภาพของ Oracle (เช่น COST, CHOOSE เป็นต้น) และความถี่ที่คุณเรียกใช้สถิติของคุณ
ตัวอย่างที่ 1:
SCAN http://docs.google.com/a/shanghainetwork.org/File?id=dd8xj6nh_7fj3cr8dx_b
ตัวอย่างที่ 2 โดยใช้ Indexes:
INDEX http://docs.google.com/a/fukuoka-now.com/File?id=dd8xj6nh_9fhsqvxcp_b
และตามที่แนะนำแล้วระวัง TABLE SCAN โดยทั่วไปคุณสามารถหลีกเลี่ยงสิ่งเหล่านี้ได้
การมองหาสิ่งต่างๆเช่นการสแกนตามลำดับอาจมีประโยชน์บ้าง แต่ความจริงแล้วอยู่ในตัวเลข ... ยกเว้นเมื่อตัวเลขเป็นเพียงค่าประมาณเท่านั้น! อะไรคือสิ่งที่มักจะไกลมีประโยชน์มากขึ้นกว่าที่กำลังมองหาที่แบบสอบถามแผนกำลังมองหาที่เกิดขึ้นจริงการดำเนินการ ใน Postgres นี่คือความแตกต่างระหว่าง EXPLAIN และ EXPLAIN ANALYZE EXPLAIN ANALYZE ดำเนินการค้นหาจริงและรับข้อมูลเวลาจริงสำหรับทุกโหนด ช่วยให้คุณเห็นสิ่งที่เกิดขึ้นจริงแทนที่จะเป็นสิ่งที่ผู้วางแผนคิดว่าจะเกิดขึ้น หลายครั้งคุณจะพบว่าการสแกนตามลำดับไม่ใช่ปัญหาเลย แต่กลับเป็นอย่างอื่นในการสืบค้น
กุญแจสำคัญอีกอย่างคือการระบุขั้นตอนที่มีราคาแพงที่แท้จริงคืออะไร เครื่องมือกราฟิกจำนวนมากจะใช้ลูกศรขนาดต่างๆเพื่อระบุว่าส่วนต่างๆของแผนมีค่าใช้จ่ายเท่าใด ในกรณีนี้ให้มองหาขั้นตอนที่มีลูกศรบาง ๆ เข้ามาและลูกศรหนาออก หากคุณไม่ได้ใช้ GUI คุณจะต้องจับตาดูตัวเลขและมองหาตำแหน่งที่มันใหญ่ขึ้นมาก ด้วยการฝึกฝนเพียงเล็กน้อยมันจะค่อนข้างง่ายในการเลือกประเด็นปัญหา
จริงๆสำหรับปัญหาเช่นนี้สิ่งที่ดีที่สุดที่จะทำคือASKTOM โดยเฉพาะอย่างยิ่งคำตอบของเขาสำหรับคำถามนั้นมีลิงก์ไปยังเอกสาร Oracle ออนไลน์ซึ่งมีการอธิบายกฎเหล่านี้จำนวนมาก
สิ่งหนึ่งที่ควรทราบก็คือการอธิบายแผนการเป็นสิ่งที่เดาได้ดีที่สุด
เป็นความคิดที่ดีที่จะเรียนรู้การใช้ sqlplus และทดลองใช้คำสั่ง AUTOTRACE ด้วยตัวเลขที่ยากโดยทั่วไปคุณสามารถตัดสินใจได้ดีขึ้น
แต่คุณควรถาม เขารู้เรื่องทั้งหมด :)
ผลลัพธ์ของคำอธิบายจะบอกคุณว่าแต่ละขั้นตอนใช้เวลานานแค่ไหน สิ่งแรกคือการค้นหาขั้นตอนที่ใช้เวลานานและเข้าใจว่าหมายถึงอะไร สิ่งต่างๆเช่นการสแกนตามลำดับจะบอกคุณว่าคุณต้องการดัชนีที่ดีกว่าซึ่งส่วนใหญ่เป็นเรื่องของการค้นคว้าในฐานข้อมูลและประสบการณ์เฉพาะของคุณ
หนึ่ง "โอ้ไม่ที่ไม่ถูกต้อง" มักจะเป็นในรูปแบบของตารางการสแกน การสแกนตารางไม่ได้ใช้ดัชนีพิเศษใด ๆ และสามารถนำไปสู่การล้างแคชที่มีประโยชน์ทั้งหมดในหน่วยความจำ ตัวอย่างเช่นใน postgreSQL คุณจะพบว่ามีลักษณะเช่นนี้
Seq Scan on my_table (cost=0.00..15558.92 rows=620092 width=78)
บางครั้งการสแกนตารางก็เหมาะกว่าเช่นใช้ดัชนีเพื่อสืบค้นแถว อย่างไรก็ตามนี่เป็นหนึ่งในรูปแบบธงแดงที่ดูเหมือนว่าคุณกำลังมองหา
โดยพื้นฐานแล้วคุณจะดูที่การดำเนินการแต่ละครั้งและดูว่าการดำเนินการนั้น "เหมาะสม" หรือไม่หากได้รับความรู้ว่าควรจะทำงานได้อย่างไร
ตัวอย่างเช่นหากคุณกำลังเข้าร่วมสองตาราง A และ B บนคอลัมน์ตามลำดับ C และ D (AC = BD) และแผนของคุณแสดงการสแกนดัชนีคลัสเตอร์ (คำของเซิร์ฟเวอร์ SQL - ไม่แน่ใจเกี่ยวกับคำพยากรณ์) บนตาราง A จากนั้นลูปที่ซ้อนกันจะเข้าร่วมกับชุดของดัชนีคลัสเตอร์ที่ค้นหาบนตาราง B คุณอาจคิดว่ามีปัญหา ในสถานการณ์นั้นคุณอาจคาดหวังให้เอ็นจิ้นทำการสแกนดัชนีคู่หนึ่ง (เหนือดัชนีในคอลัมน์ที่เข้าร่วม) ตามด้วยการรวมการผสาน การตรวจสอบเพิ่มเติมอาจเปิดเผยสถิติที่ไม่ดีทำให้เครื่องมือเพิ่มประสิทธิภาพเลือกรูปแบบการเข้าร่วมนั้นหรือดัชนีที่ไม่มีอยู่จริง
ดูเปอร์เซ็นต์ของเวลาที่ใช้ในแต่ละส่วนย่อยของแผนและพิจารณาว่าเครื่องยนต์กำลังทำอะไรอยู่ ตัวอย่างเช่นหากกำลังสแกนตารางให้ลองใส่ดัชนีลงในฟิลด์ที่กำลังสแกน
ฉันมองหาดัชนีหรือการสแกนตารางเป็นหลัก สิ่งนี้มักจะบอกฉันว่าฉันไม่มีดัชนีในคอลัมน์สำคัญที่อยู่ในคำสั่ง where หรือคำสั่งเข้าร่วม
จากhttp://www.sql-server-performance.com/tips/query_execution_plan_analysis_p1.aspx :
หากคุณเห็นสิ่งต่อไปนี้ในแผนการดำเนินการคุณควรพิจารณาสัญญาณเตือนและตรวจสอบปัญหาด้านประสิทธิภาพที่อาจเกิดขึ้น แต่ละคนมีความเหมาะสมน้อยกว่าในแง่ของประสิทธิภาพ
* 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, don't include wiews 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?เป็นไปไม่ได้เสมอไปที่จะหลีกเลี่ยงสิ่งเหล่านี้ แต่ยิ่งคุณสามารถหลีกเลี่ยงได้มากเท่าไหร่ประสิทธิภาพการสืบค้นก็จะเร็วขึ้นเท่านั้น
(คุณอาจต้องการอ่านรายละเอียดด้วย:
ตารางสแกนตารางขนาดใหญ่หลายตาราง
การใช้ดัชนีดัชนีเฉพาะ
รวมถึงฟิลด์ที่จำเป็นทั้งหมด
ในปัญหาด้านประสิทธิภาพประมาณ 90% ที่ฉันได้เห็นการชนะที่ง่ายที่สุดคือการแยกข้อความค้นหาที่มีตารางจำนวนมาก (4 ตารางขึ้นไป) ออกเป็น 2 แบบสอบถามขนาดเล็กและตารางชั่วคราว