SQL の問題を解決すると、MySQL についての理解が確実に一歩前進します。
SQL チュートリアル このコラムでは、MySQL をより効果的に理解する方法を紹介します
属性テーブル (product_props) の構造は次のとおりです
データ音量が 800 W を超えていますタイプ | 説明 | |
---|---|---|
int | id | |
int | 属性タイプ | |
int | 属性値 | |
int | Product ID |
pn_id | pv_id | |
---|---|---|
5 (モデル) | 135 (Apple 9) | |
11 (メモリ) | 23 (512G) | |
10 (カラー) | 17 (ローカルゴールド) | |
8 (ネットワーク) | 6(5G) | |
5 | 135 | |
11 | 24 (1024G) | |
10 | 16 (オーロラブルー) |
##データ量が 40W を超える
説明 | ||
---|---|---|
product_id | type_id | |
typeid | brand_id | |
brandid | model_id | |
モデル id | ステータス | |
ステータス |
brand_id | model_id | status | ||
---|---|---|---|---|
1(Apple) | 1(iPhone8) | 1(通常) | 10980 | |
1(Apple) | 1(iPhone8X) | 3 (販売済み) | 10981 | |
1(Apple) | 1 (Iphone8XP) | 1(正常) |
モデル番号が であることを確認します。 Apple 9
同時に、メモリは512G、色は ローカル ゴールド、ステータスは normal、製品の総数は 、ps: 属性条件は 10 グループを超える可能性があります。 要件
パフォーマンスを最優先し、集計関数などは避けます。
元の問題に対する解決策のパフォーマンス ランキング
@Kamicloud からの既存のスキーム
- @Elijah_Wang からのサブクエリ スキーム
SELECT sql_no_cache `product_id` FROM `zx_tests` AS a WHERE `pn_id` = 101 AND `pv_id` = 59 AND EXISTS( SELECT sql_no_cache * FROM `zx_tests` WHERE a.product_id = product_id and `pn_id` = 101 AND `pv_id` = 171); 2 组条件下 0.657,3 组 0.695,4 组 0.759,5 组 0.743 (单独查属性表)
- 新しい質問後のパフォーマンス ランキング
SELECT `product_id` FROM `product` WHERE `pn_id` = 5 AND `pv_id` = 135 AND `product_id` IN (SELECT `product_id` FROM `product` WHERE `pn_id` = 11 AND `pv_id` = 23); 2 组条件下 0.729,3 组 0.75,4 组 0.730,5 组 0.757 (新问题之前)
@Elijah_Wang からのサブクエリ プラン
- 1.5 ~ 1.56 (実行範囲 10)
select SQL_NO_CACHE count(1) from pdi_product a join ( SELECT distinct product_id FROM `product_props` WHERE `pn_id` = 5 AND `pv_id` = 127 AND `product_id` IN ( SELECT `product_id` FROM `product_props` WHERE `pn_id` = 11 AND `pv_id` = 22 ) AND `product_id` IN ( SELECT `product_id` FROM `product_props` WHERE `pn_id` = 10 AND `pv_id` = 18 ) AND `product_id` IN ( SELECT `product_id` FROM `product_props` WHERE `pn_id` = 8 AND `pv_id` = 6 ) AND `product_id` IN ( SELECT `product_id` FROM `product_props` WHERE `pn_id` = 9 AND `pv_id` = 1 ) ) b on a.product_id = b.product_id where a.status = 1;
分析の説明:
- #
select SQL_NO_CACHE count(1) from pdi_product a where a.status = 1 and a.product_id in (SELECT distinct product_id FROM `product_props` WHERE `pn_id` = 5 AND `pv_id` = 127 AND `product_id` IN ( SELECT `product_id` FROM `product_props` WHERE `pn_id` = 11 AND `pv_id` = 22 ) AND `product_id` IN ( SELECT `product_id` FROM `product_props` WHERE `pn_id` = 10 AND `pv_id` = 18 ) AND `product_id` IN ( SELECT `product_id` FROM `product_props` WHERE `pn_id` = 8 AND `pv_id` = 6 ) AND `product_id` IN ( SELECT `product_id` FROM `product_props` WHERE `pn_id` = 9 AND `pv_id` = 1 ))
-
@Kamicloud からの既存の解決策
SELECT SQL_NO_CACHE count(1) FROM product a WHERE a.STATUS = 1 AND a.product_id IN ( SELECT DISTINCT `product_id` FROM `product_props` AS a WHERE a.`pn_id` = 5 AND a.`pv_id` = 127 AND EXISTS ( SELECT product_id FROM `product_props` WHERE a.product_id = product_id AND `pn_id` = 11 AND `pv_id` = 22 ) AND EXISTS ( SELECT product_id FROM `product_props` WHERE a.product_id = product_id AND `pn_id` = 10 AND `pv_id` = 18 ) AND EXISTS ( SELECT product_id FROM `product_props` WHERE a.product_id = product_id AND `pn_id` = 9 AND `pv_id` = 1 ) AND EXISTS ( SELECT product_id FROM `product_props` WHERE a.product_id = product_id AND `pn_id` = 8 AND `pv_id` = 6 ) );
- 5.7-5.85 かかります (実行範囲 10 回)
- # #分析の説明:
SELECT SQL_NO_CACHE count(1) FROM pdi_product a join (SELECT DISTINCT `product_id` FROM `product_props` AS a WHERE a.`pn_id` = 5 AND a.`pv_id` = 127 AND EXISTS ( SELECT product_id FROM `product_props` WHERE a.product_id = product_id AND `pn_id` = 11 AND `pv_id` = 22 ) AND EXISTS ( SELECT product_id FROM `product_props` WHERE a.product_id = product_id AND `pn_id` = 10 AND `pv_id` = 18 ) AND EXISTS ( SELECT product_id FROM `product_props` WHERE a.product_id = product_id AND `pn_id` = 9 AND `pv_id` = 1 ) AND EXISTS ( SELECT product_id FROM `product_props` WHERE a.product_id = product_id AND `pn_id` = 8 AND `pv_id` = 6 ) ) b on a.product_id = b.product_id WHERE a.STATUS = 1
ログイン後にコピー5.7-6.0 かかります (実行範囲 10 回)
分析の説明:
Explain 分析後、最初のサブクエリが速い理由は、その SQL が単純であり、select_type が単純であるためです。
join メソッドや既存メソッドに関係なく、select_type はほとんどが DERIVED および DEPENDENT SUBQUERY です。 関連する無料学習の推奨事項:
mysql ビデオ チュートリアル
以上がSQL の問題を解決すると、MySQL についての理解が確実に一歩前進します。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

