どのようにMYSQLデータベースのクエリ統計速度を向上させますか？

データベースシステムは情報システムを管理する中核であり、データベースに基づくオンライン事務処理（OLT P）及びオンライン分析処理（OLPP）は銀行、企業、政府などの部門で最も重要なコンピュータアプリケーションの一つである。ほとんどのシステムの応用例から見て、照会動作は様々なデータベース操作において占有される比重が最も大きく、クエリ動作に基づいたSELECT文はSQL文においてまた最大の値を持つ文である。例えば、データの量が一定の程度まで蓄積されると、例えば銀行の口座データベーステーブル情報が百万件以上の記録に蓄積され、全表スキャンはしばしば数十分、あるいは数時間がかかります。全表スキャンより良いクエリポリシーを採用すれば、クエリ時間を数分に減らすことができます。したがって、最適化技術の重要性を確認します。筆者はアプリケーションプロジェクトの実施において、多くのプログラマがいくつかのフロントエンドデータベース開発ツール（PowerBuider、Delphiなど）を利用してデータベースアプリケーションを開発する時、ユーザーインターフェースの華麗さだけを重視します。検索文の効率を重視しないため、開発されたアプリケーションの効率が低下し、資源の浪費が深刻です。そのため、効率的で合理的なクエリ文の設計は非常に重要です。本論文は応用例を基礎として、データベース理論を結合して、クエリ最適化技術の現実的なシステムでの運用を紹介します。分析問題の多くのプログラマは、クエリ最適化はDBMS（データベース管理システム）のタスクであり、プログラマが作成したSQL文とは関係がないと考えています。これは間違いです。良い照会プランは、プログラムの性能を数十倍に高めることができます。クエリプランは、ユーザが提示したSQL文の集合であり、クエリプランは、最適化された処理を経て生成されたステートメントのセットである。DBMS処理照会計画のプロセスは、照会文の語法、文法検査を終えた後、文をDBMSの照会最適化器に提出し、最適化した代数最適化とアクセス経路の最適化を最適化した後、プリコンパイルモジュールによって文を処理し、アンケート計画を作成し、適切な時間にシステム処理実行に提出し、最後に実行結果をユーザーに返します。実際のデータベース製品（Oracle、Syboaseなど）の高いバージョンでは、価格に基づく最適化方法が採用されています。この最適化は、システム辞書から得られた情報に基づいて、異なるクエリ計画の価格を推定し、より優れた計画を選択することができます。現在のデータベース製品はクエリの最適化においてますますよくなってきましたが、ユーザーによって提出されたSQL文はシステム最適化の基礎であり、元々の悪い照会計画がシステムの最適化を経て効率的になるとは考えにくいです。システムが行っているクエリの最適化については、しばらく検討しません。以下のポイントはユーザー照会計画を改善する解決策を説明します。問題を解決するには、関係データベースシステムInformixを例にとって、ユーザーの照会計画を改善する方法を紹介します。1.インデックスを合理的に使用することはデータベースにおける重要なデータ構造であり、その根本的な目的は照会効率を高めることである。現在ほとんどのデータベース製品はIBMが最初に提案したISAMインデックス構造を採用しています。インデックスの使用は適切であり、その使用原則は以下の通りである。●常に接続されているが、外部キーとして指定されていない列にインデックスが作成され、頻繁に接続されていないフィールドは、最適化器によって自動的にインデックスが生成される。●頻繁に並べ替えやグループ化（グループ化）する byまたはorder by操作）の列にインデックスを作成します。●条件式でよく使われる異なる値の多い列で検索を行い、異なる値の少ない列でインデックスを作成しないでください。例えば、従業員表の「性別」には「男」と「女」の二つの異なる値しかないので、インデックスを作る必要はありません。インデックスを作成すると、検索効率が向上するだけでなく、更新速度が大幅に低下します。●並べ替え対象の列が複数あれば、これらの列にコンポジットを作成することができます。 index)●システムツールを使う。Informixデータベースにtbcheckツールがあると、不審なインデックスでチェックできます。いくつかのデータベースサーバでは、インデックスが失効したり、頻繁に操作されて読み取り効率が低下したりします。インデックスを使ったクエリーが不明瞭に遅くなったら、tbcheckツールでインデックスの完全性をチェックしてみてもいいです。必要な時に修復します。また、データベーステーブルが大量のデータを更新すると、インデックスを削除して再構築することができます。2.回避または簡略化された順序付けは、大規模な表の重複した順序付けを簡略化または回避しなければならない。インデックスを利用して、適切な順序で出力を自動的に生成することができる場合、最適化器は、順序付けのステップを回避する。以下はいくつかの影響要因です。●索引には1つまたは複数の並べ替え対象の列が含まれていません。●グループ byまたはorder by子文の中の列の順序は索引の順序と違います。●並べ替えの列は、異なるテーブルから来ます。不必要な順序を避けるためには、インデックスを正確に増築し、データベーステーブルを合理的に統合する必要がある（場合によってはテーブルの規範化に影響するが、効率の向上に対しては価値がある）。順序付けが不可避である場合は、順序付けの列の範囲を狭めるなどの簡略化を図るべきである。3.大型行データへの順番アクセスを削除します。ネストクエリでは、テーブルへの順番アクセスがクエリ効率に致命的な影響を与える可能性があります。例えばシーケンスアクセスポリシーを採用して、3階建てのクエリを入れ子にして、各階ごとに1000行調べたら、このクエリは10億行のデータを調べます。このようなことを避ける主な方法は、接続された列をインデックスすることです。例えば、二つの表：学生表（学名、氏名、年齢…）と選択授業（学名、課程番号、成績）。二つの表を接続するには、「学号」という連結フィールドにインデックスを作成します。順序的なアクセスを回避するために、統合を使用することもできる。すべてのチェックリストにインデックスがありますが、いくつかの形式のwhereサブ句は順序的にアクセスするように強制されます。以下のクエリは、ordersテーブルの順序操作を強制されます：SELECT ＊ FROM orders WHERE (customer_num=104 AND order.num>1001） OR order.num=1008はcustomer_ですがnumとorder_numにはインデックスが構築されていますが、上の文では優先度アクセスパスを使って表全体をスキャンします。この文は分離された行の集合を検索しますので、次のような文に変えます。 ＊ FROM orders WHERE customer_num=104 AND order.num>1001ユニオンSELECT ＊ FROM orders WHERE order.num=1008はインデックスパスを利用してクエリーを処理することができます。4.関連するサブクエリーの1つの列のタグが同時にプライマリクエリとwhereサブフレーズのクエリに現れることを避けると、メインクエリの列の値が変更された後、サブクエリは再検索される可能性が高い。クエリのネストレベルが多ければ多いほど、効率が低いので、できるだけサブクエリを避けるべきです。子供の検索が避けられないなら、できるだけ多くの行をサブクエリーでフィルタします。5.困難を避ける正規表現MATCHESとLIKEキーワードはワイルドカードマッチングをサポートし、技術的には正規表現と呼ばれています。しかし、このマッチングは特に時間がかかります。例えば：SELECT ＊ FROM customer WHERE zipcode LIKE “98_ _ _” zipcodeフィールド上にインデックスが確立されていても、この場合は逐次スキャンを採用します。文をSELECTに変えたら ＊ FROM customer WHERE zipcode >“98000」は、クエリーを実行する時にインデックスを使って検索します。明らかに速度が大きくなります。また、非最初の串は避けなければなりません。例えば文：SELECT ＊ FROM customer WHERE zipcode[2,3]>「80」は、where子文に非開始部分列を採用していますので、この文はインデックスを使用しません。6.臨時テーブルで加速クエリを使用して表のサブセットを並べ替えて仮テーブルを作成し、時には検索を加速することができます。多重秩序化動作を回避し、他の面でも最適化器の動作を簡略化するのに役立つ。例えば：SELECT cust.name，rvbles.balance，…other columns FROM cust，rcvbles WHERE cust.customerid。 = rvlbes.customer_id AND rvblls.balance>0 AND cust.postcode>「98000」ORDER BY。 cust.nameはもしこのクエリが何度も実行されるならば、一回だけではなくて、すべての未払いの取引先を探し出して1つの臨時のファイルの中に置くことができて、そして取引先の名前によって並べ替えます：SELECT cust.name，rvbles.balance，…other columns FROM cust，rcvbles WHERE cust.customerid。 = rvlbes.customer_id AND rvblls.balance>0 ORDER BY。 cust.name INTO TEMP cust_with_balanceは次のように臨時表で調べます。 ＊ FROM cust_with_balance WHERE postcode>「98000」仮テーブルの行はメインテーブルの行よりも少なく、物理的な順序が要求されているため、ディスクI/Oが減少しています。注意：一時テーブルを作成しても、メインテーブルの変更は反映されません。メインテーブルでデータが頻繁に修正されている場合、データが失われないように注意してください。7.順番以外のアクセスディスクの代わりに並べ替えをするのは、ディスクのアクセスアームの往復移動を示す最も遅い動作です。SQL文はこの状況を隠しています。アプリケーションを書く時、大量の非順序ページにアクセスすることを要求するクエリを簡単に書き出すことができます。いくつかの場合、データベースの順序付け能力で非順序のアクセスを置き換えることで、クエリを改善することができます。