1. SqlDataRead とデータセットの選択 Sqldataread の利点: データの読み取りが非常に高速です。返されたデータに多くの処理が必要ない場合は、datset よりもパフォーマンスがはるかに優れている SqlDataReader を使用することをお勧めします。欠点: データが読み取られるまでデータベースへの接続を閉じることができません
(SqlDataReader はデータを早送り方向で読み取ります。SqlDataReader クラスは、SQL Server データベースから取得した順方向専用データ ストリームを読み取る方法を提供します。これは SQL Server のネイティブ ネットワーク データ送信形式では、データベース接続からデータを直接読み取ります。DataReader は、時間内にデータ接続を解放するために明示的に閉じる必要があります。) Dataset
はデータを読み取り、メモリにキャッシュします。欠点: メモリの使用量が多くなります。返されたデータに対して多くの処理を行う必要がある場合は、Dataset を使用してデータベースへの接続操作を減らすことをお勧めします。利点: データベースへの接続を閉じるには一度接続するだけで済みます
。一般に、大量のデータを読み取り、返されたデータに対して多くの処理を行わない場合は、大量のデータに対して SqlDataReader を使用します。返されたデータを処理する場合、SqlDataReader と Dataset の選択はプログラム関数の実現に依存します。
2. ExecuteNonQuery および ExecuteScalar は、
データを更新するときに結果セットを返す必要はありません。ExecuteNonQuery を使用することをお勧めします。結果セットが返されないため、ネットワーク データ送信を省略できます。影響を受ける行数を返すだけです。データを更新するだけの場合、ExecuteNonQuery のパフォーマンスのオーバーヘッドは比較的小さいです。
ExecuteScalar は、結果セットの最初の行の最初の列のみを返します。 ExecuteScalar メソッドを使用して、データベースから単一の値 (ID 番号など) を取得します。この操作に必要なコードは、返されたデータに対して単一の値を生成するために必要な操作を実行する ExecuteReader メソッドを使用する場合よりも少なくなります。
*ExecuteNonQuery を使用してデータを更新するだけです。単一値のクエリは ExecuteScalar データ バインディング オプション
3 を使用します。 データ バインディング DataBinder の
一般的なバインディング メソッド <%# DataBinder.Eval(Container.DataItem, "field name") %> DataBinder.eval を使用します。データ ソース (Dataread または dataset) は関係ありません。 eval はこのデータ オブジェクトを文字列に変換しますので、データの種類を気にする必要はありません。リフレクション機能を使用して、基礎となるバインディングに対して多くの作業が行われました。使いやすいからといって、データのパフォーマンスに影響を与えます。 <%# DataBinder.Eval(Container.DataItem, "フィールド名") %> を見てみましょう。データセットにバインドされている場合、DataItem は実際には DataRowView です (データ リーダー (dataread) にバインドされている場合は、IdataRecord です)。したがって、DataItem を DataRowView に直接変換すると、パフォーマンスが大幅に向上します。
<%# ctype(Container.DataItem,DataRowView).Row("フィールド名") %>
*データには <%# ctype(Container.DataItem,DataRowView).Row("フィールド名") %> を使用することをお勧めしますバインディング。データ量が多い場合、速度は数百倍に向上します。使用するときは、次の 2 つの点に注意してください。 1. <%@ Import namespace="System.Data"%> をページに追加する必要があります。 2. フィールド名の大文字と小文字に注意してください (特に注意してください)。クエリと矛盾している場合、場合によっては <%# DataBinder.Eval(Container.DataItem, "フィールド名") %> よりも遅くなることがあります。さらに速度を向上させたい場合は、<%# ctype(Container.DataItem,DataRowView).Row(0) %> メソッドを使用できます。ただし、可読性は高くありません。
以上がvb.netの書き方です。 C# の場合: <@% ((DataRowView)Container.DataItem)["フィールド名"] %>
ページ上の各実行プロセスのステータスを表示する最も簡単な方法: ページのトレース属性が次の場合に詳細を表示できます。真実。
1. ストアド プロシージャを使用します。
1. パフォーマンス: ストアド プロシージャは、標準 SQL 言語にはない多くの高度な機能を提供します。パラメーターを渡して論理式を実行する機能は、アプリケーション設計者が複雑なタスクを処理するのに役立ちます。さらに、ストアド プロシージャはローカル サーバーに保存されるため、プロシージャの実行に必要なネットワーク送信帯域幅と実行時間が削減されます。 (ストアド プロシージャは SQL 文をプリコンパイルしているため、プログラム内で SQL 文を実行するよりも実行速度がはるかに高速です)
2. プログラムの構造: プログラムのスケーラビリティの観点から、ストアド プロシージャを使用すると、将来のプログラムの変更に影響します。便宜上。たとえば、データベースの構造が変更された場合、対応するストレージ構造とプログラムの呼び出し部分を変更するだけで済みます。この部分はこの記事の範囲外であり、プログラム構造設計に属します。したがって、ここでは詳しく説明しません。
3. プログラムのセキュリティ: SQL インジェクション攻撃は、ストアド プロシージャを使用することで回避できます。
2. クエリ文の最適化（SQL Server2000の場合）
SQL文の実行効率を考慮せず、目的のためだけにSQL文を書いている人が多いです。ここでは、テーブルの順序を最適化する方法のみを説明します (SQL ステートメントの最適化と原則については、SQL Server2000 の学習ノートで説明します)。SQL
ステートメントの実行効率を高めるために、SQL Server2000 のクエリ アナライザーを使用できます。ステートメントの実行プロセスを表示します。
テーブル順序の最適化: 通常の状況では、sqlserver はテーブル接続を自動的に最適化します。例: select name,no from A join B on A. id=B.id join C on C.id=A.id where name='wang'ただし、
A テーブルは From の最初にリストされ、次に B、最後にリストされます。 Cです。ただし、SQL サーバーは最初に c テーブルを使用する場合があります。その選択原理は、クエリを 1 行または数行に制限することで、他のテーブルで検索されるデータの総量を減らすことができます。ほとんどの場合、SQL Server は最適な選択をしますが、複雑な結合クエリが予想よりも遅い場合は、SET FORCEPLAN ステートメントを使用して、SQL Server がテーブルを出現順に使用するように強制できます。上記の例のように、 SET FORCEPLAN ON....SET FORCEPLAN OFF を追加します。 テーブルの実行順序は、記述した順序で実行されます。クエリ アナライザーで 2 つの実行効率を表示し、テーブルを結合する順序を選択します。
*SET FORCEPLAN を使用してテーブル接続シーケンスを選択します
。 3. ページ最適化 (.aspx) は
主にいくつかのページ属性に焦点を当てます。
1. EnableViewState (ページのビュー ステート)。特別な要件がない場合は false に設定します。 ViewState を使用する場合、各オブジェクトはまず ViewState にシリアル化され、その後ポストバックによって逆シリアル化される必要があるため、ViewState の使用にコストはかかりません。使用するオブジェクトをできる限り少なくし、可能であれば ViewState に入れるオブジェクトの数を減らします。ビューステートは基本的に次の状況で無効にできます。
(1) ページ コントロール (.ascx)
(2) ページはそれ自体に戻されません。
(3) コントロールのイベント処理は必要ありません。
(4) コントロールには動的またはデータ バインドされたプロパティ値がありません (またはポストパックごとにコードで処理されます)
次のように、単一ページまたはページごとに ViewState を無効にします。 単一ページ: <%@ Page EnableViewState=" False" %> 各ページ: web.config <Pages EnableViewState="false" /> では、EnableSessionState はデフォルト値を維持できます (ページがセッション状態を使用する場合にのみリソースを占有します)。 EnableViewStateMac 特別なセキュリティ要件がない場合は、デフォルト値をそのまま使用します。
2. ページレイアウト。ページレイアウトモデル。 Flowlayout を使用することをお勧めします (絶対位置属性を使用せずに要素が追加されます)。Gridlayout (絶対位置属性) は、主にコントロールの位置情報である絶対位置を使用するため、Flowlayout よりも多くのコードを生成します。
3. プロジェクトをリリースするときは、ページのデバッグ ステータスを忘れずにリリースしてください。
4. HTML言語の最適化。私の提案は、HTML/JavaScript に習熟し、vs.net2003 によって自動的に生成される無駄な HTML コードを減らすことです。
5. スマート ナビゲーションを true に設定すると、ユーザーのパフォーマンスが大幅に向上します。このプロパティを有効にすると、更新が必要な部分をインテリジェントに更新できます。
4. コントロールの選択:
HTML コントロールとサーバー コントロールの選択。サーバー コントロールによってもたらされる利便性と機能の実現は、HTML コントロールの比ではありません。ただし、これはサーバー側のリソースを犠牲にして取得されます。私の個人的な提案: HTML コントロールが実現したい機能を実現できず、一部のスクリプト言語 (javascrpt/vbscript など) と組み合わせても実現できない場合。その場合にのみ、サーバー コントロールが選択されます。サーバー コントロールを選択した後、一部のページ状態をキャンセルするなど、そのコントロールの最適化を試みます (特にコントロールの最適化を参照)。
主にいくつかの一般的なデータ コントロールについて説明します。DataGrid: 最も強力なデータ コントロールが付属しています
。
データ表示 コントロールには、データの変更、削除、追加、ページングなどの多くの実用的な機能が組み込まれています。データを表示するだけの場合は、DataGrid を選択しないでください (すべてのデータがビューステートに保存されます)。また、Microsoft は自動ページングの最下層で多くの作業を行っています。使いやすいですが、パフォーマンスのオーバーヘッドが膨大です。
DataList: DataGrid よりも関数がはるかに少なくなっています。しかし、はるかにカスタマイズ可能です。ユニークな複数行のデータ表示は、私たちに多くの利便性をもたらします。基本的にはDataGridで実現できる機能を実装できます。したがって、それを使用することをお勧めします。
リピーター: 機能は最も低いですが、非常にカスタマイズ可能です。データを表示するだけの場合は、これを使用することをお勧めします。多くの機能が削減されているため、サーバーのパフォーマンスの消費は最小限に抑えられます。したがって、データを表示する場合は、基本的にRepeater、次にDataList、最後にDataGridを選択します
* htmlコントロールを選択するようにしています。クライアントで実装できる機能はクライアント（JavaScriptに精通したもの）で実装されるため、サーバーへの負担が軽減されます。データ コントロールの選択シーケンス:Repeater、DataList、DataGrid
5. サーバー コントロールの最適化:
1.
Viewstate コントロールのビューステートは、基本的にページのビューステートと同じです。コントロールの一部の状態を保存するために使用されます。処理原理は、ページのビューステートの処理と同じです。興味がある場合は、Datagrid を使用してデータをバインドし、ビューステートによって保存されるデータの量をテストできます。基本的に、Datagrid によって表示されるデータの量と同じです。
2. Ispostpack の
デフォルトは false です。イベントを生成する必要がある場合は、
このコントロールの知識に主に依存します。コントロールの内部の仕組みを理解すればするほど、コントロールを適切に最適化できるようになります。
パフォーマンスの最適化は、ほんの数文で説明することはできません。私が書いたことは氷山の一角にすぎません。パフォーマンスの最適化は、日々の経験の蓄積とプログラムの動作原理の継続的な理解に依存しています。
6. 例外の問題
ユーザーがフォーラムに存在しない、ユーザーのパスワードが間違っているなどの一般的な問題には、例外を使用する必要はありません。例外のインスタンス化には多くのリソースが必要であり、入力が必要になるためです。例外情報 (例外の種類、例外がスローされる例外の場所) など)。もちろん例外の使用を避けるためではなく、必要な例外を処理するためです。例外の原則は、可能な限り使用しないことです。また、システム内の既存の例外を使用できる場合は、独自の例外を生成しないでください。