ナビゲーション · ホームページとして設定 · お気に入りに追加 · モバイル Tencent · Tencent ホームページ ニュース ブログ フォーラム コメント 金融 証券 香港株 ファンド エンターテイメント スター 映画 音楽 スポーツ NBA フットボール 総合 車 不動産 家電 テクノロジー デジタル モバイル ダウンロード 女性の感情 子育て ファッション ショッピング 旅行 読書 オリジナル教育 海外旅行 ゲーム アニメ アニメーション 星座 ビデオ ライブ写真 博覧会 チャリティー 子供 新作 人気 人気 中国のゴールド ディスク ファッションと高級品のカラフルな世界を訪れてください 全国ベストセラーの携帯電話 ランキング リストに従って、今日誕生日を迎える有名人を確認してください。ホーム > テクノロジーとデジタル > デジタル スクロール ニュース > テキスト
SQL Server データベース開発のための Catch-21 http://digi.QQ.com 2009 年 12 月 21 日 09:43 中関村オンライン SQL Server ベースのプロジェクトを担当している場合、または SQL Server を初めて使用する場合は、次のことを行うことができます。データベースのパフォーマンスの問題に直面している場合、この記事では役立つガイダンスを提供します (ガイダンスのほとんどは他の DBMS でも使用できます)。
ここでは、SQL Server を使用するためのヒントを紹介するつもりはありません。また、万能の解決策を提供するつもりもありません。優れた設計を形成する方法についての経験を要約することです。この経験は、私が過去数年間にわたって同じ設計ミスを何度も繰り返し見てきた中で学んだことから来ています。
1. 使用するツールを知る
これを過小評価しないでください。これがこの記事で説明する最も重要な点です。おそらく、多くの SQLServer プログラマがすべての T-SQL コマンドと SQLServer が提供する便利なツールを使いこなしているわけではないことも目にしたことがあるでしょう。
「何? 決して使わない SQL コマンドの学習に 1 か月を無駄にするなんて???」と思われるかもしれません。そうです、これを行う必要はありません。ただし、週末をかけてすべての T-SQL コマンドを実行する必要があります。ここでのタスクは、将来クエリを設計するときに、「ところで、必要な機能を完全に実現できるコマンドは次のとおりです」ということを思い出すことになることを理解することです。そのため、MSDN にアクセスしてクエリの正確な構文を確認してください。このコマンド。
もう一度繰り返しますが、カーソルは使用しないでください。システム全体のパフォーマンスを破壊したい場合は、これらが最も効果的な第一選択です。ほとんどの初心者は、カーソルがパフォーマンスに与える影響を認識せずにカーソルを使用します。これらはメモリを占有し、あらゆる奇妙な方法でテーブルをロックし、カタツムリのように動作します。そして最悪のことは、DBA が実行できるパフォーマンスの最適化をすべて実行しないことと同じになる可能性があることです。 FETCH を実行するたびに SELECT コマンドが実行されることをご存知ですか?これは、カーソルに 10,000 件のレコードがある場合、10,000 件の SELECT が実行されることを意味します。 SELECT、UPDATE、または DELETE のセットを使用して対応する作業を完了すると、はるかに効率的になります。
初心者は一般に、カーソルを使用する方が親しみやすく快適なプログラミング方法であると考えていますが、残念ながら、これはパフォーマンスの低下につながる可能性があります。明らかに、SQL の全体的な目的は、どのように達成するかではなく、何を達成したいかです。
以前、T-SQL を使用してカーソル ベースのストアド プロシージャを書き直したことがあります。テーブルには 100,000 レコードしかありませんでしたが、新しいストアド プロシージャでは完了までに 40 分かかりました。ここを見れば、無能なプログラマが何をやっているのかが分かるはずです！ ！ ！
データを取得して処理し、データベースを更新するための小さなプログラムを作成することもでき、その方が効率的な場合もあります。覚えておいてください: T-SQL はループに関しては何もできません。
もう一度言っておきますが、カーソルを使用するメリットはありません。 DBA の仕事を除いて、カーソルを効果的に使用して何かが行われたのを見たことがありません。
3. データテーブルを標準化する
なぜデータベースを正規化しないのでしょうか?おそらく言い訳は 2 つあります。パフォーマンス上の理由と、まったくの怠惰です。 2番目の点については、遅かれ早かれその代償を支払わなければなりません。パフォーマンスに関しては、まったく遅くないものを最適化する必要はありません。 「元の設計が遅すぎた」という理由でプログラマがデータベースを「非正規化」しているのをよく見かけますが、多くの場合、結果としてシステムが遅くなります。 DBMS は正規化データベースを処理するように設計されているため、正規化の要件に従ってデータベースを設計することに注意してください。
4. SELECT * を使用しないでください。
私もいつも自分でやっているので、これは簡単ではありません。ただし、必要な列を SELECT で指定すると、次のような利点があります。
1 メモリ消費量とネットワーク帯域幅を削減する
2 より安全な設計が可能
3 クエリ オプティマイザーに、インデックスから必要な列をすべて読み取る機会を与えます。
ページ 2: データをどう扱うかを理解する
データベースに堅牢なインデックスを作成することは良いことです。しかし、これを行うのは単なる芸術です。テーブルにインデックスを追加すると、SELECT は高速になりますが、インデックスの作成と維持には多くの追加作業が必要となるため、INSERT と DELETE は大幅に遅くなります。明らかに、ここでの質問の鍵は、このテーブルに対してどのような操作を実行したいかということです。この問題は、特に DELETE と UPDATE の場合、これらのステートメントの WHERE 部分に SELECT コマンドが含まれることが多いため、理解するのが簡単ではありません。
6.「性別」列にはインデックスを作成しないでください。
まず、インデックスによってテーブルへのアクセスがどのように高速化されるかを理解する必要があります。インデックスは、特定の基準に基づいてテーブルを分割する方法と考えることができます。 「性別」などの列にインデックスを作成すると、テーブルが男性と女性の 2 つの部分に単純に分割されます。 1,000,000 件のレコードを含むテーブルを扱っているのですが、この分割にはどのような意味があるのでしょうか?インデックスの維持には時間がかかることに注意してください。インデックスを設計するときは、次のルールに従ってください。名前 + 都道府県 + 性別など、列に含まれる可能性のあるさまざまなコンテンツの数に応じて、列を多い順に配置します。
7. トランザクションを使用する
特にクエリに時間がかかる場合は、トランザクションを使用してください。システムに問題が発生した場合、これにより命が救われます。一般に、ある程度の経験のあるプログラマは、ストアド プロシージャのクラッシュを引き起こす予期せぬ状況に遭遇することがよくあることを理解しているでしょう。
8. デッドロックに注意する
特定の順序でテーブルにアクセスします。最初にテーブル A をロックし、次にテーブル B をロックする場合、すべてのストアド プロシージャでこの順序でロックする必要があります。ストアド プロシージャで (誤って) 最初にテーブル B をロックし、次にテーブル A をロックすると、デッドロックが発生する可能性があります。ロックシーケンスが事前に詳細に設計されていない場合、デッドロックを検出するのは容易ではありません。
よくある質問は、「ComboBox に 100,000 レコードをすばやく追加するにはどうすればよいですか?」です。これは正しくありません。これを行うことはできませんし、行う必要もありません。それは非常に簡単です。ユーザーが必要なレコードを見つけるために 100,000 件のレコードを参照しなければならないとしたら、ユーザーは間違いなくあなたを呪うでしょう。ここで必要なのは、より優れた UI であり、ユーザーに表示するレコードの数は 100 または 200 未満にする必要があります。
サーバー側カーソルと比較して、クライアント側カーソルはサーバーとネットワークのオーバーヘッドを削減し、ロック時間も短縮できます。
11.パラメータクエリを使用する
CSDN 技術フォーラムで次のような質問を時々見かけます。「SELECT * FROM aWHEREa.id='A'B、一重引用符のクエリが原因で例外が発生しました。どうすればよいですか?」。一般的な答えは次のとおりです。2 つ使用します。一重引用符の代わりに一重引用符を使用します。これは間違いです。これにより、根本的な原因ではなく症状が解決されます。これは、重大なバグを引き起こすだけでなく、他の文字でも同様の問題が発生する可能性があるためです。さらに、SQL Server バッファリング システムが正常に機能しなくなります。パラメータクエリを使用すると、これらの問題はすべて解消されます。
12. プログラムのコーディング時に大規模なデータ データベースを使用する
開発時にプログラマーが使用するテスト データベースには通常、大量のデータはありませんが、エンド ユーザーが大量のデータを持っていることがよくあります。私たちの通常のアプローチは間違っています。理由は非常に単純です。ハードドライブは現在それほど高価ではありませんが、パフォーマンスの問題が回復不能になるまで気付かないのはなぜでしょうか?
13. 大量のデータをインポートするために INSERT を使用しないでください。
どうしても必要な場合を除き、これを行わないでください。 UTS または BCP を使用すると、柔軟性とスピードを一気に実現できます。
14. タイムアウトの問題に注意する
データベースにクエリを実行する場合、一般的なデータベースのデフォルト値は 15 秒や 30 秒など比較的小さいです。一部のクエリは、特にデータベース内のデータ量が増加し続ける場合、これよりも実行に時間がかかります。
ページ 3: 同じレコードを同時に変更する場合の問題を無視しないでください
15. 同じレコードを同時に変更する問題を無視しないでください
場合によっては、2 人のユーザーが同時に同じレコードを変更することがあります。このように、後者の変更子が前の変更子の操作を変更すると、一部の更新が失われます。この状況に対処するのは難しいことではありません。タイムスタンプ フィールドを作成し、書き込む前にチェックし、許可されている場合は変更をマージし、競合がある場合はユーザーにプロンプトを表示します。
16. 詳細テーブルにレコードを挿入する場合、メインテーブルで SELECT MAX(ID) を実行しないでください。
これは、2 人のユーザーが同時にデータを挿入するときにエラーを引き起こすよくある間違いです。 SCOPE_IDENTITY、IDENT_CURRENT、IDENTITY を使用できます。トリガーが存在すると問題が発生する可能性があるため、IDENTITY は可能な限り使用しないでください (ここでの説明を参照)。
17. 列を NULL 許容として設定しないようにする
可能であれば、列を NULL 可能にすることは避けてください。システムは NULL 許容列の各行に追加のバイトを割り当てます。これにより、クエリ時のシステム オーバーヘッドが増加します。さらに、列を NULL 可能にすると、これらの列はアクセスされるたびにチェックする必要があるため、コーディングが複雑になります。
そう考える人もいますが、NULL がトラブルの原因だと言っているわけではありません。ビジネス ルールで「NULL データ」が許可されている場合、列を NULL 可能にすることがうまく機能する場合もあると思いますが、以下のような状況で NULL 可能を使用すると問題が発生します。
顧客名1
顧客住所1
顧客メールアドレス1
顧客名2
顧客住所2
顧客メールアドレス3
顧客名1
顧客住所2
顧客メールアドレス3
この問題が発生した場合は、テーブルを正規化する必要があります。
18. TEXT データ型は使用しないようにしてください
非常に大規模なデータセットを扱う場合を除き、TEXT を使用しないでください。なぜなら、クエリは簡単ではなく、処理速度も遅く、適切に使用しないと多くのスペースを浪費してしまうからです。一般に、VARCHAR はデータをより適切に処理できます。
19. 一時テーブルは使用しないようにする
どうしても必要な場合を除き、一時テーブルは使用しないようにしてください。一般に、一時テーブルの代わりにサブクエリを使用できます。一時テーブルを使用するとシステム オーバーヘッドが発生し、COM+ でプログラミングしている場合は、多くの問題も発生します。COM+ はデータベース接続プールを使用し、一時テーブルが最初から最後まで存在するためです。 SQL Server では、テーブル データ型などの代替手段がいくつか提供されています。
20. 分析とクエリを学ぶ
SQL Server Query Analyzer は、クエリとインデックスがパフォーマンスに与える影響を理解できる親友です。
21. 参照整合性を使用する
主キー、一意制約、外部キーを定義すると、時間を大幅に節約できます。