ประสิทธิภาพของขั้นตอนการจัดเก็บเทียบกับแบบสอบถามแบบดิบ

ฉันได้อ่านมากทั้งสองด้านของการอภิปรายนี้: มีประสิทธิภาพที่มีนัยสำคัญที่จะได้รับโดยใช้วิธีการที่เก็บไว้เฉพาะกับแบบสอบถามแบบดิบหรือไม่ ฉันสนใจ SQL Server โดยเฉพาะ แต่จะสนใจในฐานข้อมูลใด ๆ และทั้งหมด

มันน้อยกว่าดังนั้นใน SQL Server 2008 และสูงกว่า แต่ก็ยังอยู่ที่นั่น สิ่งที่เกิดขึ้นคือแคชแผนการดำเนินการและ SQL Server สามารถสอบถามพารามิเตอร์อัตโนมัติที่ส่งมาเมื่อใช้กระบวนงานที่เก็บไว้ (ที่ไม่มี SQL แบบไดนามิกอยู่ภายใน) แบบสอบถามจะถูกกำหนดไว้ล่วงหน้าแล้วดังนั้น SQL Server จึงไม่ ' ไม่จำเป็นต้องสร้างแผนสำหรับแต่ละแบบสอบถามเมื่อเรียกใช้เนื่องจากมีการจัดเก็บแผนไว้ในแคชแผนแล้ว

และอย่าลืมเกี่ยวกับปัญหาด้านความปลอดภัย (ไดนามิก SQL, สิทธิ์ขั้นต่ำและอื่น ๆ ) ที่หายไปเมื่อใช้กระบวนงานที่เก็บไว้

เมื่อแอปใช้ SQL แบบไดนามิกกับตารางฐานเพื่อเลือกแทรกอัปเดตและลบข้อมูลในตารางที่แอปพลิเคชันต้องมีสิทธิ์ในวัตถุเหล่านั้นทั้งหมดโดยตรง ดังนั้นหากใครบางคนใช้การฉีด SQL เพื่อเข้าสู่เซิร์ฟเวอร์พวกเขาจะมีสิทธิ์ในการสอบถามเปลี่ยนแปลงหรือลบข้อมูลทั้งหมดในตารางเหล่านั้น

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

เนื่องจากการฉีด SQL เป็นวิธีที่ง่ายที่สุดในการเจาะเข้าไปในฐานข้อมูลนี่เป็นสิ่งที่สำคัญ

ในฐานะที่เป็นภาคผนวกของคำตอบของ Denny ไม่ใช่เรื่องแปลกที่จะค้นหาระบบที่ใช้หน่วยความจำบัฟเฟอร์พูลจำนวนมากในแผนการดำเนินการเฉพาะกิจแบบใช้ครั้งเดียวหรือน้อยซึ่งสร้างขึ้นจากการใช้แบบสอบถามมากกว่า procs

ในกรณีที่เลวร้ายที่สุดเมื่อเร็ว ๆ นี้ 8GB จัดสรรให้กับอินสแตนซ์แคชแผน 3GB, แผนการใช้งานเพียงครั้งเดียว 2.5GB ส่วนใหญ่เป็น SQL2005 ดังนั้นจึงไม่มีตัวเลือกให้ลองปรับการตั้งค่าภาระงานแบบแอดฮอค

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

SQL Server จะแคชและปรับโพรซีเดอร์ที่เก็บไว้และ ad-hoc SQL ให้เหมาะสมในลักษณะเดียวกัน ตัวอย่างเช่นขั้นตอนนี้:

create procedure dbo.TestSB(@id int) as select * from Orders where id = @id

จะถูกออปติไมซ์และแคชเหมือนกันกับ:

select * from Orders where id = @id

อย่างไรก็ตาม ad-hoc SQL ต่อไปนี้ไม่สามารถแคชได้อย่างมีประสิทธิภาพเนื่องจากค่าฮาร์ดโค้ด:

select * from Orders where id = 42

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