ยังผิดไหมที่จะเริ่มต้นชื่อผู้ใช้ที่จัดเก็บโพรซีเดอร์ด้วย sp_?

หนึ่งในเพื่อนร่วมงานของฉันตั้งชื่อกระบวนงานที่เก็บไว้ในฐานข้อมูล SQL Server 2008 R2 ของsp_somethingเรา เมื่อฉันเห็นสิ่งนี้ฉันก็คิดทันที: "นั่นมันผิด!" และเริ่มค้นหาบุ๊กมาร์กของฉันสำหรับบทความออนไลน์นี้ซึ่งอธิบายว่าทำไมมันผิดดังนั้นฉันจึงสามารถให้คำอธิบายแก่เพื่อนร่วมงานของฉันได้

ในบทความ (โดยBrian Moran ) มีการอธิบายว่าการให้ขั้นตอนการจัดเก็บคำนำหน้าsp_ทำให้ SQL Server ดูที่ฐานข้อมูลหลักสำหรับแผนรวบรวม เนื่องจากsp_sprocไม่ได้อยู่ที่นั่น SQL Server จะคอมไพล์โพรเซสอีกครั้ง

ตัวอย่างต่อไปนี้ให้ไว้ในบทความเพื่อแสดงความแตกต่างระหว่างสองขั้นตอน:

USE tempdb;
GO

CREATE PROCEDURE dbo.Select1 AS SELECT 1;
GO

CREATE PROCEDURE dbo.sp_Select1 AS SELECT 1;
GO

EXEC dbo.sp_Select1;
GO

EXEC dbo.Select1;
GO

คุณรันสิ่งนี้จากนั้นเปิด Profiler (เพิ่มกระบวนงานที่เก็บไว้ -> SP:CacheMissเหตุการณ์) และเรียกใช้กระบวนงานที่เก็บไว้อีกครั้ง คุณควรจะเห็นความแตกต่างระหว่างสองกระบวนงานที่เก็บไว้: กระบวนงานที่sp_Select1เก็บไว้จะสร้างSP:CacheMissเหตุการณ์เพิ่มเติมมากกว่าหนึ่งSelect1กระบวนงานที่เก็บไว้ (บทความอ้างอิงSQL Server 7.0และSQL Server 2000 )

เมื่อฉันรันตัวอย่างในสภาพแวดล้อม SQL Server 2008 R2 ของฉันฉันจะได้รับSP:CacheMissเหตุการณ์จำนวนเท่ากันสำหรับทั้งสองโพรซีเดอร์ (ทั้งใน tempdb และในฐานข้อมูลทดสอบอื่น)

ดังนั้นฉันสงสัย:

• ฉันสามารถทำสิ่งผิดพลาดในการดำเนินการตามตัวอย่างได้หรือไม่?
• sproc sp_somethingadagium ' ไม่ตั้งชื่อผู้ใช้' ยังคงใช้ได้ใน SQL Server รุ่นที่ใหม่กว่าหรือไม่
• ถ้าเป็นเช่นนั้นมีตัวอย่างที่ดีที่แสดงความถูกต้องใน SQL Server 2008 R2 หรือไม่

ขอบคุณมากสำหรับความคิดของคุณในเรื่องนี้!

แก้ไข

ฉันพบการสร้างกระบวนงานที่เก็บไว้ (โปรแกรมฐานข้อมูล)บน msdn สำหรับ SQL Server 2008 R2 ซึ่งตอบคำถามที่สองของฉัน:

เราขอแนะนำให้คุณไม่สร้างขั้นตอนการจัดเก็บใด ๆ โดยใช้ sp_ เป็นคำนำหน้า SQL Server ใช้คำนำหน้า sp_ เพื่อกำหนดขั้นตอนการจัดเก็บระบบ ชื่อที่คุณเลือกอาจขัดแย้งกับขั้นตอนของระบบในอนาคต [ ... ]

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

การทดสอบตัวเองค่อนข้างง่าย มาสร้างสองโพรซีเดอร์ง่ายๆกัน:

CREATE PROCEDURE dbo.sp_mystuff
AS
  SELECT 'x';
GO
CREATE PROCEDURE dbo.mystuff
AS
  SELECT 'x';
GO

ตอนนี้เรามาสร้าง wrapper ที่รันหลาย ๆ ครั้งโดยมีและไม่มีคำนำหน้าสคีมา:

CREATE PROCEDURE dbo.wrapper_sp1
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @i INT = 1;
    WHILE @i <= 1000
    BEGIN
      EXEC sp_mystuff;
      SET @i += 1;
    END
