残念ながら(または幸いなことに)私が共有しようとしている知識は経験的には得られませんが、大部分はブルジョアのインターネットからのいくつかの記事の無料翻訳です。
そのため、その名前が示すように、それは最適化に関するものです。 これから説明するすべてのアクションによって、パフォーマンスが大幅に(多少は)大きくなるということをすぐに予約します。
この記事は、最適化のトピックを完全に開示することを主張するものではなく、むしろ私の仕事に適用する実践の集まりであり、その有効性を保証することができます。 行こう!
1.プロシージャに行を含める-SET NOCOUNT ON:各DML式で、SQLサーバーは、処理されたレコードの数を含むメッセージを慎重に返します。 この情報は、コードのデバッグ中に役立つ場合がありますが、その後はまったく役に立ちません。 SET NOCOUNT ONと記述することにより、この機能をオフにします。 複数の式または\およびループを含むストアドプロシージャの場合、トラフィックの量が大幅に削減されるため、このアクションによりパフォーマンスが大幅に向上します。
CREATE PROC dbo.ProcName
AS
SET NOCOUNT ON;
--
SELECT column1 FROM dbo.TblTable1
-- SET NOCOUNT
SET NOCOUNT OFF;
GO
2.スキームの名前とオブジェクトの名前を使用します 。これは明確だと思います。 この操作は、サーバーにオブジェクトを探す場所を指示し、ビンをランダムに調べるのではなく、どこに行くべきか、何をすべきかをすぐに認識します。 多数のデータベース、テーブル、ストアドプロシージャを使用すると、時間と神経を大幅に節約できます。
SELECT * FROM dbo.MyTable --
--
SELECT * FROM MyTable --
--
EXEC dbo.MyProc --
--
EXEC MyProc --!
3.ストアドプロシージャの名前にプレフィックス「sp_」を使用しないでください。プロシージャ名が「sp_」で始まる場合、SQL Serverは最初にメインデータベースを検索します。 実際、このプレフィックスは個人の内部サーバーストアドプロシージャに使用されます。 したがって、データベースと同じ名前のプロシージャが見つかった場合、その使用は追加コストにつながり、誤った結果にさえつながる可能性があります。
4. IF EXISTS(SELECT *)の代わりにIF EXISTS(SELECT 1)を使用します。別のテーブルのレコードを確認するには、式IF EXISTSを使用します。 内部式から少なくとも1つの値が返される場合、この式はtrueを返します。「1」、すべての列、またはテーブルは関係ありません。 返されたデータは、原則として、いかなる方法でも使用されません。 したがって、以下に示すように、データ転送中に「1」を使用してトラフィックを圧縮する方が論理的です。
IF EXISTS (SELECT 1 FROM sysobjects
WHERE name = 'MyTable' AND type = 'U')
5. TRY-Catchを使用してエラーをキャッチします。2005サーバーより前では、各リクエストの後に、膨大な数のエラーチェックがプロシージャに書き込まれていました。 より多くのコードは常により多くのリソースと時間を消費します。 2005 SQL Serverでは、この問題を解決するためのより正確で便利な方法が登場しました。
BEGIN TRY
--
END TRY
BEGIN CATCH
--
END CATCH
おわりに
原則として、今日はすべてが揃っています。 繰り返しますが、これは私が個人的に練習で使用したテクニックのみであり、その有効性を保証できます。
PS
私の最初の投稿、厳密に判断しないでください。