ホット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)

ホットトピック

データ統合の簡素化:AmazonrdsmysqlとRedshiftのゼロETL統合効率的なデータ統合は、データ駆動型組織の中心にあります。従来のETL(抽出、変換、負荷)プロセスは、特にデータベース(AmazonrdsmysQlなど)をデータウェアハウス(Redshiftなど)と統合する場合、複雑で時間がかかります。ただし、AWSは、この状況を完全に変えたゼロETL統合ソリューションを提供し、RDSMYSQLからRedshiftへのデータ移行のための簡略化されたほぼリアルタイムソリューションを提供します。この記事では、RDSMysQl Zero ETLのRedshiftとの統合に飛び込み、それがどのように機能するか、それがデータエンジニアと開発者にもたらす利点を説明します。

1.正しいインデックスを使用して、データの量を削減してデータ検索をスピードアップしました。テーブルの列を複数回検索する場合は、その列のインデックスを作成します。あなたまたはあなたのアプリが基準に従って複数の列からのデータが必要な場合、複合インデックス2を作成します2。選択した列のみを避けます。必要な列のすべてを選択すると、より多くのサーバーメモリを使用する場合にのみサーバーが遅くなり、たとえばテーブルにはcreated_atやupdated_atやupdated_atなどの列が含まれます。

MySQLプライマリキーは、データベース内の各行を一意に識別するキー属性であるため、空にすることはできません。主キーが空になる可能性がある場合、レコードを一意に識別することはできません。これにより、データの混乱が発生します。一次キーとして自己挿入整数列またはUUIDを使用する場合、効率やスペース占有などの要因を考慮し、適切なソリューションを選択する必要があります。

MySQLは、複数の同時接続を処理し、マルチスレッド/マルチプロセスを使用して、各クライアントのリクエストに独立した実行環境を割り当てて、邪魔されないことを確認できます。ただし、同時接続の数は、システムリソース、MySQL構成、クエリパフォーマンス、ストレージエンジン、ネットワーク環境の影響を受けます。最適化では、コードレベル(効率的なSQLの書き込み)、構成レベル(MAX_Connectionの調整)、ハードウェアレベル(サーバー構成の改善)などの多くの要因を考慮する必要があります。

ルートとしてMySQLにログインできない主な理由は、許可の問題、構成ファイルエラー、一貫性のないパスワード、ソケットファイルの問題、またはファイアウォール傍受です。解決策には、構成ファイルのBind-Addressパラメーターが正しく構成されているかどうかを確認します。ルートユーザー許可が変更されているか削除されてリセットされているかを確認します。ケースや特殊文字を含むパスワードが正確であることを確認します。ソケットファイルの許可設定とパスを確認します。ファイアウォールがMySQLサーバーへの接続をブロックすることを確認します。

MySQLがテーブル構造を変更すると、メタデータロックが通常使用され、テーブルがロックされる可能性があります。ロックの影響を減らすために、次の測定値をとることができます。1。オンラインDDLでテーブルを使用できます。 2。バッチで複雑な変更を実行します。 3.小規模またはオフピーク期間中に操作します。 4. PT-OSCツールを使用して、より細かい制御を実現します。

MySQLはAndroidで直接実行できませんが、次の方法を使用して間接的に実装できます。Androidシステムに構築されたLightWeight Database SQLiteを使用して、別のサーバーを必要とせず、モバイルデバイスアプリケーションに非常に適したリソース使用量が少ない。 MySQLサーバーにリモートで接続し、データの読み取りと書き込みのためにネットワークを介してリモートサーバー上のMySQLデータベースに接続しますが、強力なネットワーク依存関係、セキュリティの問題、サーバーコストなどの短所があります。

MySQLはJSONデータを返すことができます。 json_extract関数はフィールド値を抽出します。複雑なクエリについては、Where句を使用してJSONデータをフィルタリングすることを検討できますが、そのパフォーマンスへの影響に注意してください。 JSONに対するMySQLのサポートは絶えず増加しており、最新バージョンと機能に注意を払うことをお勧めします。
