MySQLクエリが遅い原因と解決策

クエリ速度が遅くなる理由は多数ありますが、最も一般的な理由は次のとおりです。

1. インデックスがないか、インデックスが使用されていない (これはクエリが遅くなる最も一般的な問題であり、プログラム設計上の欠陥です)
2. I/O スループットが低いため、ボトルネック効果が発生します。
3. 計算列を作成しないと、クエリが最適化されません。
4. メモリ不足
5. ネットワーク速度が遅い
6. クエリされたデータの量が多すぎる（複数のクエリやその他の方法を使用してデータ量を減らすことができます）
7. ロックまたはデッドロック（これは遅いクエリの最も一般的な問題でもあり、プログラム設計上の欠陥です）
8. sp_lock、sp_who、アクティブユーザーチェック、理由は読み取り/書き込み競合リソースです。
9. 不要な行と列が返される
10. クエリステートメントが適切ではなく、最適化されていない

クエリを最適化するには、次の操作を実行します。

1. データ、ログ、インデックスを異なる I/O デバイスに配置して、読み取り速度を上げます。以前は、Tempdb を RAID0 に配置できましたが、SQL2000 ではこれがサポートされなくなりました。データの量（サイズ）が大きくなるほど、I/O を改善することが重要になります。
2. テーブルを垂直方向と水平方向に分割してテーブルのサイズを縮小します (sp_spaceuse)
3. ハードウェアをアップグレードする
4. クエリ条件に基づいてインデックスを作成し、インデックスを最適化し、アクセス方法を最適化し、結果セット内のデータ量を制限します。フィルファクターは適切である必要があることに注意してください (デフォルト値の 0 を使用するのが最適です)。インデックスはできるだけ小さくする必要があります。インデックスを作成するには、バイト数の少ない列を使用することをお勧めします (インデックスの作成を参照)。性別フィールドなど、値の数が限られているフィールドには、単一のインデックスを作成しないでください。
5. インターネット速度を向上させる。
6. サーバーのメモリを拡張します。Windows 2000 および SQL Server 2000 は 4 ～ 8 G のメモリをサポートできます。仮想メモリを構成する: 仮想メモリのサイズは、コンピューター上で同時に実行されているサービスに基づいて構成する必要があります。 Microsoft SQL Server? 2000 を実行する場合は、仮想メモリサイズをコンピュータにインストールされている物理メモリの 1.5 倍に設定することを検討してください。さらにフルテキスト検索機能をインストールし、Microsoft Search サービスを実行してフルテキストインデックス作成とクエリを実行する予定の場合は、仮想メモリサイズをコンピューターにインストールされている物理メモリの 3 倍以上に構成することを検討してください。 SQL Server の最大サーバーメモリサーバー構成オプションを物理メモリの 1.5 倍 (仮想メモリサイズ設定の半分) に構成します。
7. サーバーの CPU の数を増やします。ただし、並列処理ではシリアル処理よりも多くのメモリなどのリソースが必要になることを理解する必要があります。 MsSQL は、並列処理を使用するかシリアル処理を使用するかを自動的に評価して選択します。単一のタスクは、プロセッサ上で実行できる複数のタスクに分割されます。たとえば、遅延クエリの並べ替え、結合、スキャン、GROUP BY 句は同時に実行されます。SQL SERVER は、システム負荷に基づいて最適な並列処理レベルを決定します。CPU を大量に消費する複雑なクエリは、並列処理に最適です。ただし、更新操作 UPDATE、INSERT、および DELETE は並列処理できません。
8. LIKE を使用してクエリを実行する場合、単純にインデックスを使用するだけでは機能せず、フルテキストインデックスによってスペースが消費されます。 like 'a%' インデックスを使用します like '%a' インデックスを使用しません like '%a%' を使用してクエリを実行する場合、クエリ時間はフィールド値の合計長に比例するため、CHAR 型は使用できず、VARCHAR が使用されます。非常に長い値を持つフィールドのフルテキストインデックスを作成します。
9. DBサーバーとアプリケーションサーバーの分離、OLTPとOLAPの分離
10. 分散パーティションビューを使用して、データベースサーバーコンプレックスを実装できます。フェデレーションとは、個別に管理されながらも連携してシステムの処理負荷を共有するサーバーのグループです。データをパーティション分割してデータベースサーバーフェデレーションを形成するこのメカニズムにより、サーバーのグループを拡張して、大規模な多層 Web サイトの処理ニーズをサポートできます。詳細については、「フェデレーテッドデータベースサーバーの設計」を参照してください。 (SQL ヘルプファイル「パーティションビュー」を参照)

