簡単にするために、すべての関連フィールドがであると仮定しますNOT NULL。

できるよ：

SELECT
    table1.this, table2.that, table2.somethingelse
FROM
    table1, table2
WHERE
    table1.foreignkey = table2.primarykey
    AND (some other conditions)

または他の場合：

SELECT
    table1.this, table2.that, table2.somethingelse
FROM
    table1 INNER JOIN table2
    ON table1.foreignkey = table2.primarykey
WHERE
    (some other conditions)

これら2つは同じ方法で機能しMySQLますか？

INNER JOIN 使用すべきANSI構文です。

特に多くのテーブルを結合する場合は、一般的に読みやすくなります。

またOUTER JOIN、必要なときにいつでも簡単に置き換えることができます。

WHERE構文は、より多くのリレーショナルモデルが向いています。

2つのテーブルJOINedの結果は、結合列が一致する行のみを選択するフィルターが適用されるテーブルのデカルト積です。

これをWHERE構文で見ると簡単です。

あなたの例については、MySQL（および一般にSQL）では、これら2つのクエリはシノニムです。

MySQLにもSTRAIGHT_JOIN句があることに注意してください。

この句を使用JOINすると、外部ループでスキャンされるテーブルと内部ループでスキャンされるテーブルの順序を制御できます。

MySQLでは、WHERE構文を使用してこれを制御することはできません。

他のINNER JOIN人は人間の読みやすさに役立つと指摘しており、それが最優先事項であると私は同意します。結合構文がより読みやすい理由
を説明してみましょう。

基本的なSELECTクエリは次のとおりです。

SELECT stuff
FROM tables
WHERE conditions

このSELECT条項は、何を取り戻しているかを示しています。FROM句が教えてくれるところ我々はからそれを取得している、とWHERE句が教えてくれるている私たちが取得しているもの。

JOIN テーブル、それらがどのように結合されているか（概念的には、実際には単一のテーブルに）についてのステートメントです。

テーブルを制御するすべてのクエリ要素（データの取得元）は、意味的にはFROM句に属します（もちろん、JOIN要素が移動する場所です）。joining-elementsをWHERE句に入れると、whichとwhere-fromが統合されるため、JOIN構文が推奨されます。

ON / WHEREでの条件ステートメントの適用

ここでは、論理クエリの処理手順について説明しました。

参照：Microsoft®SQL Server™2005 T-SQLクエリの
発行元：Microsoft Press
Pub日付：2006年3月7日
印刷ISBN-10：0-7356-2313-9
印刷ISBN-13：978-0-7356-2313-2
ページ：640

Microsoft®SQL Server™2005 T-SQLクエリの内部

(8)  SELECT (9) DISTINCT (11) TOP <top_specification> <select_list>
(1)  FROM <left_table>
(3)       <join_type> JOIN <right_table>
(2)       ON <join_condition>
(4)  WHERE <where_condition>
(5)  GROUP BY <group_by_list>
(6)  WITH {CUBE | ROLLUP}
(7)  HAVING <having_condition>
(10) ORDER BY <order_by_list>

他のプログラミング言語とは異なるSQLの最初の注目すべき側面は、コードが処理される順序です。ほとんどのプログラミング言語では、コードは記述された順序で処理されます。SQLでは、処理される最初の句はFROM句ですが、最初に現れるSELECT句はほぼ最後に処理されます。

各ステップは、次のステップへの入力として使用される仮想テーブルを生成します。これらの仮想テーブルは、呼び出し元（クライアントアプリケーションまたは外部クエリ）では使用できません。最後のステップで生成されたテーブルのみが呼び出し元に返されます。クエリで特定の句が指定されていない場合、対応するステップは単にスキップされます。

論理クエリ処理フェーズの簡単な説明

ステップの説明が今のところあまり意味をなさないように見えても、あまり心配しないでください。これらはリファレンスとして提供されています。シナリオの例の後のセクションでは、手順についてさらに詳しく説明します。

1. FROM：デカルト積（クロス結合）がFROM句の最初の2つのテーブル間で実行され、その結果、仮想テーブルVT1が生成されます。

2. ON：ONフィルターがVT1に適用されます。<join_condition>がTRUE である行のみがVT2に挿入されます。

3. OUTER（結合）：（CROSS JOINまたはINNER JOINではなく）OUTER JOINが指定されている場合、一致が見つからなかった1つまたは複数の保持されたテーブルの行が、VT2の行に外部行として追加され、生成されますVT3。FROM句に3つ以上のテーブルが表示される場合、すべてのテーブルが処理されるまで、最後の結合の結果とFROM句の次のテーブルの間にステップ1〜3が繰り返し適用されます。

4. WHERE：WHEREフィルターはVT3に適用されます。<where_condition>がTRUE である行のみがVT4に挿入されます。

5. GROUP BY：VT4からの行は、GROUP BY句で指定された列リストに基づいてグループに配置されます。VT5が生成されます。

6. CUBE | ROLLUP：スーパーグループ（グループのグループ）がVT5からの行に追加され、VT6が生成されます。

