MySQL上級編2日目

記事ディレクトリ

1. MySQL アーキテクチャの概要

MySQL サーバー全体は、次の
接続プールで構成されています。接続プールコンポーネント
管理サービスとユーティリティ: 管理サービスとツールコンポーネント
SQL インターフェイス: SQL インターフェイスコンポーネント
パーサー: クエリアナライザーコンポーネント
オプティマイザー: オプティマイザーコンポーネント
キャッシュとバッファ: バッファプールコンポーネント
プラガブルストレージエンジン: ストレージエンジン
ファイルシステム: ファイルシステム

1) 接続層
最上位層は、ローカル Sock 通信や、クライアント/サーバーツールに基づくほとんどの TCP/IP に似た通信を含む、いくつかのクライアントとリンクサービスです
。主に、いくつかの接続処理、認可認証、および関連するセキュリティソリューションを完了します。スレッドプールの概念は、
認証を通じて安全にアクセスするクライアントにスレッドを提供するためにこの層に導入されています。SSL ベースの安全なリンクもこの層に実装できます。また、サーバーは、安全にアクセスする各クライアントに対してサーバー
が持つ操作権限を検証します。
2) サービス層
北京市昌平区建材城西路金延隆オフィスビル 1 階電話: 400-618-9090 第 2 層アーキテクチャは主に、SQL インターフェイスなどのコアサービス機能のほとんどを完了し、キャッシュされたサービス機能を完了します。クエリ、SQL 分析、および
一部の組み込み関数の実行を最適化します。プロシージャ、関数など、すべてのクロスストレージエンジン機能もこの層に実装されます。この層では、サーバーはクエリを解析して対応する内部解析ツリーを作成し
、テーブルクエリの順序の決定、インデックスを使用するかどうかなどの対応する最適化を完了し、最終的に対応する実行操作を生成します。select ステートメントの場合
、サーバーは内部キャッシュにもクエリを実行します。キャッシュスペースが十分に大きければ、
大量の読み取り操作を解決する環境でシステムのパフォーマンスを大幅に向上させることができます。
3) エンジン層
ストレージエンジン層、ストレージエンジンは MySQL でのデータの保存と取得を担当し、サーバーは API を介してストレージエンジンと通信します。ストレージ
エンジンが異なれば機能も異なるため、ニーズに応じて適切なストレージエンジンを選択できます。
4) ストレージ層
データストレージ層は主にファイルシステムにデータを保存し、ストレージエンジンとの対話を完了します。
他のデータベースと比較すると、MySQL は少し異なり、そのアーキテクチャはさまざまなシナリオに適用でき、適切に動作します。主にストレージに反映されます
エンジンでは、プラグインストレージエンジンアーキテクチャにより、クエリ処理が他のシステムタスクやデータの保存と抽出から分離されます。このアーキテクチャにより、
ビジネスニーズと実際のニーズに基づいて適切なストレージエンジンを選択できます。

2. ストレージエンジン

ほとんどのデータベースとは異なり、MySQL にはストレージエンジンの概念があり、さまざまなストレージ要件に応じて最適なストレージエンジンを選択できます。ストレージエンジンは、データの保存、インデックスの構築、クエリデータの更新などのテクノロジの実装です。ストレージエンジンはライブラリベースではなくテーブルベースです。したがって、ストレージエンジンはテーブルタイプとも呼ばれます。Oracle や SqlServer などのデータベースには、ストレージエンジンが 1 つだけあります。MySQL はプラグインストレージエンジンアーキテクチャを提供します。したがって、MySQL には複数のストレージ
エンジンがあり、必要に応じて対応するエンジンを使用したり、ストレージエンジンを作成したりできます。MySQL5.0 でサポートされるストレージエンジンには、InnoDB、MyISAM、BDB、MEMORY、MERGE、EXAMPLE、NDB Cluster、
ARCHIVE、CSV、BLACKHOLE、FEDERATED などが含まれます。InnoDB と BDB はトランザクションセーフなテーブルを提供しますが、他のストレージエンジンは非対応です。 -トランザクションセーフなテーブル。show Engines を指定することで、現在のデータベースでサポートされているストレージエンジンをクエリできます。