END
GO
CREATE PROCEDURE dbo.wrapper_1
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @i INT = 1;
    WHILE @i <= 1000
    BEGIN
      EXEC mystuff;
      SET @i += 1;
    END
END
GO
CREATE PROCEDURE dbo.wrapper_sp2
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @i INT = 1;
    WHILE @i <= 1000
    BEGIN
      EXEC dbo.sp_mystuff;
      SET @i += 1;
    END
END
GO
CREATE PROCEDURE dbo.wrapper_2
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @i INT = 1;
    WHILE @i <= 1000
    BEGIN
      EXEC dbo.mystuff;
      SET @i += 1;
    END
END
GO

ผล:

สรุป:

• การใช้คำนำหน้า sp_ ช้ากว่า
• การออกจากคำนำหน้าสคีมาช้ากว่า

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

นอกจากนี้ฉันทำการทดสอบรูปแบบนี้ในโพสต์บล็อกต่อไปนี้:

http://www.sqlperformance.com/2012/10/t-sql-queries/sp_prefix

เราขอแนะนำให้คุณไม่สร้างขั้นตอนการจัดเก็บใด ๆ โดยใช้ sp_ เป็นคำนำหน้า SQL Server ใช้คำนำหน้า sp_ เพื่อกำหนดขั้นตอนการจัดเก็บระบบ ชื่อที่คุณเลือกอาจขัดแย้งกับขั้นตอนของระบบในอนาคต [ ... ]

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

ในฐานะที่เป็นความคิดเห็นที่เรียบง่ายของ Martin Smith แสดง - ใช่ถ้าคุณมีโพรซีเดอร์ที่เก็บไว้พร้อมกับsp_คำนำหน้า - ตัวจัดการคิวรี่เซิร์ฟเวอร์ SQL จะเสมอตรวจสอบในmasterฐานข้อมูลก่อนเพื่อดูว่าขั้นตอนการเก็บ (ทำเครื่องหมายว่าเป็นระบบขั้นตอนการเก็บ) โดยใช้ชื่อที่มีอยู่

และถ้ามันมีอยู่ระบบนั้นจะจัดเก็บขั้นตอนจาก masterฐานข้อมูลเสมอและจะถูกดำเนินการแทนตัวคุณ

ใช่แล้ว - มันยังคงอยู่: อย่าใช้ส่วนsp_นำหน้า

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

select * from Person.BusinessEntity b
inner join Person.BusinessEntityAddress ba on b.BusinessEntityID = ba.BusinessEntityID
inner join Person.Address a on ba.AddressID = a.AddressID

ฉันได้รับจำนวนแคชที่พลาดและการเข้าชมจำนวนมากในทั้งสองกรณีและในทั้งสองกรณีมีการเพิ่มแผนลงในแคช ฉันรันทั้งสอง procs หลายครั้งและไม่มีความแตกต่างที่สอดคล้องกันในเวลา CPU หรือเวลาที่ผ่านไปที่รายงานโดย dm_exec_query_stats

ข้อกังวลอีกประการหนึ่งคือเนื่องจาก procs "sp_" สามารถเรียกใช้งานจากต้นแบบได้คุณอาจได้รับสำเนาของ proc ที่ถูกเรียกใช้เป็น master แทนที่จะเป็น DB ที่คุณกำลังทำงานอยู่ แต่การทดสอบอย่างรวดเร็วจะแสดงว่าไม่ใช่กรณี อย่างไรก็ตามหาก proc หลุดจากฐานข้อมูลที่คุณกำลังทำงานอยู่และมีสำเนาอยู่ในต้นแบบแล้วมันจะถูกเรียกใช้งานซึ่งอาจเป็นปัญหาหากเป็นรุ่นเก่า หากนี่เป็นข้อกังวลฉันจะไม่ใช้ "sp_" เพื่อตั้งชื่อ proc

ฉันเชื่อว่าปัญหาต้องทำเมื่อคุณไม่ได้ระบุชื่อวัตถุที่ผ่านการรับรองโดยสมบูรณ์ ดังนั้น "EXEC sp_something" จะตรวจสอบอาจารย์ก่อน แต่ "EXEC dbname.dbo.sp_something" จะไม่ไปเป็นผู้เชี่ยวชาญก่อน

บทเรียนถ้าฉันจำได้ก็คือใช้ชื่อที่ผ่านการรับรองโดยสมบูรณ์