SQLストアドプロシージャのコメントのパフォーマンスへの影響

Question

最近私のストアドプロシージャに関するコメントがストアドプロシージャ内に存在していてはならず、拡張プロパティを使用する必要があります。

これまでは、このようなものを使用していました。

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

いつでも、誰でも、彼らはノートを見ることがSSMSの手順を開いて、この方法は、他のコメントにも、当社のプロセスを文書化する方法に存在していました。今私はこれに関するパフォーマンス/メモリの問題を認識していませんでした。しかし、私たちにはそれが主張する人がいます。

私は、このタイプのコメントによるパフォーマンスおよび/またはメモリの問題の存在を証明または拒否する文書を見つけることができませんでした。

私の質問は、誰かがこれを証明するか拒否することができるドキュメントを知っていますか？

Answer 1

これは、ストアドプロシージャのコンパイルを少し遅くしますが、とにかく頻繁に起こることはありません。

これは基本的に恐怖のように聞こえます。どのように有用なコメントが（適度に）できるかを考えれば、私はの証拠のコメントでパフォーマンスが低下することを要求します。私にとってはばかげた政策のように思える。

（いつでも誰かがパフォーマンスに関する主張を作る要求の厳しい証拠は良い一般的なルールである - 。特に彼らはあなたが読みやすさや想定さ、パフォーマンスの向上のために他のいくつかの正の属性を犠牲にすることを示唆している場合）

Answer 2

テキスト（コメントを含む）は、SQL 2005+のsys.sql_modulesに格納されます。したがって、システムテーブルサイズに追加されます。

プランを作成するコンパイルでは、コメントは無視されます。コメントです。コメントです。どんな合理的な言語と同じように...？

しかし、状況によっては、debug commentsがまだ解析され、影響を受ける可能性があります。

これは私がもう少し前に見たものですが、それを却下しました（この回答で検索しました）。