新しいテーブルの作成時にストレージエンジンを指定しない場合、システムはデフォルトのストレージエンジンを使用します。MySQL 5.5 より前のデフォルトのストレージエンジンは MyISAM でしたが、5.5 以降は InnoDB に変更されました。
Mysql データベースのデフォルトのストレージエンジンを表示するには、次のコマンドを実行します。

 show variables like '%storage_engine%' ；

2.2 さまざまなストレージエンジンの特性
ここでは、一般的に使用されるいくつかのストレージエンジンの紹介に焦点を当て、次の表に示すように、各ストレージエンジンの違いを比較します。

2.2.1 InnoDB
InnoDB ストレージエンジンは、Mysql のデフォルトのストレージエンジンです。InnoDB ストレージエンジンは、コミット、ロールバック、クラッシュ回復機能によりトランザクションの安全性を提供します。ただし、MyISAM ストレージエンジンと比較すると、InnoDB の書き込みは効率が低く、データとインデックスを保持するためにより多くのディスク領域を消費します。InnoDB ストレージエンジンは他のストレージエンジンと異なります:
トランザクション制御

create table goods_innodb(
id int NOT NULL AUTO_INCREMENT,
name varchar(20) NOT NULL,
primary key(id)
)ENGINE=innodb DEFAULT CHARSET=utf8;

start transaction;
insert into goods_innodb(id,name)values(null,'Meta20');
commit;

外部キーの制約
MySQL で外部キーをサポートする唯一のストレージエンジンは InnoDB です。外部キーを作成するときは、親テーブルに対応するインデックスが必要です。子テーブルが外部キーを作成すると、対応するインデックスが自動的に作成されます。次の 2 つのテーブルでは、country_innodb が親テーブル、country_id が主キーインデックス、city_innodb テーブルが子テーブル、country_id フィールドが外部キーで、country_innodb テーブルの主キー country_id に対応します。

create table country_innodb(
country_id int NOT NULL AUTO_INCREMENT,
country_name varchar(100) NOT NULL,
primary key(country_id)
)ENGINE=InnoDB DEFAULT CHARSET=utf8;
create table city_innodb(
city_id int NOT NULL AUTO_INCREMENT,
city_name varchar(50) NOT NULL,
country_id int NOT NULL,
primary key(city_id),
key idx_fk_country_id(country_id),
CONSTRAINT `fk_city_country` FOREIGN KEY(country_id) REFERENCES
country_innodb(country_id) ON DELETE RESTRICT ON UPDATE CASCADE
)ENGINE=InnoDB DEFAULT CHARSET=utf8;
insert into country_innodb values(null,'China'),(null,'America'),(null,'Japan');
insert into city_innodb values(null,'Xian',1),(null,'NewYork',2),
(null,'BeiJing',1);

インデックスの作成時に、親テーブルの削除または更新時に子テーブルで実行される対応する操作 (RESTRICT、CASCADE、SET NULL、NO ACTION など) を指定できます。RESTRICT は NO ACTION と同じで、子テーブルに関連レコードがある場合は親テーブルを更新できないことを意味します。CASCADE は、親テーブルが更新または削除されると、子テーブルの対応するレコードが更新または削除されることを意味します。SET NULL は親テーブルが更新または削除されたことを意味し、更新または削除の場合、サブテーブルの対応するフィールドは SET NULL になります。
上記で作成した 2 つのテーブルでは、サブテーブルの外部キーの指定が ON DELETE RESTRICT ON UPDATE CASCADE になっているため、メインテーブルがレコードを削除する際、サブテーブルに対応するレコードがある場合は削除が許可されず、メインテーブルがレコードを削除することになります。テーブルがレコードを更新しているとき、サブテーブルに対応するレコードがある場合、サブテーブルもそれに応じて更新されます。
表のデータを以下に示します。