a. パーティションビューを実装する前に、まずテーブルを水平にパーティション分割する必要があります。
b. メンバーテーブルを作成した後、各メンバーサーバーで分散パーティションビューを定義し、各ビューに同じ名前を付けます。したがって、分散パーティションビュー名を参照するクエリは、任意のメンバーサーバーで実行できます。システムは、各メンバーサーバーに元のテーブルのレプリカがあるかのように動作しますが、実際には、各サーバーには 1 つのメンバーテーブルと 1 つの分散パーティションビューしかありません。データの場所はアプリケーションに対して透過的です。

11. DBCC REINDEX と DBCC INDEXDEFRAG を使用してインデックスを再構築し、DBCC SHRINKDB と DBCC SHRINKFILE を使用してデータとログを縮小します。自動ログ縮小を設定します。大規模なデータベースの場合、自動データベース拡張を設定しないでください。サーバーパフォーマンスが低下します。 T-SQL を書くときに注意すべき点はたくさんあります。共通点は次のとおりです。まず、DBMS がクエリプランを処理するプロセスは次のとおりです。

1. クエリ文の語彙と文法のチェック
2. ステートメントをDBMSクエリオプティマイザに送信する
3. オプティマイザは代数最適化とアクセスパス最適化を実行する
4. プリコンパイルされたモジュールからクエリプランを生成する
5.その後、適切なタイミングで処理と実行のためにシステムに送信します。
6. 最後に、実行結果がユーザーに返されます。次に、SQL SERVER のデータストレージ構造を見てみましょう。ページのサイズは 8K (8060) バイトで、8 ページがディスク領域を形成し、B ツリーに従って格納されます。

