行うにはMySQLの最適化は、我々は、EXPLAINビューのSQLの実行計画を十分に活用する必要があります。
私たちは、データに集中したいラベル（1,2,3,4,5）、のに簡単な例をみましょう
-
コラム、接続の種類を入力します。範囲レベルを達成するために、少なくとも1つの良いSQL文。すべてのレベルの出現を防ぎます
-
キー列は、インデックスの名前を使用します。あなたは、インデックスを選択しない場合、値はNULLです。インデックスは、執行側がかかる場合があります
-
key_lenに列インデックスの長さ
-
行列、走査線の数。この値は推定値であります
-
余分な列の詳細。共通の価値観は非常に友好的ではないことに注意してください：filesortレコードを使用して、一時的に使用します
第二に、SQL文の中に含まれる値は、IN過負荷にするべきではありません
MySQLは、対応する最適化されたINしたため、全てにおいて今後定数の内部配列に格納され、アレイがソートされます。値が多い場合には、比較的大きい生成消費します。別の例は：連続値について（1,2,3）でここでNUM TからIDを選択し、間に使用することができない。置換するために使用または再接続します。
三、SELECTステートメントは、フィールドの名前を指定することが確実です
SELECT *不要な消費（CPU、IO、メモリ、ネットワーク帯域）の数を増やし、テーブル構造の変更は、破断前に更新する必要がある場合と、カバリングインデックスを使用する可能性を増加させます。だから私は、選択中のフィールド名の後ろに直接接続要求しました。
第四に、あなたが唯一のデータ使用制限1を必要とするとき
これは、EXPLAIN const型で型の列を達成することです
ソートフィールドがインデックスに使用されていない場合は第五、できるだけソートします
第六に、他の分野での制約がインデックス化されていない場合、またはできるだけ
他の条件は、フィールドをインデックス化していない間、またはフィールドの両側には、フィールドのインデックスがない場合、状況はクエリがインデックスを行かない原因になります。交換する「または」する労働組合のすべてまたは共用（必要な）方法を使用して多くの時間が、より良い結果を得ることができます。
七、労働組合と労働組合を交換しようとするすべての
連合と労働組合のすべての違いは主に旧ますが、ソート含むことになる結果、その後、フィルタリング操作の独自のコレクションを必要とし、CPU操作の数を増やし、資源の消費量とレイテンシを増加させます。もちろん、条件付きで2つの労働組合のすべての結果データセットが繰り返されていないこと。
八、RAND（BY ORDERを使用しないでください）
select id from `dynamic` order by rand() limit 1000;SQL文の上に合わせて最適化することができます
select id from `dynamic` t1 join (select rand() * (select max(id) from `dynamic`) as nid) t2 on t1.id > t2.nidlimit 1000;
九、中および存在、ないではなく区別するために存在します
select * from 表A where id in (select id from 表B)上記の文は、SQLと同じです
select * from 表A where exists(select * from 表B where 表B.id=表A.id)
違いは、主に存在し、（主要なパフォーマンスの変化である）順序を変更するためのドライバは、それが存在する場合は、テーブル駆動型テーブルの外側層は、最初にアクセスされることがである場合、それはサブクエリを実行引き起こさ。適合ので大小外側インナー場合、小規模および大規模なテーブルの外側のケースに適応存在します。
、ない存在ではなくについて我々は、存在していないだけでなく、効率を推奨、ロジックに問題がある可能性がありません。高効率の代替を書くためにどのようにSQL文を存在しませんか？
元のSQL文の
select colname … from A表 where a.id not in (select b.id from B表)
効率的なSQL文の
select colname … from A表 Left join B表 on where a.id = b.id where b.id is null以下に示すように、結果セットを削除する表には、表Bのデータはないが、示し
十、ページングページング効率を高めるために合理的な方法の使用
-
-
選択 ID、名前 製品から 限界 866613、 20
ページネーションを行うには、SQL文を使用している場合、一部の人々はそれを見つけることができ、テーブルデータの量が増加すると、直接問い合わせページ制限が遅くなります使用します。
次のように最適化する方法であって、行の最大数、および次の開始点がこの最大IDに基づいて制限される前に、IDがとることができます。だから、最大の以前のIDより列は866612です。次のようにSQLを書くことができます。
select id,name from product where id> 866612 limit 20
XI、サブクエリ
一部のユーザーの選択ページでは、一部のユーザーは、フレームがスロークエリで、その結果、大きすぎる時間を選択することができます。主な理由は、走査線の過剰な数です。今回は、ディスプレイ上の結果の統合プロセスを通じてセグメンテーションクエリ、ループをプログラムすることができます。
あなたはセグメンテーションクエリを使用することができ、走査線の数よりも多くに百万のSQL文下図、
句が判断した場合にNULL値のフィールドをXIIを避けます
nullの判断のためにエンジンがインデックスと全表スキャンを使用してあきらめてしまいます。
XIIIは、ファジィクエリのプレフィックス％を使用することは推奨されません
「％名」またはLIKE「％名％」LIKE例えば、このような問合せは全表スキャンのためにインデックスしながら、故障につながることができます。しかし、あなたは「名％」のように使用することができます。
どのようにクエリ％名％？
インデックスが秘密のフィールドに追加されているが、以下に示すが、果物で結果を説明していないとして、
したがって、この問題を解決する方法、答えは：フルテキストインデックスの使用
私たちのクエリでは、多くの場合、 '％zhangsan％' のようなdynamic_201606 USER_NAMEから。SELECT ID、FNUM、fdstを使用;. このような文は、一般的な指標は、お問い合わせのニーズを満たすことができません。幸い、MySQLでは、フルテキストインデックスは、私たちを支援します。
フルテキストインデックスSQL構文を作成することです：
ALTER TABLE `dynamic_201606` ADD FULLTEXT INDEX `idx_user_name` (`user_name`);フルテキストインデックスSQLステートメントでを使用します。
select id,fnum,fdst from dynamic_201606 where match(user_name) against('zhangsan' in boolean mode);
注意：あなたは、フルテキストインデックスを作成する必要がある前に、作成されたかどうかを判断するには、DBAに連絡してください。また、ノートの定期的なインデックスとクエリの文言の違いはあります
第四に、句の式フィールドで動作避けます
そのようなものとして
select user_id,user_project from user_base where age*2=36;エンジンは、インデックスを使用して放棄させることができるライン上の演算の分野において、提案された変更
select user_id,user_project from user_base where age=36/2;
第五に、暗黙の型変換を避けるために、
型変換が発生した一貫性のないパラメータの種類は、どこ型のパラメータを決定することを推奨されている場合、Typeカラムは、where句フィールドに表示され、渡されました
共同インデックスのXVI、法令を遵守する最も左のプレフィックス
カラムがインデックスID、名前、学校、idフィールドのフィールドを直接使用することができます含まれているために、ID、この順に名前が、名前であってもよく、学校では、このインデックスを使用することはできません。したがって、関節のインデックスを作成するときには、一般的に前にクエリフィールドで使用される、インデックスフィールドの順序に注意を払う必要があります
必要に応じてXVII力指数は、インデックスクエリが行く強制するために、使用することができ、
時にはそれを取るために、MySQLのオプティマイザは、適切なインデックスは、SQL文を取得するために考えて、それがインデックスに使用することができる私たちが望むものではありません。そして、あなたは私たちが開発したインデックスを使用するようオプティマイザに強制的にforceindex使用することができます。
XVIII注意スパンクエリ
関節指数のために、そのような間のような範囲クエリ、>、<ときに、他の条件がある場合、インデックスフィールドの後ろの故障を引き起こす可能性があります。
JOINの最適化に関する、第九
LEFTテーブル駆動テーブルのJOIN
INNERは、MySQLのJOINは自動的に少しデータテーブル駆動型のテーブルの役割を識別します
RIGHT Bに参加すると、テーブル駆動型のテーブルです
。注：MySQLは参加いっぱいではありません、あなたが解決するために、次の方法を使用することができます
左から*選択をBに参加b.name = A.namewhere b.nameにnullunionのallselectある Bから*、
内側を利用するジョイン、避けるために参加左
少なくとも二つのテーブルのジョイントテーブルクエリに参加し、点の大きさは、一般的に存在します。接続は内部結合である場合、MySQLは左側のテーブル名を参加残した、自動的に駆動表などの他のフィルタの状況が存在しない場合に小さなテーブルを選択しますが、左駆動テーブルの選択に続いジョインを右へ左ドライブの原理であります駆動テーブル。
インデックスの使用の合理化
制限フィールドとして、テーブルインデックスフィールドで駆動されます。
小さなテーブルと大きなテーブルを駆動します
図から直接であるが、駆動テーブルを減らす数とCPU IOオペレーションの総量を減少させるために、ループ内でネストされたループの数を低減することが可能であるかどうかを確認することができます。
巧用STRAIGHT_JOIN
内側ドライバMySQLのテーブルによって選択された結合が、いくつかの特別な事情がある場合に「filesortレコードを使用する」等、順によってそのような基として、駆動テーブルなどの別のテーブルを選択する必要が「使用して、一時。」表に、結合順序を強制するSTRAIGHT_JOINは、右が駆動されているテーブル左駆動テーブルSTRAIGHT_JOINあります。使用時にはSTRAIGHT_JOINがクエリは内部結合であることを条件に、ある内部結合です。その他のリンクはSTRAIGHT_JOINを推奨していない、またはそれが不正確な結果を引き起こす可能性があります。
出典ます。https：//zhuanlan.zhihu.com/p/49888088