คือ
select * from myViewเร็วกว่าแบบสอบถามเพื่อสร้างมุมมอง (เพื่อให้มีชุดผลลัพธ์เดียวกัน):
select * from ([query to create same resultSet as myView])?
มันไม่ชัดเจนเลยสำหรับฉันถ้ามุมมองใช้การแคชบางประเภททำให้เร็วขึ้นเมื่อเทียบกับแบบสอบถามแบบง่าย
คำตอบ:
ใช่มุมมองสามารถกำหนดดัชนีคลัสเตอร์ได้และเมื่อเสร็จแล้วจะมีการจัดเก็บผลลัพธ์ชั่วคราวที่สามารถเร่งการสืบค้นที่เกิดขึ้นได้
อัปเดต: มีคนอย่างน้อยสามคนโหวตฉันในเรื่องนี้ ด้วยความเคารพฉันคิดว่าพวกเขาผิด เอกสารของ Microsoft ระบุชัดเจนว่า Views สามารถปรับปรุงประสิทธิภาพได้
อย่างแรกคือมีการขยายมุมมองแบบง่าย ๆ และไม่สนับสนุนการปรับปรุงประสิทธิภาพโดยตรง - นั่นเป็นเรื่องจริง อย่างไรก็ตามมุมมองที่จัดทำดัชนีสามารถปรับปรุงประสิทธิภาพได้ อย่างมาก
ให้ฉันไปที่เอกสารโดยตรง:
หลังจากสร้างดัชนีคลัสเตอร์ที่ไม่ซ้ำกันในมุมมองชุดผลลัพธ์ของมุมมองจะเกิดขึ้นทันทีและคงอยู่ในที่เก็บข้อมูลทางกายภาพในฐานข้อมูลทำให้ประหยัดค่าใช้จ่ายในการดำเนินการที่มีค่าใช้จ่ายสูง ณ เวลาดำเนินการ
ประการที่สองมุมมองที่จัดทำดัชนีเหล่านี้สามารถทำงานได้แม้ว่าพวกเขาจะไม่ได้ถูกอ้างถึงโดยตรงโดยแบบสอบถามอื่น ๆเนื่องจากเครื่องมือเพิ่มประสิทธิภาพจะใช้พวกเขาแทนการอ้างอิงตารางตามความเหมาะสม
เอกสารอีกครั้ง:
มุมมองที่จัดทำดัชนีสามารถใช้ในการดำเนินการแบบสอบถามได้สองวิธี แบบสอบถามสามารถอ้างอิงมุมมองที่จัดทำดัชนีโดยตรงหรือที่สำคัญกว่านั้นเครื่องมือเพิ่มประสิทธิภาพแบบสอบถามสามารถเลือกมุมมองหากพิจารณาว่าสามารถแทนที่มุมมองสำหรับแบบสอบถามบางส่วนหรือทั้งหมดในแผนคิวรีที่มีต้นทุนต่ำที่สุด ในกรณีที่สองมุมมองที่จัดทำดัชนีจะใช้แทนตารางต้นแบบและดัชนีทั่วไป ไม่จำเป็นต้องอ้างถึงมุมมองในแบบสอบถามเพื่อให้เครื่องมือเพิ่มประสิทธิภาพแบบสอบถามใช้ในระหว่างการดำเนินการค้นหา สิ่งนี้อนุญาตให้แอปพลิเคชันที่มีอยู่ได้รับประโยชน์จากมุมมองที่จัดทำดัชนีใหม่โดยไม่ต้องเปลี่ยนแอปพลิเคชันเหล่านั้น
เอกสารฉบับนี้เช่นเดียวกับชาร์ตแสดงให้เห็นถึงการปรับปรุงประสิทธิภาพสามารถพบได้ที่นี่
อัปเดต 2:คำตอบได้รับการวิพากษ์วิจารณ์บนพื้นฐานที่ว่าเป็น "ดัชนี" ที่ให้ประโยชน์ด้านประสิทธิภาพไม่ใช่ "มุมมอง" อย่างไรก็ตามสิ่งนี้สามารถหักล้างได้ง่าย
ให้เราบอกว่าเราเป็น บริษัท ซอฟต์แวร์ในประเทศเล็ก ๆ ฉันจะใช้ลิทัวเนียเป็นตัวอย่าง เราขายซอฟต์แวร์ทั่วโลกและเก็บบันทึกของเราในฐานข้อมูล SQL Server เราประสบความสำเร็จเป็นอย่างมากในอีกไม่กี่ปีเรามีบันทึกมากกว่า 1,000,000 รายการ อย่างไรก็ตามเราต้องรายงานยอดขายเพื่อวัตถุประสงค์ด้านภาษีและเราพบว่าเราขายซอฟต์แวร์ของเราเพียง 100 ชุดในประเทศของเรา ด้วยการสร้างมุมมองที่จัดทำดัชนีของลิทัวเนียเพียงระเบียนเราจะได้รับการเก็บบันทึกที่เราต้องการในแคชที่จัดทำดัชนีตามที่อธิบายไว้ในเอกสาร MS เมื่อเราเรียกใช้รายงานยอดขายลิทัวเนียของเราในปี 2008 แบบสอบถามของเราจะค้นหาผ่านดัชนีที่มีความลึกเพียง 7 (Log2 (100) ด้วยใบที่ไม่ได้ใช้) ถ้าเราจะทำสิ่งเดียวกันโดยไม่ต้องใช้ VIEW และพึ่งอาศัยดัชนีในตารางเราจะต้องสำรวจแผนภูมิดัชนีที่มีความลึกการค้นหา 21!
เห็นได้ชัดว่ามุมมองนั้นจะช่วยให้เราได้เปรียบด้านประสิทธิภาพ (3x) ในการใช้งานดัชนีอย่างง่ายเพียงอย่างเดียว ฉันพยายามใช้ตัวอย่างจริง แต่คุณจะทราบว่ารายการขายง่าย ๆ ของลิทัวเนียจะทำให้เราได้เปรียบมากขึ้น
โปรดทราบว่าฉันแค่ใช้ b-tree สำหรับตัวอย่างของฉัน ในขณะที่ฉันค่อนข้างแน่ใจว่า SQL Server ใช้ตัวแปร b-tree บางตัวฉันไม่ทราบรายละเอียด อย่างไรก็ตามประเด็นก็คือ
อัปเดต 3:คำถามเกิดขึ้นเกี่ยวกับว่ามุมมองแบบดัชนีใช้ดัชนีที่วางอยู่บนตารางพื้นฐานหรือไม่ นั่นคือการถอดความ: "มุมมองที่จัดทำดัชนีเป็นเพียงเทียบเท่าดัชนีมาตรฐานและมันไม่มีอะไรใหม่หรือไม่ซ้ำกับมุมมอง" หากเป็นจริงแน่นอนการวิเคราะห์ข้างต้นจะไม่ถูกต้อง! ให้ฉันเสนอราคาจากเอกสาร Microsoft ที่แสดงให้เห็นว่าทำไมฉันคิดว่าการวิจารณ์นี้ไม่ถูกต้องหรือเป็นจริง:
การใช้ดัชนีเพื่อปรับปรุงประสิทธิภาพการสืบค้นไม่ใช่แนวคิดใหม่ อย่างไรก็ตามมุมมองที่จัดทำดัชนีจะให้ประโยชน์ด้านประสิทธิภาพเพิ่มเติมซึ่งไม่สามารถทำได้โดยใช้ดัชนีมาตรฐาน
เมื่อรวมกับการอ้างถึงข้างต้นเกี่ยวกับการคงอยู่ของข้อมูลในที่จัดเก็บข้อมูลจริงและข้อมูลอื่น ๆ ในเอกสารเกี่ยวกับวิธีการสร้างดัชนีใน Views ฉันคิดว่ามันปลอดภัยที่จะกล่าวว่ามุมมองที่จัดทำดัชนีไม่ได้เป็นเพียง ดัชนีที่กำหนดไว้ในตารางหลัก ดังนั้นฉันยังคงยืนหยัดอยู่กับคำตอบนี้
โดยทั่วไปแล้วไม่มี มุมมองส่วนใหญ่จะใช้เพื่อความสะดวกและปลอดภัยและจะไม่ก่อให้เกิดประโยชน์ต่อความเร็วใด ๆ
ที่กล่าวว่า SQL Server 2000 ขึ้นไปมีคุณสมบัติที่เรียกว่าการจัดทำดัชนีมุมมองที่สามารถปรับปรุงประสิทธิภาพได้อย่างมากโดยมีข้อแม้บางประการ:
COUNT, MIN, หรือMAXTOPบทความนี้อธิบายถึงประโยชน์และข้อ จำกัด เพิ่มเติมของมุมมองที่จัดทำดัชนี :
คุณสามารถ…
- นิยามมุมมองสามารถอ้างอิงหนึ่งตารางขึ้นไปในฐานข้อมูลเดียวกัน
- เมื่อดัชนีคลัสเตอร์ที่ไม่ซ้ำกันถูกสร้างขึ้นดัชนีที่ไม่ใช่คลัสเตอร์เพิ่มเติมสามารถสร้างขึ้นกับมุมมอง
- คุณสามารถอัปเดตข้อมูลในตารางพื้นฐาน - รวมถึงการแทรกการอัพเดทการลบและแม้แต่การตัดทอน
คุณไม่สามารถ ...
- นิยามมุมมองไม่สามารถอ้างอิงมุมมองอื่นหรือตารางในฐานข้อมูลอื่น
- ไม่สามารถมี COUNT, MIN, MAX, TOP, การรวมภายนอกหรือคำหลักหรือองค์ประกอบอื่น ๆ
- คุณไม่สามารถแก้ไขตารางและคอลัมน์ที่เกี่ยวข้องได้ มุมมองถูกสร้างขึ้นด้วยตัวเลือก WITH SCHEMABINDING
- คุณไม่สามารถคาดเดาได้เสมอว่าเครื่องมือเพิ่มประสิทธิภาพคิวรีจะทำอะไร หากคุณกำลังใช้ Enterprise Edition มันจะพิจารณาดัชนีคลัสเตอร์ที่ไม่ซ้ำกันโดยอัตโนมัติเป็นตัวเลือกสำหรับการสืบค้น - แต่หากพบว่าดัชนี "ดีกว่า" จะถูกใช้ คุณสามารถบังคับให้เครื่องมือเพิ่มประสิทธิภาพใช้ดัชนีผ่านคำแนะนำ WITH NOEXPAND ได้ แต่ต้องระมัดระวังเมื่อใช้คำใบ้ใด ๆ
ใน SQL Server เป็นอย่างน้อยแผนแบบสอบถามจะถูกเก็บไว้ในแคชแผนสำหรับทั้งมุมมองและแบบสอบถาม SQL ธรรมดาขึ้นอยู่กับพารามิเตอร์แบบสอบถาม / ดู สำหรับทั้งคู่พวกเขาจะถูกดร็อปจากแคชเมื่อไม่ได้ใช้งานเป็นระยะเวลานานพอและต้องการพื้นที่สำหรับคิวรีที่ส่งใหม่อื่น ๆ หลังจากนั้นหากมีการออกแบบสอบถามเดียวกันก็จะถูกคอมไพล์ใหม่และวางแผนลงในแคช ดังนั้นไม่ไม่มีความแตกต่างเนื่องจากคุณกำลังใช้คิวรี SQL ซ้ำและมุมมองเดียวกันที่มีความถี่เดียวกันซ้ำ
เห็นได้ชัดว่าโดยทั่วไปมุมมองโดยธรรมชาติแล้ว (มีคนคิดว่ามันถูกใช้บ่อยพอที่จะทำให้มันเป็นมุมมอง) โดยทั่วไปมีแนวโน้มที่จะ "นำมาใช้ใหม่" มากกว่าคำสั่ง SQL ที่กำหนดเอง
แก้ไข: ฉันผิดและคุณควรเห็นเครื่องหมายคำตอบด้านบน
ฉันไม่สามารถพูดจากประสบการณ์กับSQL Serverแต่สำหรับฐานข้อมูลส่วนใหญ่คำตอบจะไม่ ประโยชน์ที่เป็นไปได้เพียงอย่างเดียวที่คุณได้รับคือประสิทธิภาพการทำงานที่ชาญฉลาดจากการใช้มุมมองคือมันอาจสร้างเส้นทางการเข้าถึงบางอย่างตามแบบสอบถาม แต่เหตุผลหลักในการใช้มุมมองคือการทำให้แบบสอบถามง่ายขึ้นหรือสร้างมาตรฐานของวิธีการเข้าถึงข้อมูลบางอย่างในตาราง โดยทั่วไปคุณจะไม่ได้รับประโยชน์จากประสิทธิภาพการทำงาน ฉันอาจจะผิด
ฉันจะมาพร้อมกับตัวอย่างที่ซับซ้อนมากขึ้นในระดับปานกลางและใช้เวลาในการดูด้วยตัวเอง
มันอาจจะเร็วขึ้นถ้าคุณสร้างมุมมอง materialized ( กับสคีผูกพัน ) มุมมองที่ไม่เป็นตัวจริงเรียกใช้งานเช่นเดียวกับแบบสอบถามทั่วไป
ความเข้าใจของฉันคือเมื่อเวลาผ่านไปมุมมองจะเร็วขึ้นเพราะ SQL Server สามารถจัดเก็บแผนการดำเนินการและจากนั้นใช้เพียงแทนที่จะพยายามคิดออกทันที ฉันคิดว่าการแสดงที่เพิ่มขึ้นทุกวันนี้อาจไม่ได้ยอดเยี่ยมเท่าที่เคยเป็นมา แต่ฉันต้องเดาว่าจะมีการปรับปรุงเล็กน้อยเพื่อใช้มุมมอง
มุมมองดีกว่าแบบสอบถามซ้อนสำหรับ SQL Server โดยไม่ทราบว่าทำไมมันถึงดีกว่า (จนกว่าฉันจะอ่านโพสต์ของ Mark Brittingham) ฉันได้ทำการทดสอบและพบกับการปรับปรุงประสิทธิภาพที่น่าตกใจเกือบทั้งหมดเมื่อใช้มุมมองกับแบบสอบถามซ้อน หลังจากเรียกใช้แบบสอบถามแต่ละรุ่นหลายร้อยครั้งในหนึ่งแถวมุมมองแบบสอบถามจะเสร็จสมบูรณ์ในครึ่งเวลา ฉันจะบอกว่านั่นเป็นข้อพิสูจน์ที่เพียงพอสำหรับฉัน
ฉันคาดหวังว่าข้อความค้นหาทั้งสองจะทำงานเหมือนกัน มุมมองไม่มีอะไรมากไปกว่าคำจำกัดความของแบบสอบถามที่เก็บไว้ไม่มีการแคชหรือจัดเก็บข้อมูลสำหรับมุมมอง เครื่องมือเพิ่มประสิทธิภาพจะเปลี่ยนคิวรีแรกของคุณเป็นคิวรีที่สองของคุณอย่างมีประสิทธิภาพเมื่อคุณเรียกใช้
ทุกอย่างขึ้นอยู่กับสถานการณ์ MS SQL ที่จัดทำดัชนีมุมมองเร็วกว่ามุมมองปกติหรือแบบสอบถาม แต่ไม่สามารถใช้มุมมองที่จัดทำดัชนีไว้ใน invironment ฐานข้อมูลที่มิเรอร์ (MS SQL)
มุมมองในวงใด ๆ จะทำให้เกิดการชะลอตัวร้ายแรงเนื่องจากมุมมองจะ repopulated ทุกครั้งที่มีการเรียกในวง เหมือนกับแบบสอบถาม ในสถานการณ์นี้ตารางชั่วคราวที่ใช้ # หรือ @ เพื่อเก็บข้อมูลของคุณวนซ้ำผ่านจะเร็วกว่ามุมมองหรือแบบสอบถาม
ดังนั้นทุกอย่างขึ้นอยู่กับสถานการณ์
ไม่มีทางปฏิบัติที่แตกต่างกันและถ้าคุณอ่าน BOL คุณจะพบว่า SQL SELECT * เก่าธรรมดาของคุณจาก X จะใช้ประโยชน์จากแผนการแคชเป็นต้น
ควรมีผลประโยชน์เล็กน้อยในการจัดเก็บแผนการดำเนินการ แต่จะไม่สำคัญ
วัตถุประสงค์ของมุมมองคือการใช้แบบสอบถามซ้ำแล้วซ้ำอีก ด้วยเหตุนี้โดยทั่วไปแล้ว SQL Server, Oracle เป็นต้นจะให้มุมมองของคุณเป็น "แคช" หรือ "รวบรวม" ดังนั้นจึงเป็นการปรับปรุงประสิทธิภาพ โดยทั่วไปแล้วสิ่งนี้ควรทำงานได้ดีกว่าการสืบค้นแบบ "ง่าย" แต่ถ้าการสืบค้นนั้นง่ายมากจริง ๆ แล้วประโยชน์นั้นอาจเล็กน้อย
ตอนนี้ถ้าคุณกำลังทำคิวรีที่ซับซ้อนให้สร้างมุมมอง
ในการค้นหาของฉันการใช้มุมมองนั้นเร็วกว่าแบบสอบถามปกติเล็กน้อย ขั้นตอนการจัดเก็บของฉันใช้เวลาประมาณ 25 นาที (ทำงานกับชุดบันทึกที่ใหญ่กว่าและเชื่อมต่อหลายรายการ) และหลังจากใช้มุมมอง (ไม่รวมกัน) ประสิทธิภาพก็เร็วขึ้นเล็กน้อย แต่ไม่สำคัญเลย ฉันต้องใช้เทคนิค / วิธีการเพิ่มประสิทธิภาพข้อความค้นหาอื่น ๆ เพื่อให้มีการเปลี่ยนแปลงอย่างมาก
เลือกจากมุมมองหรือจากตารางจะไม่สมเหตุสมผลเกินไป
แน่นอนถ้ามุมมองไม่มีการรวมเขตข้อมูลและอื่น ๆ ที่ไม่จำเป็นคุณสามารถตรวจสอบแผนการดำเนินการของแบบสอบถามการรวมและดัชนีที่ใช้ในการปรับปรุงประสิทธิภาพการทำงานของมุมมองได้
คุณสามารถสร้างดัชนีในมุมมองเพื่อค้นหาข้อกำหนดได้เร็วขึ้น http://technet.microsoft.com/en-us/library/cc917715.aspx
แต่ถ้าคุณกำลังค้นหาเช่น '% ... %' มากกว่าเอ็นจิ้น sql จะไม่ได้รับประโยชน์จากดัชนีในคอลัมน์ข้อความ หากคุณสามารถบังคับให้ผู้ใช้ทำการค้นหาเช่น '... %' จะเร็วกว่านั้น
อ้างถึงคำตอบในฟอรัม asp: https://forums.asp.net/t/1697933.aspx?Which+is+faster+when+using+SELECT+query+VIEW+ หรือ+Table+
กับความคาดหวังทั้งหมดมุมมองจะช้าลงในบางสถานการณ์
ฉันค้นพบสิ่งนี้เมื่อเร็ว ๆ นี้เมื่อฉันมีปัญหาเกี่ยวกับข้อมูลซึ่งถูกดึงจาก Oracle ซึ่งจำเป็นต้องมีการนวดในรูปแบบอื่น อาจจะเป็นแถวที่มา 20k โต๊ะเล็ก ๆ ในการทำเช่นนี้เราได้นำเข้าข้อมูล oracle ว่าไม่เปลี่ยนแปลงเท่าที่จะทำได้ลงในตารางจากนั้นใช้มุมมองเพื่อแยกข้อมูล เรามีมุมมองรองตามมุมมองเหล่านั้น อาจจะมีมุมมอง 3-4 ระดับ
หนึ่งในคำถามสุดท้ายซึ่งแยกออกมาอาจเป็น 200 แถวจะใช้เวลาเกิน 45 นาที! ข้อความค้นหานั้นอิงตามการเรียงซ้อนของมุมมอง อาจจะลึก 3-4 ระดับ
ฉันสามารถใช้มุมมองที่เป็นปัญหาแต่ละแทรก sql ลงในแบบสอบถามที่ซ้อนกันหนึ่งและดำเนินการในไม่กี่วินาที
เรายังพบว่าเราสามารถเขียนแต่ละมุมมองลงในตารางชั่วคราวและสอบถามว่าแทนที่มุมมองและยังเร็วกว่าการใช้มุมมองแบบซ้อน
สิ่งที่น่าแปลกใจก็คือประสิทธิภาพการทำงานนั้นดีจนกระทั่งเราถึงขีด จำกัด ของแถวของแถวต้นทางที่ถูกดึงเข้าไปในฐานข้อมูลดำเนินการเพียงแค่หลุดจากหน้าผาไปทั่วพื้นที่ของสองสามวัน - แหล่งแถวอีกไม่กี่แถว
ดังนั้นการใช้ข้อความค้นหาที่ดึงจากมุมมองซึ่งดึงจากมุมมองนั้นช้ากว่าแบบสอบถามที่ซ้อนกันมากซึ่งไม่สมเหตุสมผลสำหรับฉัน
ฉันวิ่งข้ามกระทู้นี้และต้องการแบ่งปันโพสต์นี้จาก Brent Ozar เป็นสิ่งที่ควรพิจารณาเมื่อใช้กลุ่มความพร้อมใช้งาน