12. コミットとロールバックの違いロールバック: すべてのトランザクションをロールバックします。コミット: 現在のトランザクションをコミットします。動的 SQL でトランザクションを記述する必要はありません。記述する必要がある場合は、begin tran exec(@s) commit trans のように外部で記述するか、動的 SQL を関数またはストアドプロシージャとして記述してください。
13. クエリの Select ステートメントで Where 句を使用して、返される行数を制限し、テーブルスキャンを回避します。不要なデータが返されると、サーバーの I/O リソースが無駄になり、ネットワークの負荷が増加し、パフォーマンスが低下します。テーブルが非常に大きい場合、テーブルスキャン中にテーブルをロックすると、他の接続がテーブルにアクセスできなくなるため、深刻な結果を招く可能性があります。
14. SQLコメントは実行には影響しない
15. カーソルは多くのリソースを消費するため、できるだけ使用しないでください。行ごとの実行が必要な場合は、クライアントでのループ、一時テーブルの使用、テーブル変数、サブクエリ、Case ステートメントなどのカーソル以外の手法を使用してみてください。カーソルは、サポートするフェッチオプションに応じて分類できます。最初の行から最後の行まで、行のみを順番にフェッチする必要があります。 FETCH NEXT は唯一許可されるフェッチ操作であり、デフォルトです。スクロール機能により、カーソル内の任意の場所から任意の行を取得できます。カーソルテクノロジは SQL2000 で非常に強力になり、その目的はループをサポートすることです。同時実行オプションには 4 つあります。READ_ONLY: カーソルの配置 (Update) による更新は許可されず、結果セットを構成する行はロックされません。値を持つ楽観的: 楽観的同時実行制御は、トランザクション制御理論の標準的な部分です。楽観的同時実行制御は、カーソルを開いてから行を更新するまでの間に 2 番目のユーザーが行を更新する可能性がわずかしかない状況で使用されます。このオプションを使用してカーソルを開くと、その行にロックが保持されないため、処理能力が最大限に発揮されます。ユーザーが行を変更しようとすると、行の現在の値が、その行が最後にフェッチされたときに取得された値と比較されます。いずれかの値が変更されると、サーバーは他のユーザーがこの行を更新したことを認識し、エラーを返します。値が同じであれば、サーバーは変更を実行します。次の同時実行オプションを選択します: 行バージョン管理に基づくオプティミスティック同時実行制御オプション。このオプティミスティック同時実行制御オプションは、行バージョン管理に基づいています。行のバージョン管理では、カーソルに読み込まれてから行が変更されたかどうかをサーバーが判断するために使用できる何らかのバージョン識別子がテーブルに必要です。 SQL Server では、この機能は、データベース内の変更の相対的な順序を表すバイナリ数値であるタイムスタンプデータ型によって提供されます。各データベースには、グローバルな現在のタイムスタンプ値 @@DBTS があります。タイムスタンプ列を持つ行が何らかの方法で変更されるたびに、SQL Server はまず現在の @@DBTS 値をタイムスタンプ列に格納し、次に @@DBTS の値を増やします。テーブルにタイムスタンプ列がある場合、タイムスタンプは行レベルで記録されます。その後、サーバーは行の現在のタイムスタンプ値と、最後にフェッチされたときに保存されたタイムスタンプ値を比較して、行が更新されたかどうかを判断できます。サーバーはすべての列の値を比較する必要はなく、タイムスタンプ列の値のみを比較します。アプリケーションにタイムスタンプ列テーブルがなく、行のバージョン管理に基づく楽観的同時実行性が必要な場合、カーソルはデフォルトで数値に基づく楽観的同時実行性制御になります。スクロールロックこのオプションは悲観的同時実行制御を実装します。悲観的同時実行制御では、アプリケーションはカーソル結果セットにデータベース行を読み取っている間に、その行をロックしようとします。サーバーカーソルを使用する場合、カーソルに読み込まれる行に更新ロックが設定されます。トランザクション内でカーソルが開かれると、トランザクションがコミットまたはロールバックされるまでトランザクション更新ロックが保持され、次の行がフェッチされるとカーソルロックが解除されます。カーソルがトランザクション外で開かれた場合、次の行がフェッチされるときにロックは解除されます。したがって、ユーザーが完全な悲観的同時実行制御を必要とする場合は、カーソルをトランザクション内で開く必要があります。更新ロックは、他のタスクが更新ロックまたは排他ロックを取得できないようにし、他のタスクが行を更新できないようにします。ただし、更新ロックは共有ロックをブロックしないため、2 番目のタスクも更新ロックを使用して読み取りを要求していない限り、別のタスクによる行の読み取りを妨げることはありません。スクロールロックこれらのカーソル同時実行オプションは、カーソル定義の SELECT ステートメントで指定されたロックヒントに基づいてスクロールロックを生成できます。スクロールロックは、各行がフェッチされるたびに取得され、次のフェッチが行われるか、カーソルが閉じられるまで (いずれか早い方) 保持されます。次のフェッチでは、サーバーは新しいフェッチの行のスクロールロックを取得し、前のフェッチの行のスクロールロックを解除します。スクロールロックはトランザクションロックとは独立しており、コミットまたはロールバック操作後に保持できます。コミット時にカーソルを閉じるオプションがオフの場合、COMMIT ステートメントは開いているカーソルを閉じず、フェッチされたデータの分離を維持するために、コミット後までスクロールロックが保持されます。取得されるスクロールロックの種類は、カーソルの同時実行オプションとカーソル SELECT ステートメントのロックヒントによって異なります。ロックヒント読み取り専用楽観的数値楽観的行バージョン管理ロックヒントなしロック解除ロック解除ロック解除更新 NOLOCK ロック解除ロック解除ロック解除ロック解除ロック解除 HOLDLOCK 共有共有共有更新 UPDLOCK エラー更新更新更新 TABLOCKX エラーロック解除ロック解除更新その他ロック解除ロック解除ロック解除更新 *NOLOCK ヒントを指定すると、ヒントが指定されたテーブルがカーソル内で読み取り専用になります。
16. プロファイラを使用してクエリを追跡し、クエリに必要な時間を取得し、SQLの問題を見つけます。インデックスオプティマイザを使用してインデックスを最適化します。
17. UNion と UNion all の違いに注意してください。 UNION すべては良い
18. DISTINCT を使用するときは注意してください。必要がない場合は使用しないでください。UNION と同様に、クエリの速度が低下します。クエリでは重複レコードは問題にならない
19. クエリ時に不要な行や列を返さない
20. クエリによって消費されるリソースを制限するには、sp_configure 'query Governor cost limit' または SET QUERY_GOVERNOR_COST_LIMIT を使用します。クエリの評価によって消費されるリソースが制限を超えると、サーバーはクエリを自動的にキャンセルし、実行前に強制終了します。 SET LOCKTIMEはロック時間を設定します
21. select top 100 / 10 Percent を使用して、ユーザーによって返される行数を制限するか、SET ROWCOUNT を使用して操作の行数を制限します。
22. SQL2000 より前では、通常、次のステートメントは使用しないでください: 「IS NULL」、「<>」、「!="」、「!>」、「!<」、「NOT」、「NOT EXISTS」、「NOT IN」、「NOT LIKE」、および「LIKE '%500'」。これらはインデックスを使用せず、すべてテーブルスキャンであるためです。また、WHere 句の列名に Convert、Substring などの関数を追加しないでください。関数を使用する必要がある場合は、代わりに計算列を作成してからインデックスを作成してください。記述方法を変更することもできます。WHERE SUBSTRING(firstname,1,1) = 'm' を WHERE firstname like 'm%' (インデックススキャン) に変更します。関数と列名は必ず分離してください。また、インデックスを作成しすぎたり、インデックスを大きくしすぎたりしないでください。 NOT IN はテーブルを複数回スキャンします。代わりに、EXISTS、NOT EXISTS、IN、LEFT OUTER JOIN (特に左結合) を使用してください。EXIST は IN よりも高速で、最も遅いのは NOT 操作です。列の値に null が含まれている場合、以前はそのインデックスは機能しませんでしたが、2000 オプティマイザーではこれを処理できるようになりました。同様に、IS NULL、"NOT"、"NOT EXISTS"、"NOT IN" は最適化できますが、"<>" などは最適化できず、インデックスは使用されません。
23. クエリアナライザーを使用して、SQL ステートメントのクエリプランを表示し、最適化された SQL であるかどうかを評価します。一般的に、コードの 20% がリソースの 80% を占めており、私たちの最適化はこれらの遅い領域に重点を置いています。
24. IN または OR を使用するときにクエリがインデックスを使用しない場合は、明示的な宣言を使用してインデックスを指定します。
SELECT * FROM PersonMember (INDEX = IX_Title) WHERE processid IN ('male', 'female')
25. クエリする結果を事前に計算してテーブルに格納し、クエリ時にそれらを選択します。これはSQL7.0以前は最も重要な手段でした。例えば入院費の計算など。
26. MIN() と MAX() は適切なインデックスを使用できます。
27. データベースには、コードがデータに近いほど良いという原則があります。したがって、デフォルトが優先され、次にルール、トリガー、制約（外部キー、主キー、CheckUNIQUEなどの制約、データ型の最大長などはすべて制約です）、手順の順になります。これにより、メンテナンス作業が軽減されるだけでなく、プログラム作成の品質が向上し、実行が速くなります。
28. 大きなバイナリ値を Image 列に挿入する場合は、ストアドプロシージャを使用し、組み込みの INsert を使用して挿入しないでください (JAVA がこれを実行するかどうかはわかりません)。アプリケーションは最初にバイナリ値を文字列 (サイズが 2 倍) に変換し、サーバーは文字を受け取った後にそれをバイナリ値に戻します。ストアドプロシージャには次のアクションはありません: メソッド:
テーブル(Fimage)の値 (@image) への挿入としてプロシージャ p_insert を作成します。
このストアドプロシージャをフォアグラウンドで呼び出し、バイナリパラメーターを渡すと、処理速度が大幅に向上します。
29.場合によっては、Between は IN よりも高速です。Between はインデックスに基づいて範囲をより速く見つけることができます。クエリオプティマイザーを使用すると違いを確認できます。

