Один из моих коллег назвал хранимую процедуру в нашей базе данных 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
Запустите его, затем откройте Profiler (добавьте SP:CacheMiss
событие «Хранимые процедуры ->» ) и снова запустите хранимые процедуры. Предполагается, что вы увидите разницу между двумя хранимыми процедурами: sp_Select1
хранимая процедура будет генерировать на одно SP:CacheMiss
событие больше, чем Select1
хранимая процедура (статья ссылается на SQL Server 7.0 и SQL Server 2000 ).
Когда я запускаю пример в своей среде SQL Server 2008 R2, я получаю одинаковое количество SP:CacheMiss
событий для обеих процедур (как в базе данных tempdb, так и в другой тестовой базе данных).
Вот мне и интересно
- Могу ли я сделать что-то не так при выполнении примера?
Является лиsproc sp_something
adagium «не называть пользователя » все еще действительным в более новых версиях SQL Server?- Если так, есть ли хороший пример, который показывает его действительность в SQL Server 2008 R2?
Большое спасибо за ваши мысли по этому поводу!
РЕДАКТИРОВАТЬ
Я нашел создание хранимых процедур (компонент Database Engine) в msdn для SQL Server 2008 R2, который отвечает на мой второй вопрос:
Мы рекомендуем вам не создавать хранимых процедур, используя sp_ в качестве префикса. SQL Server использует префикс sp_ для обозначения системных хранимых процедур. Выбранное вами имя может конфликтовать с какой-то будущей системной процедурой. [...]
Там ничего не сказано о проблемах производительности, вызванных использованием sp_
префикса. Я хотел бы знать, если это все еще так или они исправили это после SQL Server 2000.
sp_
? Это примерно так же полезно, как префикс таблицы с tbl
. Зачем сначала использовать мастер поиска системы (даже если он незначителен или не имеет разницы в производительности), чтобы позволить вам использовать это бессмысленное соглашение об именах?
dbo.sp_Author_Rename
это лучше, чем dbo.Author_Rename
. Я не могу думать об одной вещи, которая имеет смысл.
sp_
версий (необходимо проверить как в основной, так и в пользовательской базах данных, поскольку это отдает приоритет системным процессам вmaster
-> процессам в пользовательской БД -> не системной Procs inmaster
)