外部キー情報は、次の 2 つの方法で表示できます。

show create table city_innodb ;

country_id 1 の国データを削除します。

delete from country_innodb where country_id = 1;

update country_innodb set country_id = 100 where country_id = 1;

保存方法
InnoDB はテーブルとインデックスを次の 2 つの方法で保存します: ①. 共有テーブルスペースストレージを使用し、この方法で作成されたテーブルのテーブル構造は .frm ファイルに保存され、データとインデックスは .frmファイルで定義されたテーブルスペース
に保存されます。
innodb_data_home_dir および innodb_data_file_path は複数のファイルにすることができます。
②. マルチテーブルスペースストレージを使用すると、この方法で作成されたテーブルのテーブル構造は .frm ファイルに残りますが、各テーブルのデータとインデックスは .ibd に個別に保存されます
。

2.2.2 MyISAM
MyISAM はトランザクションも外部キーもサポートしていませんが、その利点は、アクセス速度が速いこと、トランザクションの整合性が要求されないこと、または SELECT および INSERT ベースのアプリケーションが基本的にこれを使用できることです
。テーブルを作成するエンジン。次の 2 つの重要な特徴があります。

トランザクションをサポートしていません


通过测试，我们发现，在MyISAM存储引擎中，是没有事务控制的 ；
1 update country_innodb set country_id = 100 where country_id = 1;
create table goods_myisam(
id int NOT NULL AUTO_INCREMENT,
name varchar(20) NOT NULL,
primary key(id)
)ENGINE=myisam DEFAULT CHARSET=utf8;

ファイルの格納方法
各 MyISAM はディスク上に 3 つのファイルとして格納され、ファイル名はテーブル名と同じですが、拡張子は .frm
(格納テーブル定義)、.
MYD(MYData, 格納データ)、.
MYI( MYIndex、ストレージインデックス);

2.2.3 MEMORY メモリ
ストレージエンジンはテーブルデータをメモリに保存します。各 MEMORY テーブルは、実際にはディスクファイルに対応します。形式は .frm です。このファイルにはテーブルの構造のみが格納され、そのデータファイルはメモリに格納されます。これにより、データの高速処理が可能になり、効率が向上します。テーブル全体の。MEMORY タイプのテーブルアクセスは、データがメモリに保存され、デフォルトで HASH インデックスが使用されるため、非常に高速ですが、サービスが終了すると、テーブル内のデータは失われます。

2.2.4 MERGE
MERGE ストレージエンジンは、MyISAM テーブルのグループの組み合わせです。これらの MyISAM テーブルは同じ構造を持つ必要があります。MERGE テーブル自体にはデータは格納されません。MERGE タイプのテーブルは、クエリ、更新、削除が可能です。これらのテーブルは、クエリ、更新、および削除が可能です。操作は実際には内部 MyISAM テーブルで実行されます。MERGE タイプのテーブルの挿入操作の場合、挿入されるテーブルは INSERT_METHOD 句によって定義され、3 つの異なる値を持つことができます。FIRST または LAST の値を使用して、それに応じて最初または最後のテーブルに対して挿入操作を実行します。この句を定義しないか、NO として定義されている場合は、この MERGE テーブルに対して挿入操作を実行できないことを示します。
MERGE テーブルに対して DROP 操作を実行できますが、この操作は MERGE テーブルの定義を削除するだけであり、内部テーブルには影響しません。

以下は MERGE テーブルの作成と使用の例です:
1). 3 つのテストテーブル order_1990、order_1991、order_all を作成します (order_all は最初の 2 つのテーブルの MERGE テーブルです)。

