MySQLが使用することはできません最後に参加します
多くの場合、ビューの2種類を聞きます：
の使用を最小限に抑え、低パフォーマンスに参加
マルチテーブルには参加し、より多くの複数のSQLクエリになります
実際、上記のある程度ビューの真の、しかし完全に正しくありません。しかし、そう広く普及した理由は、主に実際の状態をクリアし、いくつかのあいまいな法律の実際の使用に応じてまとめていません。のみのMySQLの実際の実装は道に参加し理解することによって、あなたは、ビューの2種類以上のあいまいな法律は、この法律は、当社の実際の開発を指導しないことを知っています。ここに参加するのMySQLの実際の実装について話をします。
どのようにMySQLの参加の実装です
操作は、十字交点の内側セットに対応するこれらの高校の数学セット、組合、補体間の計算の関係のように参加、外側の、完全ジョイン、内部ジョイン、右ジョイン、例えば左のような一種類のコレクションは、参加することをジョイン言えるジョインコレクションのように。実際のコードでは、実質的に積層することによって達成される動作サイクルに参加します。
一例として、そのT1を想定し、t2の2つのテーブルのテーブル構造は次の通りであります：
createtablet1(
idintnotnullAUTO_INCREMENT,
usernamevarchar(20)notnulldefault,
ageintnotnulldefault0,
PRIMARYkey(`id`)
)ENGINE=INNODBDEFAULTCHARSET=UTF8MB4;
createtablet2(
idintnotnullauto_increment,
usernamevarchar(20)notnulldefault,
scoreintnotnulldefalut0,
primarykey(`id`)
))ENGINE=INNODBDEFAULTCHARSET=UTF8MB4;
100データT1が存在すると仮定し、T2テーブル200番号を有しています
SQLクエリは次のようになります。
selectt1.*,t2.*fromt1leftjoint2on(t1.username=t2.username)
このSQLは、次のステップを実行するよう：
R1、T1データテーブルの行から取ら
R1、クエリテーブルt2に抽出されたユーザ名フィールドから
結果セットの一部として、行R1組成物と、条件を満たしT2テーブル内の行を削除します
繰り返し手順1、2、そうテーブルT1のサイクルが完了するまでデータ
その後、T1ユーザ名のデータの各行に応じて、ルックアップテーブルT2は、記録の条件を満たすように、実質的にトラバースT、1に。基本的な層は2サイクルです。
クエリに参加最適化する方法
上記から分かるように、コストは次の通りである周期性を、参加：
トラバースデータT1、読み出されたデータは、複雑さがNも、テーブルT1の行数が行の数がnであると仮定されます
中線によるT2クエリデータ線にユーザ名が一致するフィールドT1
このプロセスは、MySQLバイナリツリーデータ格納構造、時間複雑度はLOG2（M）であるため、mは、テーブルT2の行数であります次いで、全体的な複雑約n + N（2log2（M））
上記のようにステップ、最適化の方向から見ることができます。
t1のクエリ、オーバーヘッドIO主にディスクが、全表スキャンを避ける際のオーバーヘッドの削減、インデックス
インデックスを使用しても、オーバーヘッドときT2問い合わせを減らします
テーブル駆動テーブルを作成するために、大量のデータ、小さなテーブルを駆動するためのテーブル、データテーブルの量に大きな影響の対数をとり、mはの複雑さのない直線的に増加しません
T1キャッシュテーブル、常に、キャッシュ100のように、ロード・ディスクを行っていない、それはかなりのディスクの数を減らすことができ、T2、T1は、各データキャッシュとを比較し、データを読み出します
ランダムなディスクは、ディスクのパフォーマンスを消費し、読みストレージバイナリツリー構造ので、各非プライマリキーのルックアップは、再びクエリがデータを必要とする主キーに基づいて、テーブルに移動バックがある、シーケンシャルリードに変換しました
最適化の基本的な方法：
、サイクルタイムを削減し、ディスクIOを減らす、IOは確率変数列IOであります
実際には、MySQLは上記の最適化のために、対応するアルゴリズムがあります。
シンプルなネストされたループ結合循環最も一般的なのは、これは避けるべきです
ブロックネストされたループは、主に参加メモリ動作にディスク操作が比較ように、データをバッファリングしていますが、比較的大きなデータ・テーブルを駆動する場合との比較を行うT2データの各行のステップ2でテーブルT2にはインデックスに対して向けに参加しますその後も性能劣化のMySQLで、その結果、主にキャッシュプールが満たされ、パフォーマンスに影響を与えます
インデックスのネストが参加し、このパフォーマンスが優れている主キーによって関連するすべてを見つけることです
バッチキーアクセスは、これは、テーブルに存在し、バックは、非常にコストパフォーマンスのIOランダム操作は、このアルゴリズムのコアは時間がセカンダリインデックスを通じて見つけることがことがあるため、メインキーがソートを取得するために、最適化された結合索引ネストされた上で行われ参加して、主キーに従ってください見つけるために増加し、最適化のパフォーマンスへの読み取り順序にディスクの近くを読みます
最後に参加してはなりません
私たちは、限り、パフォーマンスの制御などと許容範囲内で、実現可能である、またはコードの複雑さを軽減するために参加し、上記の分析から見ることができます。テーブルのインデックスが作成、またはSQLヘアラインそれほど悲惨されていない参加を避ける必要があります。
概要
まだ次の原則に従う限り、使用することを大胆にすることができましょう。
カラムがインデックス付きの列であり、好ましくは、主キーのインデックスと同じタイプの加入作ってみます
小さなテーブル駆動テーブルを作成してみます（MySQLはバージョン5.6の後に自動的に行うことができること）
書かれたSQLは、SQLの実行を観察するために良い習慣を説明運ば開発
