mysql ヘルプ where a.id=b.id と join on a.id=b.id の効率の違いは何ですか
以下はecshopのproductテーブルとbrandテーブルのクエリです。両者のクエリ効率の違いは何ですか?
もう 1 つの質問は、左結合と結合のどちらがより効率的かということです。
ありがとう! !
SELECT a.`goods_id` , a.`goods_name` , b.brand_nameFROM `ecs_goods` AS aLEFT JOIN ecs_brand AS b ON a.`brand_id` = b.`brand_id`
SELECT a.`goods_id` , a.`goods_name` , b.brand_nameFROM `ecs_goods` AS a, ecs_brand AS bWHERE a.`brand_id` = b.`brand_id`
ディスカッションに返信 (解決策)
他にフィルター条件がないため、最初の数式は左側のリンクです
結果セットには、左側のテーブル (ecs_goods) のすべてのレコードが含まれます
最初の式 2 番目の式はカンマ接続 (INNER JOIN の略)
接続条件を満たすレコードのみが結果セットに表示されます
両者の機能は異なるため、効率の比較はできません
いつ右側のテーブル (ecs_brand) にはフィルター条件があります
左側 接続は内部結合に縮退し、2 つの式は同じであり、違いはありません
他にフィルター条件がないため、最初の式は左側のリンクです
そこ結果セット内の左側のテーブル (ecs_goods) のすべてのレコードになります
2 番目の式 式はカンマ接続 (INNER JOIN の略) です
接続条件を満たすレコードのみが結果セットに表示されます
両者の機能は異なり、効率の比較はできません
モデレータ 左側を削除するのは最初の SQL ですか? 2 番目の SQL とまったく同じです。
効率とインデックスの使用に関して、両者に違いはありますか?
右側のテーブル (ecs_brand) にフィルター条件がある場合
左側の結合は内部結合に縮退し、2 つの式は同じであるため、違いはありません
モデレーター ご回答ありがとうございます。まだ質問があります
たとえば、製品にブランドが必要な場合、その製品にはブランド ID が必要であることを意味します。
次に、ブランドリストに製品を含める必要があるブランドがあります。
したがって、left join または join によって返される結果は同じです。それでは、効率の観点からそれらを比較できるでしょうか?
接続の外側にフィルター条件があるため、mysql は内部接続へのクエリ命令を最適化します。したがって、効率の比較はありません
もちろん、ここで比較できるのは、
商品テーブルでブランド商品を確認することと、ブランドテーブルで商品を探すことです
両者の効率は異なります
ブランドテーブルは明らかに製品テーブルより小さい
接続の外側にフィルター条件があるため、mysql はクエリ命令を内部接続に最適化します。したがって、効率の比較はありません
もちろん、ここで比較できるのは、
商品テーブルでブランド商品を確認することと、ブランドテーブルで商品を探すことです
両者の効率は異なります
ブランドテーブルは明らかに製品テーブルよりも小さいです
モデレーター ご回答ありがとうございます
あなたの回答を要約しました:
最初のポイント:
SELECT a.`goods_id` , a.`goods_name` , b.brand_nameFROM `ecs_goods` AS a, ecs_brand AS bWHERE a.`brand_id` = b.`brand_id`
と
SELECT a.`goods_id` , a.`goods_name` , b.brand_nameFROM `ecs_goods` AS aJOIN ecs_brand AS b ON a.`brand_id` = b.`brand_id`
2 つの SQL ステートメントはまったく同じです MySQL は最初の SQL ステートメントを二つ目 。
2 番目のポイント:
「product テーブルでブランド製品を検索するのと、ブランド テーブルで製品を検索する」
つまり、2 つの SQL ステートメント
SELECT a.`goods_id` , a.`goods_name` , b.brand_nameFROM `ecs_goods` AS aJOIN ecs_brand AS b ON a.`brand_id` = b.`brand_id`
と
SELECT a.`goods_id` , a.`goods_name` , b.brand_nameFROM ecs_brand AS bJOIN `ecs_goods` AS a ON b.`brand_id`=a.`brand_id`
の効率は異なります。
/////////////////////////////////////////////// /// /////////////
上記 2 つの説明は正しいですか?正しく理解できましたか?
そうでない場合、2 番目の点に対する誰もが行うアプローチはデカルト積です。
私の理解では、それが ecs_goods` AS a JOIN ecs_brand AS b である場合、
それは製品テーブル内のレコードであり、ブランドテーブル内のすべてのレコードをスキャンします。 10 個の製品と 10 個のブランドがある場合
つまり、10*10=100 100 回スキャンされます
次に、ecs_brand AS b JOIN `ecs_goods` AS a
ブランドが 10 個の製品をスキャンする場合、スキャン回数も 100 回になります。では、なぜ効率が違うのでしょうか?
笑、自分でコンセプトを変えて、自分にコツを与えてください!
SELECT a.`goods_id` , a.`goods_name` , b.brand_nameFROM `ecs_goods` AS a, ecs_brand AS bWHERE a.`brand_id` = b.`brand_id`
SELECT a.`goods_id` , a.`goods_name` , b.brand_nameFROM `ecs_goods` AS a INNER JOIN ecs_brand AS b ON a.`brand_id` = b.`brand_id`
が同等であるというのは完全にあなたの間違った見解です。
SELECT a.`goods_id` , a.`goods_name` , b.brand_nameFROM `ecs_goods` AS a LEFT JOIN ecs_brand AS b ON a.`brand_id` = b.`brand_id`WHERE b.`field_name`= 123
は mysql によって
SELECT a.`goods_id` , a.`goods_name` , b.brand_nameFROM `ecs_goods` AS a, ecs_brand AS bWHERE a.`brand_id` = b.`brand_id`AND b.`field_name`= 123
に最適化されます。ははは、自分でコンセプトをこっそり変更して自分で設定することもできます。
SELECT a.`goods_id` , a.`goods_name` , b.brand_nameFROM `ecs_goods` AS a, ecs_brand AS bWHERE a.`brand_id` = b.`brand_id`
SELECT a.`goods_id` , a.`goods_name` , b.brand_nameFROM `ecs_goods` AS a INNER JOIN ecs_brand AS b ON a.`brand_id` = b.`brand_id`
が同等であるというのは完全にあなたの間違った見解です。
SELECT a.`goods_id` , a.`goods_name` , b.brand_nameFROM `ecs_goods` AS a LEFT JOIN ecs_brand AS b ON a.`brand_id` = b.`brand_id`WHERE b.`field_name`= 123
は mysql によって
SELECT a.`goods_id` , a.`goods_name` , b.brand_nameFROM `ecs_goods` AS a, ecs_brand AS bWHERE a.`brand_id` = b.`brand_id`AND b.`field_name`= 123
に最適化されます。 モデレーター これら 2 つのステートメントを試してみましたが、それらは等しくないようです。
-- -- 表的结构 `good_tbl`-- CREATE TABLE `good_tbl` ( `good_id` int(10) unsigned NOT NULL auto_increment, `brand_id` int(10) unsigned NOT NULL, PRIMARY KEY (`good_id`)) ENGINE=MyISAM DEFAULT CHARSET=gbk AUTO_INCREMENT=4 ;-- -- 导出表中的数据 `good_tbl`-- INSERT INTO `good_tbl` VALUES (1, 2);INSERT INTO `good_tbl` VALUES (2, 3);INSERT INTO `good_tbl` VALUES (3, 2);
-- -- 表的结构 `brand_tbl`-- CREATE TABLE `brand_tbl` ( `brand_id` int(10) unsigned NOT NULL auto_increment, `brand_name` varchar(50) NOT NULL, PRIMARY KEY (`brand_id`)) ENGINE=MyISAM DEFAULT CHARSET=gbk AUTO_INCREMENT=4 ;-- -- 导出表中的数据 `brand_tbl`-- INSERT INTO `brand_tbl` VALUES (1, '诺基亚');INSERT INTO `brand_tbl` VALUES (3, '三星');
モデレーター: これらの mysql 情報はどこで見つけることができますか? たとえば、特定のステートメントが mysql 内の他のステートメントに最適化されることを確認するにはどうすればよいですか?

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック









Laravelは、直感的なフラッシュメソッドを使用して、一時的なセッションデータの処理を簡素化します。これは、アプリケーション内に簡単なメッセージ、アラート、または通知を表示するのに最適です。 データは、デフォルトで次の要求のためにのみ持続します。 $リクエスト -

PHPクライアントURL(CURL)拡張機能は、開発者にとって強力なツールであり、リモートサーバーやREST APIとのシームレスな対話を可能にします。尊敬されるマルチプロトコルファイル転送ライブラリであるLibcurlを活用することにより、PHP Curlは効率的なexecuを促進します

Laravelは簡潔なHTTP応答シミュレーション構文を提供し、HTTP相互作用テストを簡素化します。このアプローチは、テストシミュレーションをより直感的にしながら、コード冗長性を大幅に削減します。 基本的な実装は、さまざまな応答タイプのショートカットを提供します。 Illuminate \ support \ facades \ httpを使用します。 http :: fake([[ 'google.com' => 'hello world'、 'github.com' => ['foo' => 'bar']、 'forge.laravel.com' =>

顧客の最も差し迫った問題にリアルタイムでインスタントソリューションを提供したいですか? ライブチャットを使用すると、顧客とのリアルタイムな会話を行い、すぐに問題を解決できます。それはあなたがあなたのカスタムにより速いサービスを提供することを可能にします

記事では、PHP 5.3で導入されたPHPの後期静的結合(LSB)について説明し、より柔軟な継承を求める静的メソッドコールのランタイム解像度を可能にします。 LSBの実用的なアプリケーションと潜在的なパフォーマ

この記事では、フレームワークにカスタム機能を追加し、アーキテクチャの理解、拡張ポイントの識別、統合とデバッグのベストプラクティスに焦点を当てています。

記事では、入力検証、認証、定期的な更新など、脆弱性から保護するためのフレームワークの重要なセキュリティ機能について説明します。