create table order_1990(
order_id int ,
order_money double(10,2),
order_address varchar(50),
primary key (order_id)

 分别向两张表中插入记录
3）. 查询3张表中的数据。
order_1990中的数据 ：
order_1991中的数据 ：
order_all中的数据 ：
)engine = myisam default charset=utf8;
create table order_1991(
order_id int ,
order_money double(10,2),
order_address varchar(50),
primary key (order_id)
)engine = myisam default charset=utf8;
create table order_all(
order_id int ,
order_money double(10,2),
order_address varchar(50),
primary key (order_id)
)engine = merge union = (order_1990,order_1991) INSERT_METHOD=LAST default
charset=utf8;

2). 2 つのテーブルにそれぞれレコードを挿入します。

insert into order_1990 values(1,100.0,'北京');
insert into order_1990 values(2,100.0,'上海');
insert into order_1991 values(10,200.0,'北京');
insert into order_1991 values(11,200.0,'上海');

3). 3 つのテーブルのデータをクエリします。

4). order_all にレコードを挿入します MERGE テーブル定義時に INSERT_METHOD で LAST が選択されるため、挿入されたデータは
最後のテーブルに挿入されます。

insert into order_all values(100,10000.0,'西安')；

2.3 ストレージエンジンの選択

        ストレージエンジンを選択するときは、アプリケーションシステムの特性に基づいて適切なストレージエンジンを選択する必要があります。複雑なアプリケーションシステムの場合は、実際の条件に応じて複数のストレージエンジンを選択して組み合わせることができます。以下は、一般的に使用されるいくつかのストレージエンジンの使用環境です。
        InnoDB: Mysql のデフォルトのストレージエンジンであり、トランザクション処理アプリケーションで使用され、外部キーをサポートします。アプリケーションのトランザクション整合性に対する要件が比較的高く、同時実行条件下でのデータの一貫性が必要であり、データ操作に挿入やクエリに加えて多くの更新操作や削除操作が含まれる場合は、InnoDB ストレージエンジンがより適切な選択肢です。InnoDB ストレージエンジンは、削除や更新によって引き起こされるロックを効果的に削減することに加えて、トランザクションの完全な送信とロールバックを保証することもできます。InnoDB は、請求システムや金融システムなど、高いデータ精度が必要なシステムに最適です。
        MyISAM: アプリケーションが主に読み取り操作と挿入操作に基づいており、更新操作と削除操作はわずかで、トランザクションの整合性と同時実行性の要件がそれほど高くない場合、このストレージエンジンの選択は非常に適しています。
MEMORY: すべてのデータを RAM に保存し、レコードやその他の同様のデータを迅速に見つける必要がある場合に複数のブロックにアクセスできるようにします。
        MEMORY の欠点は、テーブルのサイズに制限があることです。大きすぎるテーブルはメモリにキャッシュできません。第 2 に、テーブル内のデータを復元できることを確認する必要があります。テーブル内のデータデータベースが異常終了した後でも復元できます。MEMORY テーブルは通常、アクセス結果を迅速に取得するために更新頻度が低い小さなテーブルに使用されます。
        MERGE: 一連の同等の MyISAM テーブルを論理的に結合し、それらを 1 つのオブジェクトとして参照するために使用されます。MERGE テーブルの利点は、単一の MyISAM テーブルのサイズ制限を突破できることです。また、異なるテーブルを複数のディスクに分散することで、MERGE テーブルのアクセス効率を効果的に向上させることができます。これは、データウェアハウジングなどの VLDB 環境に非常に適しています。

3. SQLステップを最適化する

アプリケーション開発プロセスでは、初期のデータ量が少なかったため、開発者は SQL ステートメントを作成する際に機能実装に重点を置いていましたが、アプリケーションシステムが正式にリリースされると、本番データの量が急速に増加し、多くの SQL が必要になりました。ステートメントが徐々に現れ始めました。パフォーマンス上の問題は、本番環境への影響が増大します。現時点では、これらの問題のある SQL ステートメントがシステム全体のパフォーマンスのボトルネックになるため、最適化する必要があります。この章では、SQL を最適化する方法について詳しく紹介しますMySQL.メソッドのステートメント。SQL のパフォーマンスの問題を抱えたデータベースに直面した場合、問題の SQL をできるだけ早く特定し、問題をできるだけ早く解決するには、どこから体系的な分析を開始すればよいでしょうか。

