序文
前回の記事では、MySQLアーキテクチャとそれに関連するストレージエンジンの紹介を紹介しました。次に、SQLステートメントの最適化と特定のSQL最適化手順を紹介します。次に、SQLを最適化するための特定の手順を紹介します。
実際、開発中であれ人工知能であれ、データベースから分離して必要なデータを保存するために使用することはできません。初期の頃はまだデータ量が少なかったので、最初はSQL文を書くときに関数の実現に気を配っていましたが、実際にプロジェクトを運用するにつれ、データ量が飛躍的に増え、多くのSQLステートメントの開始パフォーマンスの問題が徐々に発生し、プロジェクトのパフォーマンス要件がますます高くなっています。このとき、必要に応じてSQLステートメントを最適化する必要があります。次に、MysqlでのSQLの特定の最適化手順を紹介します。SQLパフォーマンスの問題を最適化するときは、SQLステートメント自体を分析し、SQLステートメントの最適化を可能な限り最大化する必要があります。
1.SQLの実行頻度を確認します
MySQLクライアントに正常に接続すると、次のコマンドを使用してサーバーのステータス情報を提供できます。
show[session|global] status
ただし、上記のコマンドから、パラメータがあるsessionか、レベルの計算結果（現在の接続）とグローバルレベルの統計結果（データベースが最後に起動されてから）globalを表示sessionすることがわかります。指定しない場合は、デフォルトで使用されますsession。次のコマンドは、現在のセッションのすべての統計パラメータの値を表示します：
show status like `Com______`;
具体的な結果は次のとおりです。
次のコマンドを使用して、SQLステートメントのステータスを表示できます。
show status like `Innodb_rows_%`;
具体的な結果は次のとおりです。
ここでは、Com_xxxが各xxxステートメントの実行数を表すいくつかのパラメーターを紹介します。通常、次の統計パラメーターに関心
があります。ここでは、次の2つのパラメーターを具体的に説明する必要があります。
- Com_ ***：これらのパラメーターは、すべてのストレージエンジンのテーブル操作に対して累積されます。
- Innodb_ ***：これらのパラメーターはInnoDBストレージエンジン専用であり、累積アルゴリズムもわずかに異なります。
次に、SQLの非効率的な実行を見つけます
次の2つの方法で、実行効率が低下したSQLステートメントを見つけることができます。
- 遅いクエリログ：遅いクエリログを使用して、実行効率が低下しているSQLステートメントを見つけます。-log-slow-queries[= file_name]オプションを指定して開始すると、mysqldは実行されたすべてのSQLステートメントを含むログファイルを書き込みます。時間はlong_query_time秒を超えています。
- show processlist：遅いクエリログはクエリの終了後に記録されるため、アプリケーションが実行効率の問題を反映している場合、遅いクエリログをクエリしても問題を特定できません。showprocesslistコマンドを使用して、次のような現在のMySQLスレッドを表示できます。スレッドのステータス、テーブルをロックするかどうかなど、SQLの実行をリアルタイムで表示し、いくつかのロックテーブル操作を最適化できます。
show processlist;
具体的な結果は次のとおりです。
次に、上記の表の各列名の意味を紹介します。
- id列：ユーザーがmysqlにログインするときにシステムによって割り当てられる「connection_id」。これは関数connection_id（）を使用して表示できます。
- ユーザー列：現在のユーザーを表示します。rootでない場合、このコマンドはユーザーの権限のsqlステートメントを表示します。
- ホスト列：ステートメントの送信元のIPとポートを示します。これを使用して、問題のあるステートメントを持つユーザーを追跡できます。
- db列：プロセスが現在接続されているデータベースを示します
- コマンド列：現在接続されている実行コマンドを表示します。通常、値はsleep（sleep）、query（query）、connect（connect）などです。
- 時間列：この状態の期間を秒単位で表示します
- 状態列：現在の接続を使用したSQLステートメントの状態を示します。これは非常に重要な列です。状態は、ステートメントの実行における特定の状態を表します。SQLステートメントは、クエリを例にとると、tmpテーブルへのコピー、結果の並べ替え、データの送信などによって完了する必要がある場合があります。
- 情報列：このSQLステートメントが表示されます。これは、問題ステートメントを判断するための重要な基礎です。
3つ目は、分析実行計画を説明する
非効率的なSQLステートメントをクエリする上記の手順により、MySQLがEXPLAINまたはDESCコマンドを介してselectステートメントを実行する方法に関する情報を取得できます。これには、テーブルの接続方法やselectステートメントの実行中の接続の順序が含まれます。次に、次のステートメントを使用して実行プランを表示します。
explain select * from tb_item where id = 1;
具体的な結果は次のとおりです。
サンプルステートメントを通じてそれを達成します。
explain select * from tb_item where title = '阿尔卡特(OT-979) 冰川白 联通3G手机3';
具体的な結果は次の通りです：
にexplainフィールド、と我々はに関連する特定の意味を紹介し
、我々は特定の最適化SQL文を実証するための詳細なケースを持って次のを、私たちは3つのテーブル、すなわち、準備をしてみましょう：t_user、USER_ROLE、t_roleテーブルとの関係をそれらは、図に示されている：
次に、我々は3つのテーブルを作成まず、作成します。t_roleテーブルを次のように特定のコマンドは次のとおりです。
create table `t_role`(
`id` varchar(32) NOT NULL,
`role_name` varchar(255) DEFAULT NULL,
`role_code` varchar(255) DEFAULT NULL,
`description` varchar(255) DEFAULT NULL,
PRIMARY KEY(`id`),
UNIQUE KEY `unique_role_name`(`role_name`)
)ENGINE = InnoDB DEFAULT CHARSET=utf8;
次に、t_usertableとuser_roletableの2つのテーブルを作成します。t_roleテーブルはすでに作成されているため、スペースを確保するために図の形式で実装します。
次に、作成したテーブルのデータを挿入します。挿入ステートメントは次のとおりです。
1.説明のID
idフィールドは、selectクエリのシーケンス番号であり、一連の番号であり、クエリでselect句または操作テーブルが実行される順序を示します。3つのid状況があります：
- 1.同じIDは、テーブルをロードする順序が上から下であることを意味します。
explain select * from t_role r, t_user u, user_role ur where r.id = ur.role_id and u.id = ur.user_id;
- 2. id値が高いほど、優先度が高くなり、実行が早くなります。
explain select * from t_role where id = (select role_id from user_role where user_id = (select id from t_user where username = 'stu1'));
- 3. IDは同じですが、異なり、同時に存在します。同じIDを持つものはグループと見なされ、上から下の順に実行されます。すべてのグループで、idの値が大きいほど、優先度が高くなり、実行が早くなります。
explain select * from t_role r, (select * from user_role ur where ur.`user_id` = '2') a where r.id = a.role_id;
2、explain之select_type
次の表に示すように、選択値と共通値のタイプを示します。
3、説明可能
この行のデータがどのテーブルに関するものかを表示します
4、explain之type
タイプは、より重要な指標であるアクセスのタイプを示しています。可能な値を図に示します：
この表の良いものから悪いものへの結果を図に示します：
NULL>システム> const> eq_ref> ref>フルテキスト> ref_or_null> index_merge> unique_subquery> index_subquery> range> index> ALL
5.キーを説明します
- possible_keys：このテーブルに適用される可能性のあるインデックスを1つ以上表示します。
- キー：実際に使用されるインデックス。NULLの場合、インデックスは使用されません。
- key_len：インデックスで使用されるバイト数を示します。この値は、実際に使用される長さではなく、インデックスフィールドの可能な最大長です。精度が失われない限り、長さは短いほど良いです。
6、説明行
スキャンラインの数。
7、余分な説明
その他の追加の実行プラン情報がこの列に表示されます。
4、プロファイル分析SQLを表示
実際、MySQLバージョン5.0.37の初めから、サポートステートメントshow profilesとshow profileサポートステートメントが追加されています。show profilesこれは、SQLの最適化を行うときに時間が費やされている場所を理解するのに役立ちます。have_profiling現在のMySQLがパラメータを介してプロファイルをサポートしているかどうかを確認できます。
select @@have_profiling;
mysqlのデフォルトのプロファイリングはオフになっています。setステートメントを使用して、セッションレベルでプロファイリングをオンにできます。
select @@have_profiling;
次に、プロファイリングを通じてスイッチをオンにします
set profiling = 1;
次に、プロファイルを渡した後、SQL実行のプロセスをより明確に理解することができました。まず、次のように一連の操作を実行できます。
show databases;
use db01;
show tables;
select * from tb_item where id < 5;
select count(*) from tb_item;
上記のコマンドを実行した後show profiles、SQLステートメントの実行時間を照会する命令を実行します。具体的なプロセスは次のとおりです。
次に、次のコマンドを使用して、SQL実行プロセス中の各スレッドのステータスと消費時間を表示します。
show profile for query query_id;
ここで注意する必要があるのは、データの送信状態は、MySQLスレッドがデータ行へのアクセスを開始し、結果をクライアントだけでなくクライアントに返すことを示しています。データ送信状態では、MySQLスレッドが多くのディスク読み取り操作を実行する必要があることが多いため、クエリ全体で最も時間がかかる状態であることがよくあります。
最も時間のかかるスレッドステータスを取得した後、MySQLは、all、cpu、block io、コンテキストスイッチ、ページフォールトなどの詳細なタイプをさらに選択して、MySQLが使用しているリソースを表示することをサポートします。たとえば、CPUに費やされた時間を表示することを選択します。
5、トレース分析オプティマイザ実行プラン
MySQL 5.6はSQLのトレースを提供します。トレースファイルを通じて、オプティマイザがプランBではなくプランAを選択する理由をさらに理解できます。トレースを開き、形式をjsonに設定し、トレースで使用できる最大メモリサイズを設定して、解析プロセス中にデフォルトのメモリが小さすぎるために完全に表示されないようにします。
set optimizer_trace = "enabled=on", end_markers_in_json = on;
set optimizer_trace_max_men_size = 1000000;
SQLステートメントを実行する
select * from tb_item where id<4;
最後に、information_schema.optimizer_traceMySQLがSQLを実行する方法を確認します。
select * from information_schema.optimizer_trace\G;
具体的な内容は以下のとおりです。
総括する
前回の記事、mysqlのアーキテクチャとストレージエンジンでは、mysqlの内部構造と動作原理をさらに理解し、mysqlのいくつかの典型的なストレージエンジンの違いと特定の使用法を紹介します。この記事では、SQLの実行頻度の表示、非効率的なSQLの特定など、SQLの最適化について紹介し、分析の実行プランについて説明しました。したがって、mysqlは非常に重要なスキルです。コンピューター内のほとんどすべてのジョブにはmysqスキルが必要です。したがって、特別な習熟が必要です。人生は終わりがなく、闘いは終わりがありません。私たちは毎日一生懸命働き、一生懸命勉強し、常に能力を向上させ、何かを学ぶと信じています。いい加減にして！！！