私はここでかなり困惑しています。
私は2つのテーブルを持っており、どのレコードが最初のもので2番目のものではないかを調べるために、最初のもの(約50万レコード)と2番目のもの(約220万レコード)を結合したままです。(典型的な「b.attribute is null」ナンセンス)
最初のテーブルでインデックスが使用されるのはなぜ (どのように) ですか? とにかく、最初のテーブルのすべてのレコードを通過する必要がありますが、最初のテーブルでインデックス（または主キー..これはすべてETLであるため必要ありません）なしでこの結合を実行しようとすると、クロールします。
ちなみに、innodbを使用しています。
ヘルプ？
EDIT : 2 番目のテーブルにインデックスが付けられます。最初はそうではありませんでした。
これはそれにいくつかの光を当てるはずです：http://dev.mysql.com/doc/refman/5.5/en/innodb-index-types.html
つまり、すべての InnoDB テーブルには、実際の行が格納されるいわゆる「クラスター化インデックス」があります (テーブルに明示的なインデックスが定義されていなくても、InnoDB は自動的に作成します)。
これが起こっているかどうかはわかりませんが、理論的には、データベースエンジンが、テーブル自体ではなく、左側のテーブルのインデックスをスキャンする可能性があります（実際のクエリによって異なります）。そのために必要なキーデータを構築できます。インデックスのスキャンがテーブルのスキャンよりも高速である場合、速度の違いが原因である可能性があります。
プライマリ インデックスの目的は、(少なくとも SQL Server では) 大きなツリーを並べ替えて作成することにより、物事を整理することです。より具体的に言えばBツリー。これは、各レコードのキーがツリー内のある場所 (またはバケット) に属していることを意味します。
では、FIRST テーブルにキーを追加すると、クエリの速度が向上するのはなぜでしょうか。その理由は、クエリが実行されると、主キーが存在するためにSECOND テーブルが既にソートされているため、FIRST テーブルがソートされているためです。これは、ソートされた 2 つのリストを比較する方が、各要素のバイナリ検索を実行するよりもはるかに高速であるという単純な事実によるものです。この場合、インデックスがないため、ソートに時間がかかります。
ところで、私の言うことに惑わされないでください。実際にはリストを比較しているわけではありませんが、上の図のインデックス ツリーをさらに剪定します。たとえば、T1 に K1、K2、K3 があり、K1 が図の 2 番目のバケットにある場合、最初のバケットで残りを確認する必要はありません。キーの。
MySQLにはハッシュ結合がありません。