場合によります;両方を実行して調べます。次に、説明のために「explainselect」を実行します。
実際のパフォーマンスの違いは、id ='12345'のAの行のうち、BとCに一致するレコードがない行の数に応じて、「実質的に存在しない」から「かなり重要」までの範囲になります。
更新 （投稿されたクエリプランに基づく）
INNER JOINを使用する場合、どのテーブルから開始するかは（パフォーマンスではなく結果の観点から）重要ではないため、オプティマイザーは、パフォーマンスが最も高いと思われるテーブルを選択しようとします。適切なすべてのPK/FK列にインデックスがあり、friend_events.useridにインデックスがないようです。 または、userid = '13006'のレコードが多すぎます そしてそれは使用されていません。どちらの方法でも、オプティマイザーは行の少ないテーブルを「ベース」として選択します。この場合は、zcms_usersです。 。
LEFT JOINを使用すると、機能します どのテーブルから始めるか（結果に関して）。したがって、friend_events 選ばれます。今なぜ そうすれば時間がかからないので、よくわかりません。 friend_events.useridだと思います 状態が役立ちます。その上にインデックスを追加すると（実際にはvarcharですか、数値ではありませんか？）、INNER JOINの動作も異なる（そして高速になる）可能性があります。