タイトルが ('男性','女性') である chineseresume から * を選択します 
タイトルが「男」と「女」の間にある chineseresume から * を選択してください

同じです。何度も呼び出されるため、遅くなる場合があります。
30. 必要に応じて、グローバルまたはローカルの一時テーブルにインデックスを作成します。これにより速度が向上する場合がありますが、インデックスも多くのリソースを消費するため、必ずしもそうとは限りません。作成方法は実際のテーブルと同じです。
31. レポートの生成など、リソースを浪費する無駄なものを作成しないでください。物を使う必要があるときだけ使用してください。
32. OR 句は複数のクエリに分解でき、複数のクエリは UNION を通じて接続できます。速度はインデックスが使用されているかどうかにのみ関係します。クエリで結合インデックスを使用する必要がある場合は、UNION all を使用する方が効率的です。複数の OR 句はインデックスを使用しないため、UNION の形式で書き換えられ、インデックスとの一致が試みられます。重要な問題は、インデックスを使用するかどうかです。
33. ビューは非効率的なので、できるだけ使用しないでください。ビューに対する操作はテーブルに対する直接操作よりも遅いため、代わりにストアドプロシージャを使用できます。特に、ビューをネストしないでください。ネストされたビューでは元のデータを見つけるのが難しくなります。ビューの本質を見てみましょう。ビューは、サーバー上で生成され保存されるクエリプランを含む最適化された SQL ステートメントです。単一のテーブルからデータを取得する場合、複数のテーブルを指すビューを使用しないでください。テーブルから直接取得するか、このテーブルのみを含むビューから読み取ります。そうしないと、不要なオーバーヘッドが追加され、クエリが妨げられます。ビューのクエリを高速化するために、MsSQL ではビューインデックス機能が追加されました。
34. 必要がない場合は、DISTINCT と ORDER BY を使用しないでください。これらのアクションは、代わりにクライアント側で実行できます。余分なオーバーヘッドが追加されます。これは UNION および UNION ALL と同じ原理です。

