Все ще неправильно починати ім'я користувальницької процедури, що зберігається, з sp_?

Один з моїх колег назвав збережену процедуру в нашій базі даних SQL Server 2008 R2 sp_something. Побачивши це, я одразу подумав: "Це НЕПРАВНО!" і почав шукати мої закладки для цієї інтернет-статті, яка пояснює, чому це неправильно, щоб я міг надати своєму колезі пояснення.

У статті ( Брайан Моран ) пояснюється, що надання збереженій процедурі префікса 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

Ви запускаєте це, потім відкриваєте Профілер (додайте Збережені процедури -> SP:CacheMissподія) та запускайте збережені процедури заново. Ви повинні побачити різницю між двома збереженими процедурами: sp_Select1збережена процедура генерує ще одну SP:CacheMissподію, ніж Select1збережена процедура (статті посилаються на SQL Server 7.0 та SQL Server 2000. )

Коли я запускаю приклад у моєму середовищі SQL Server 2008 R2, я отримую однакову кількість SP:CacheMissподій для обох процедур (і в tempdb, і в іншій тестовій базі даних).

Тож мені цікаво:

• Чи можу я зробити щось не так у виконанні прикладу?
• Чи sproc sp_somethingадагіум "не називати користувача " все ще дійсний у нових версіях SQL Server?
• Якщо так, чи є хороший приклад, який показує його дійсність у SQL Server 2008 R2?

Дякую за ваші думки з цього приводу!

EDIT

Я знайшов Створення збережених процедур (Engine Database Engine) у 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

Тепер давайте побудуємо обгортку, яка виконує їх кілька разів, з префіксом схеми та без:

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.

Як показує простий коментар Мартіна Сміта - так, якщо у вас є збережена процедура з sp_префіксом - виконавець запитів SQL Server спочатку завжди перевірятиме в masterбазі даних, щоб побачити, чи існує збережена процедура (позначена як системна збережена процедура) цим ім'ям.

І якщо вона існує, ця системно збережена процедура з masterбази даних завжди переважає і буде виконуватися замість вашої власної.

Так що так - це все ще стоїть: не використовувати в 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

Я отримав однакову кількість пропущених кеш-подій і подій в обох випадках, і в обох випадках план був доданий до кешу. Я також запускав обидва програми кілька разів, і не було послідовної різниці в процесі процесора або минулому часу, повідомленому dm_exec_query_stats.

Інша стурбованість полягає в тому, що оскільки «sp_» програми можуть бути виконані від master, ви можете отримати копію протоколу, який був запущений у master замість БД, в якій ви працюєте, але швидкий тест покаже, що це не так. Однак якщо Proc випадає з БД, в якій ви працюєте, і копія існує в master, то вона буде виконана, що може бути проблемою, якщо це стара версія. Якщо це питання, я б не використовував "sp_", щоб назвати прок.

Я вважаю, що це має бути зроблено, коли ви не вказуєте повністю кваліфіковану назву об'єкта. Так, "EXEC sp_something" спочатку перевірить майстер, але "EXEC dbname.dbo.sp_something" ніколи не перейде до майстра спочатку.

Якщо я пригадую, урок - завжди використовувати цілком кваліфіковану назву.