SQL 存储过程中注释的性能影响

Posted

技术标签:

【中文标题】SQL 存储过程中注释的性能影响【英文标题】:Performance Implications of Comments in SQL Stored Procedures 【发布时间】:2009-03-30 16:27:04 【问题描述】:

最近在我的日常工作中被告知,任何与我们的存储过程有关的 cmets 都不得存在于存储过程中,而必须使用扩展属性。

过去我们用过这样的东西。

/*
 * NOTE: Auto-Generated Procedure DO NOT MODIFY
 */
CREATE PROCEDURE dbo.MyProc
AS
SELECT *
FROM MyTable
GO

这样,任何人在 SSMS 中打开程序时都会看到注释,其他 cmets 也存在于程序中以记录我们的流程。现在我不知道有任何性能/内存问题。但是,我们有些人坚持这样做。

我找不到任何文件来证明或否认此类 cmets 存在性能和/或内存问题。

所以我的问题是,有没有人知道任何可以证明或否认这一点的文件?

【问题讨论】:

【参考方案1】:

它会稍微减慢存储过程的编译速度,而且这种情况不应该经常发生。

基本上这听起来像是在散布恐慌。鉴于 cmets 有多么有用(适度),我要求提供 cmets 损害性能的证据。对我来说,这听起来像是一个荒谬的政策。

(在有人声称性能时要求提供证据是一个很好的一般规则 - 尤其是,如果他们建议您为了所谓的性能增益而牺牲可读性或其他一些积极属性。 )

【讨论】:

我同意,可悲的是,在我的情况下,我有责任提供他们错误的文件......【参考方案2】:

文本(包括 cmets)存储在 SQL 2005+ 中的 sys.sql_modules 中。所以它增加了系统表的大小。

编译生成计划时,cmets 被忽略:它们是 cmets。就像任何合理的语言一样...?

但是,在某些情况下,debug comments 显然仍然可以被解析并影响事物。

这是我不久前看到的,但忽略了它(并搜索了这个答案)。

【讨论】:

以上是关于SQL 存储过程中注释的性能影响的主要内容,如果未能解决你的问题,请参考以下文章

高性能安全式SQL拼接

存储过程性能低怎么破?

Sql Server 2008 R2 - SSMA 转换的扩展过程调用(IMPL 过程)影响性能

SQL Server 存储过程性能测试

PL/SQL出现存储过程注释中文乱码

SQL 存储过程返回值