上位 20 件を選択 ad.companyname、comid、position、ad.referenceid、worklocation、 
convert(varchar(10),ad.postDate,120) を postDate1,workyear,degreedescription として変換します。 
jobcn_query.dbo.COMPANYAD_query ad where referenceID in('JCNAD00329667','JCNAD132168','JCNAD00337748','JCNAD00338345', 
'JCNAD00333138'、'JCNAD00303570'、'JCNAD00303569'、 
'JCNAD00303568'、'JCNAD00306698'、'JCNAD00231935'、'JCNAD00231933'、 
'JCNAD00254567'、'JCNAD00254585'、'JCNAD00254608'、 
'JCNAD00254607'、'JCNAD00258524'、'JCNAD00332133'、'JCNAD00268618'、 
'JCNAD00279196'、'JCNAD00268613'）投稿日降順で並び替え

35. IN以降の値のリストでは、最も頻繁に出現する値を先頭に、最も頻繁に出現しない値を最後尾に配置して、判断回数を減らします。
36. SELECT INTO を使用すると、システムテーブル (sysobjects、sysindexes など) がロックされ、他の接続によるアクセスがブロックされます。明示的なステートメントを使用して一時テーブルを作成する代わりに、

INTOを選択します。テーブルt_lxhを削除します。トランザクションを開始します。select * into t_lxh from chineseresume 
名前 = 'XYZ' --commit

別の接続である SELECT * from sysobjects では、SELECT INTO によってシステムテーブルがロックされ、Create table によってもシステムテーブル (一時テーブルかシステムテーブルかに関係なく) がロックされることがわかります。したがって、内部では絶対に使用しないでください。！！この場合、頻繁に使用する一時テーブルであれば、実テーブルまたは一時テーブル変数を使用してください。
37. 一般的に、冗長な行は GROUP BY 句や HAVING 句の前に削除できるため、行を削除するためにこれらを使用しないようにしてください。最適な実行順序は次のとおりです。select の Where 句は適切な行をすべて選択し、Group By を使用して行をグループ化してカウントし、Having 句を使用して冗長なグループを削除します。この方法では、Group By と Having のオーバーヘッドは小さく、クエリは高速です。大きなデータ行の Grouping と Having は多くのリソースを消費します。 Group BY の目的が計算ではなくグループ化のみである場合は、Distinct の方が高速です。
38. 一度に複数のレコードを更新する方が、一度に 1 つのレコードを更新するよりも高速です。つまり、バッチ処理の方が適しています。
39. 一時テーブルの使用頻度を減らします。代わりに結果セットとテーブル型変数を使用するようにします。一時テーブルよりもテーブル型変数の方が適しています。
40. SQL2000 では、計算フィールドにインデックスを設定できます。満たす必要がある条件は次のとおりです。

a. 計算フィールドの表現は一定である
b. TEXT、Ntext、Imageデータ型では使用できません
c. 次のオプションを設定する必要があります: ANSI_NULLS = ON、ANSI_PADDINGS = ON、...

41. ストアドプロシージャを使用するなどして、データ処理をサーバー上に配置して、ネットワークのオーバーヘッドを削減します。ストアドプロシージャは、コンパイルされ、最適化された SQL ステートメントを実行プランに編成してデータベースに保存します。これは制御フロー言語の集合であり、もちろん高速です。繰り返し実行される動的 SQL では、Tempdb に配置される一時ストアドプロシージャ (一時テーブル) を使用できます。以前は、SQL Server は複雑な数学的計算をサポートしていなかったため、この作業を他のレイヤーに配置する必要があり、ネットワークのオーバーヘッドが増加していました。 SQL2000 は UDF をサポートし、複雑な数学的計算もサポートするようになりました。関数の戻り値は大きすぎると大きなオーバーヘッドが発生するため、大きすぎる値にしないでください。ユーザー定義関数は、カーソルのように実行されると大量のリソースを消費します。大きな結果を返す場合は、ストアドプロシージャを使用します。
42. 文中で同じ関数を繰り返し使用しないでください。リソースを無駄にします。結果を変数に入れて呼び出す方が高速です。
43. SELECT COUNT(*) の効率が低いので、書き方を変えてみましょう。EXISTS の方が高速です。また、select count(Field of null) from Table と select count(Field of NOT null) from Table の戻り値が異なりますので注意してください。！！
44. サーバーに十分なメモリがある場合は、スレッド数を最大接続数 + 5 に設定すると、最大の効率が得られます。そうでない場合は、スレッド数 < 最大接続数を使用して、SQL SERVER のスレッドプールを有効にして問題を解決します。数が依然として最大接続数 + 5 に等しい場合、サーバーのパフォーマンスが著しく低下します。
45. 特定の順序でテーブルにアクセスします。最初にテーブル A をロックし、次にテーブル B をロックする場合、すべてのストアドプロシージャでこの順序でロックする必要があります。ストアドプロシージャで最初にテーブル B を (誤って) ロックし、次にテーブル A をロックすると、デッドロックが発生する可能性があります。ロックシーケンスが事前に慎重に設計されていない場合、デッドロックを検出するのは困難です。
46. SQL Server パフォーマンスモニターを使用して、対応するハードウェアの負荷を監視します。Memory: Page Faults/sec カウンターの値が時々高くなる場合は、その時点でメモリを競合するスレッドがあることを示しています。常に高い場合は、メモリがボトルネックになっている可能性があります。

プロセス：
1. % DPC 時間は、サンプル間隔中に遅延プロシージャ呼び出し (DPC) を受信して処理するために使用されるプロセッサの割合を示します。 (DPC は標準間隔よりも低い優先度間隔で実行されています)。 DPC は特権モードで実行されるため、DPC の割合は特権の割合の一部になります。これらの時間は個別に計算され、間隔計算の合計には含まれません。この合計は、インスタンス時間に対する平均ビジー時間のパーセンテージとして表示されます。
2. %Processor Time カウンターパラメータ値が 95% を超え続ける場合、ボトルネックは CPU であることを示します。新しいプロセッサを追加するか、より高速なプロセッサに切り替えることを検討してください。
3. % 特権時間は、特権モードで使用された非アイドルプロセッサ時間の割合を示します。 (特権モードは、オペレーティングシステムコンポーネントとハードウェアドライバーの操作用に設計された処理モードです。ハードウェアとすべてのメモリに直接アクセスできます。もう 1 つのモードはユーザーモードです。これは、アプリケーション、環境サブシステム、および整数サブシステム用に設計された制限された処理モードです。オペレーティングシステムは、アプリケーションスレッドを特権モードに変換して、オペレーティングシステムサービスにアクセスします)。特権時間の割合には、割り込みと DPC を処理する時間が含まれます。特権時間比率が高くなる原因としては、障害が発生したデバイスによって生成される間隔の数が多いことが考えられます。このカウンターは、サンプル時間の割合として平均ビジー時間を表示します。
4. % ユーザー時間は、並べ替え、集計関数の実行など、CPU を消費するデータベース操作を示します。この値が非常に高い場合は、インデックスの追加、単純なテーブル結合の使用、大きなテーブルの水平分割などの方法を使用して、この値を下げることを検討してください。物理ディスク: 現在のディスクキューの長さカウンターこの値は、ディスク数の 1.5 ~ 2 倍を超えてはなりません。パフォーマンスを向上させるには、ディスクを追加します。 SQLServer: キャッシュヒット率カウンター値が高いほど、良好です。常に 80% を下回る場合は、メモリを増やすことを検討してください。パラメータ値は SQL Server の起動後に蓄積されるため、一定時間が経過すると、その値はシステムの現在の値を反映しなくなることに注意してください。

47. select emp_name form employee where salary > 3000 の分析このステートメントでは、salary が Float 型の場合、オプティマイザーはそれを Convert(float,3000) に最適化します。3000 は整数なので、実行時に DBMS に変換を実行させるのではなく、プログラミング時に 3000.0 を使用する必要があります。文字データと整数データに対しても同様の変換が行われます。
48. クエリの関連付けと書き込みの順序

a.personMemberIDを選択します。* chineseresume a、personmember bから personMemberIDを選択します。
= b.referenceid および a.personMemberID = 'JCNPRH39681' (A = B、B = 'number')

a.personMemberIDを選択します。* chineseresume a、personmember bからa.personMemberIDを選択します。
= b.referenceid および a.personMemberID = 'JCNPRH39681' および b.referenceid = 'JCNPRH39681' (A = B、B = 'number'、A = 'number')

a.personMemberID、* を chineseresume a、personmember b から選択します。b.referenceid を指定します。
= 'JCNPRH39681' および a.personMemberID = 'JCNPRH39681' (B = '番号'、A = '番号')

49.

(1) 担当者コードが入力されていない場合は、code1=0、code2=9999、else code1=code2=担当者コード、END IF 実行されるSQL文は、SELECT 担当者名 FROM P2000 WHERE 担当者コード>=:code1 AND 担当者コード<=:code2です。
(2) 担当者コードが入力されていない場合は、SELECT 担当者名 FROM P2000 ELSE code=担当者コード SELECT 担当者コード FROM P2000 WHERE 担当者コード=:code END IF 最初の方法では、SQL 文を 1 つだけ使用し、2 番目の方法では、SQL 文を 2 つ使用します。責任者コードが入力されていない場合、2 番目の方法は制限がないため、明らかに最初の方法よりも効率的です。責任者コードが入力されている場合は、制限が 1 つ少ないだけでなく、等価演算が最も高速なクエリ演算であるため、2 番目の方法は最初の方法よりも効率的です。プログラムを書くときにトラブルを恐れてはいけない

50. JOBCN の新しいクエリページング方法 (次のとおり) については、パフォーマンスオプティマイザーを使用してパフォーマンスのボトルネックを分析します。I/O またはネットワーク速度にボトルネックがある場合は、次の最適化方法が有効です。CPU またはメモリにボトルネックがある場合は、現在の方法の方が適しています。以下の方法を区別し、指数が小さいほど良いことを説明してください。

始める 
DECLARE @local_variable テーブル (FID int identity(1,1),ReferenceID varchar(20)) 
@local_variable (参照ID) に挿入 
chineseresume から ReferenceID の上位 100000 件を選択します。ReferenceID で並べ替えます。 
Fid > 40 かつ fid <= 60 の場合、@local_variable から * を選択します。 
終わり

そして

始める 
DECLARE @local_variable テーブル (FID int identity(1,1),ReferenceID varchar(20)) 
@local_variable (参照ID) に挿入 
chineseresume から上位 100000 の ReferenceID を更新日順に選択 
Fid > 40 かつ fid <= 60 の場合、@local_variable から * を選択します。 
終わり

違い

始める 
テーブル #temp を作成します (FID int identity(1,1),ReferenceID varchar(20)) 
#temp (参照ID) に挿入 
chineseresume から上位 100000 の ReferenceID を更新日順に選択 
Fid > 40 かつ fid <= 60 の場合、#temp から * を選択し、#temp テーブルを削除します。 
終わり

遅いMySQLクエリ速度の分析と解決

1. 2 秒以内に完了しないような、実行が遅い SQL ステートメントを見つけます。

エンジンを表示します。
遅いクエリ時間を表示する
「slow%」のような変数を表示します。
遅いクエリになるまでにどれくらい時間がかかるか確認する
'long%' のような変数を表示します。
遅いクエリ時間を修正する
long_query_timeを1に設定します。
低速クエリのログ記録を有効にする
グローバル slow_query_log を 'ON' に設定します。
実行中のスレッドを確認する
完全なプロセスリストを表示
最大接続数を表示する
'%max_connections%' のような変数を表示します。
現在の接続数
「Threads_connected%」のようなステータスを表示します。