7. HAVING：HAVINGフィルターはVT6に適用されます。<having_condition>がTRUE であるグループのみがVT7に挿入されます。

8. SELECT：SELECTリストが処理され、VT8が生成されます。

9. DISTINCT：重複する行がVT8から削除されます。VT9が生成されます。

10. ORDER BY：VT9からの行は、ORDER BY句で指定された列リストに従ってソートされます。カーソルが生成されます（VC10）。

11. TOP：指定した行数または割合の行がVC10の最初から選択されます。テーブルVT11が生成され、呼び出し元に返されます。

（ON / WHEREで条件ステートメントを適用しても、ほとんどの場合大きな違いはありません。これは、結合したテーブルの数と各結合テーブルで使用可能な行の数によって異なります）

暗黙の結合ANSI構文は古く、あまり明確ではなく、推奨されません。

さらに、リレーショナル代数を使用すると、WHERE句との述語を交換できるINNER JOINため、句を使用したINNER JOINクエリでもWHERE、オプティマイザによって述語を再配置できます。

できるだけ読みやすい方法でクエリを記述することをお勧めします。

これには、INNER JOIN比較的「不完全」なものをWHERE作成し、フィルター基準のリストをより簡単に保守できるようにするために、いくつかの基準を単純に含めることが含まれる場合があります。

たとえば、次の代わりに：

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
    AND c.State = 'NY'
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
    AND a.Status = 1

書く：

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
WHERE c.State = 'NY'
    AND a.Status = 1

しかし、それはもちろん異なります。

暗黙的な結合（最初のクエリの名前）は、クエリにテーブルを追加する必要があると、はるかに混乱し、読みにくく、保守が難しくなります。4つまたは5つの異なるテーブルで同じクエリとタイプの結合を行うことを想像してみてください...それは悪夢です。

明示的な結合（2番目の例）を使用すると、はるかに読みやすく、保守が容易になります。

また、古い構文を使用するとエラーが発生しやすくなることも指摘しておきます。ON句なしで内部結合を使用すると、構文エラーが発生します。古い構文を使用していて、where句の結合条件の1つを忘れた場合は、クロス結合になります。開発者は、（結合自体が壊れていることにまだ気付いていないために結合を修正するのではなく）キーワードを追加してこれを修正しますが、これは問題を解決するように見えますが、クエリをかなり遅くします。

さらに、古い構文にクロスジョインがある場合のメンテナンスについて、メンテナは、クロスジョインが必要な場合（クロスジョインが必要な状況がある場合）または修正する必要のある事故であるかどうかをどのようにして知るのでしょうか。

左結合を使用する場合に暗黙の構文が悪い理由を確認するために、この質問を紹介します。 Sybase * =同じ内部テーブルに対して2つの異なる外部テーブルを使用するAnsi標準

さらに（ここでは個人的な暴言）、明示的な結合を使用する標準は20年以上前のものです。つまり、暗黙的な結合構文はその20年で古くなっています。20年以上古い構文を使用してアプリケーションコードを記述しますか？なぜ、データベースコードを記述したいのですか？

人間が読める意味は異なります。

ただし、クエリオプティマイザーによっては、マシンにとって同じ意味を持つ場合があります。

常に読みやすいようにコーディングする必要があります。

つまり、これが組み込みの関係である場合は、明示的な結合を使用します。弱い関連データで照合する場合は、where句を使用します。

SQL：2003標準では、いくつかの優先ルールが変更されたため、JOINステートメントは「カンマ」結合よりも優先されます。これにより、実際の設定に応じてクエリの結果が変わる可能性があります。これは、MySQL 5.0.12が標準に準拠するように切り替えたときに、一部の人々にいくつかの問題を引き起こします。

したがって、あなたの例では、クエリは同じように機能します。しかし、3番目のテーブルを追加した場合：SELECT ... FROM table1、table2 JOIN table3 ON ... WHERE ...

MySQL 5.0.12より前は、table1とtable2が最初に結合され、次にtable3が結合されていました。これで（5.0.12以降）、table2とtable3が最初に結合され、次にtable1が結合されます。結果は常に変化するとは限りませんが、変化する可能性があり、気付かない場合もあります。

「カンマ」構文はもう使用しません。2番目の例を選択します。とにかく読みやすく、JOIN条件はJOINであり、個別のクエリセクションに分割されていません。

MySQLについて話しているのは知っていますが、とにかくOracle 9では、明示的結合と暗黙的結合で異なる実行プランが生成されます。Oracle 10+で解決されたAFAIK：そのような違いはもうありません。

ANSI結合構文は間違いなく移植性が高いです。

Microsoft SQL Serverのアップグレードを行っています。また、SQL Serverの外部結合の= *および* =構文は、2005 SQL Server以降ではサポートされていません（互換モードなし）。

動的ストアドプロシージャを頻繁にプログラミングしている場合は、2番目の例（whereを使用）に夢中になります。さまざまな入力パラメーターと多くのモーフ混乱がある場合、それが唯一の方法です。それ以外の場合は、どちらも同じクエリプランを実行するため、従来のクエリに明らかな違いはありません。