データベースの性能最適化三：プログラム操作の最適化、性能向上

データベース最適化には以下の3つの部分が含まれています。データベース自体の最適化、データベーステーブル最適化、プログラム操作最適化。この文は第三部分です。 概説：プログラムアクセス最適化はSQL文にアクセスする最適化とも考えられます。良いSQL文は非常に多くのプログラム性能を低減することができます。以下に、常用エラー習慣を示します。そして、対応するソリューションを提出します。ただし、ビッグデータ量の表ではINの代わりにEXISTSがオススメです。Not INがインデックスから離れないのは絶対に使えません。2.IS NULLまたはIS NOT NULLの代わりにNOT EXISTSを使ってインデックスを操作してもいいです。このような操作はインデックスを使用することができません。他の方法で処理できます。例えば、数字タイプ、判定は0より大きく、文字列タイプはデフォルト値を設定します。標準値に等しいかどうかを判断すればいいです。3.<>操作子（等しくない）は操作子に等しくないとインデックスは永遠に使用されません。したがって、その処理は全表スキャンのみが発生します。他の同じ機能の操作で演算します。a<>0をa>0 or a<0 a>''をa''に変更します。4.全文検索でテキストデータを検索します。like検索の代わりに全文検索はlike検索よりずっと優れています。他の単語やフレーズに近い単語やフレーズを検索したり、類義語を検索したりします。2）全文検索はlike検索より簡単（特に複雑な検索）を実現する。第二に、SQL文の最適化1、調査でselect*を使わないでください。なぜ使えないのか、地球人は知っていますが、多くの人がこのように使うのに慣れています。このようにデータベースを検索しても「インデックスをカバー」は使えません。2.できるだけWHERE子文を書いてはいけません。WHEREがないSQL文を書かないようにしてください。3.SELECT INTO後のWHERE子文はSELECT INTOのためにデータを臨時表に挿入します。この過程はシステムテーブルをロックします。このWHERE子文が返したデータが多すぎたり、速度が遅すぎたりすると、システムテーブルが長期的にロックされます。諸塞の他のプロセス。4.統合クエリについては、返信された行をHAVING文でさらに限定することができます。臨時表（1）を使用しても必要がない限り、臨時表を使用しないようにします。2）大部分の場合（99%）は、テーブル変数がメモリに常駐しているため、速度は一時テーブルより速く、臨時テーブルがTempDbデータベースに常駐しているため、臨時テーブルの操作はデータベースをまたいで通信する必要があり、速度は自然に遅い。6.データベースにアクセスする回数を減らす：プログラム設計では、よく使われている大域変数表をメモリに入れたり、他の方法でデータベースへのアクセス数を減らしたりするのがベストです。重複した作業をできるだけ少なくして、無効な作業をできるだけ減らすようにします。ただし、この点はクライアントプログラムに重点を置いて、以下のように注意してください。特に、いくつかの基礎データの多重実行は、多くのプログラマがあまり注意していないBであり、複数のデータ変換を減らすためには、データ変換が必要であるかもしれないが、減少回数はプログラマができる。C、不必要なサブクエリと接続テーブルを根絶し、サブクエリは実行計画で一般的に外部接続と解釈され、余分な接続テーブルは追加のオーバーヘッドをもたらす。D、統合は同じ表の同じ条件に対して、UPDATE EMPLOYE SET FNAME='HAIWER'WHERE EMP_ID='VPA 30890 F'UPDATEMPLOYE SET LNAME='YANG'WHERE EMP_ID='VPA 30890 F'は、次の文に統合されるべきです。UPDATE EMPLOYE SET FNAME='HAIWER'は、LNAME='YANG'WHERE EMP_ID='VPA 30890 F'E、UPDATE操作はDELETE操作+INSERT操作の形式に分解しないでください。機能は同じですが、性能の違いは大きいです。F、SELECT*FROM EMPLOYE WHERE 1=2三、where使用原則1）以下の2つのselect文の中で、select*from table 1 where field 1<=10000 and field 1>=0；select*from table 1 where field 1==0 and field 1<=10000；データテーブルのデータfield 1都>=0の場合、第一条select文は第二条select文よりも効率的に多くなります。第二条select文の第一条件は多くのシステムリソースを消費します。第一の原則：where子文の中で最も制限的な条件を一番前に置くべきです。2）次のselect文の中で：select*from tab where a=...and b=...and c=…；インデックスindex(a，b，c)がある場合、whereサブルーチンのフィールドの順序はインデックス内のフィールドの順序と一致しています。第二の原則：where子文のフィールドの順序は索引のフィールドの順序と一致しています。以下の仮定では、field 1に一意のインデックスI 1があり、field 2に一意でないインデックスI 2がある。3）select field 3，field 4 from tb where field 1='sdf'快select*from tb where field 1='sdf'は遅いです。後者は索引スキャン後、ROWIDテーブルにアクセスする必要があります。select field 3，field 4 from tb where field 1>='sdf'速いselect field 3，field 4 from tb where field 1''sdf'は前者のためにインデックスを迅速に位置決めすることができます。select field 3，field 4 from tb where field 2 like'R'は、インデックスを使用しないので、field 4 from tb where field 2 like'%R'は遅いです。4）使用関数：select field 3、field 4 from tb where uper（field 2）='RMN'はインデックスを使用しません。もし一つの表に二万本の記録があるなら、関数を使わないことを勧めます。一つの表に5万以上の記録があると、関数の使用は厳しく禁じられます。二万本の記録以下には制限がない。