3.1 SQL 実行頻度の表示
MySQL クライアントが正常に接続された後、show [session|global] status コマンドを使用してサーバーのステータス情報を提供できます。show[session|global] status 必要に応じてパラメータ「session」または「global」を追加して、セッションレベル (現在の接続) およびグローバルレベル (データベースの最後の起動以降) の統計結果を表示できます。書かれていない場合、デフォルトのパラメータは「session」です。次のコマンドは、現在のセッションのすべての統計パラメータの値を表示します。

show status like 'Com_______';

show status like 'Innodb_rows_%';

Com_xxx は各 xxx ステートメントの実行時間を示します。通常、次の統計パラメータを考慮します。

3.2 実行効率の低い SQL 文の特定
次の 2 つの方法で、実行効率の悪い SQL 文を特定できます。
スロークエリログ: スロークエリログを通じて、実行効率の低い SQL ステートメントを見つけます。 --log-slow-queries[=file_name] オプションで開始すると、mysqld は、実行時間が long_query_time 秒を超えるすべての SQL ステートメントを含むログファイルを書き込みます。。
show processlist : スロークエリログはクエリの完了後に記録されるため、アプリケーションが実行効率に問題があることを反映する場合、スロークエリログをクエリしても問題を特定できません。現在の MySQL スレッド (スレッドのステータス、テーブルをロックするかどうかなど) を含む SQL の実行ステータスをリアルタイムで確認し、一部のテーブルロック操作を最適化できます。

1) id 列、ユーザーが mysql にログインするときにシステムによって割り当てられる「connection_id」。関数 connection_id() を使用して表示できます。2)
user 列、現在のユーザーが表示されます。root でない場合、このコマンドはユーザーの権限の範囲内の SQL ステートメントのみを表示します。
3) ステートメントがどの IP ポートから送信されたかを示すホスト列を使用して、問題が発生したユーザーを追跡できます。 4) db列
には、プロセスが現在接続しているデータベースが表示されます。

5) コマンド列には、現在の接続で実行されたコマンドが表示されます。通常、値はスリープ、クエリ、接続などです。 6
)
時間列には、この状態の継続時間が秒単位で表示されます。
7) 状態列には、次の状態が表示されます。現在の接続を使用している SQL ステートメントのステータスは、非常に重要な列です。state は、ステートメント実行時の特定の状態を表します。SQLステートメント (クエリを例にとります) は、完了する前に、
tmp テーブルへのコピー、結果のソート、データの送信、およびその他の状態を通過する必要がある場合があります。8) 情報列には、SQL ステートメントが表示されます。これは、SQL ステートメントの重要な基礎です。問題文を判断すること。

3.3 Explain 分析の実行計画
上記の手順で非効率な SQL ステートメントをクエリした後、EXPLAIN または DESC コマンドを使用して、テーブルの接続方法や実行中の接続順序など、MySQL による SELECT ステートメントの実行方法に関する情報を取得できます。 SELECT ステートメントの。
SQL ステートメントの実行計画をクエリします。

explain select * from tb_item where id = 1;

explain select * from tb_item where title = '阿尔卡特 (OT-979) 冰川白 联通3G手机3';

フィールドの意味:

3.4 show profile分析SQL

Mysql は、バージョン 5.0.37 以降、show profile および show profile ステートメントのサポートを追加しました。show profile は、SQL を最適化するときにどこに時間がかかっているかを理解するのに役立ちます。have_profiling パラメータを通じて、現在の MySQL がプロファイルをサポートしているかどうかを確認できます。

プロファイリングはデフォルトでオフになっていますが、set ステートメントを使用してセッションレベルでプロファイリングをオンにすることができます。

1. MySQL アーキテクチャの概要

2. ストレージエンジン

3. SQLステップを最適化する

おすすめ