メニュー
Amazon Relational Database Service
ユーザーガイド (API バージョン 2014-10-31)

Amazon Aurora MySQL を使用する際のベストプラクティス

このトピックでは、Amazon Aurora MySQL クラスターの使用およびデータ移行のベストプラクティスとオプションについて説明します。

接続先の DB インスタンスの決定

次の例に示すように、innodb_read_only グローバル変数をチェックすることにより、Aurora MySQL DB クラスターのどの DB インスタンスを接続先にするかを決定できます。

SHOW GLOBAL VARIABLES LIKE 'innodb_read_only';

innodb_read_only 変数は、Aurora レプリカに接続する場合は ON、プライマリインスタンスに接続する場合は OFF に設定します。

この方法は、ワークロードを分散させるロジックや、書き込みオペレーションで適切な接続が使用されているかを確認するロジックを、アプリケーションコードに追加する場合に便利です。

T2 インスタンスの使用

DB インスタンスクラス (db.t2.small または db.t2.medium) を使用する Amazon Aurora MySQL インスタンスは、大量のワークロードを長時間にわたってサポートしないアプリケーションに最適です。T2 インスタンスは、適度なベースラインパフォーマンスを実現したり、ワークロードの必要に応じて非常に高いパフォーマンスまでバーストする機能を実現できるように設計されています。常時または一貫して CPU をフルに使用するわけではないが、バーストが必要なことがあるワークロード向けに用意されています。DB インスタンスクラス (db.t2.small および db.t2.medium) は開発サーバーおよびテストサーバー、または他の本稼働以外のサーバーに最適です。T2 インスタンスの詳細については「T2 インスタンス」を参照してください。

Amazon Aurora MySQL T2 インスタンスに対して MySQL パフォーマンススキーマを有効にしないでください。パフォーマンススキーマが有効な場合、T2 インスタンスはメモリ不足になることがあります。

Aurora MySQL DB クラスターのプライマリインスタンスまたは Aurora レプリカに対して T2 インスタンスクラスを使用する場合は、以下をお勧めします。

  • DB クラスターの DB インスタンスクラスとして T2 インスタンスを使用する場合は、同じ DB インスタンスクラスを DB クラスターのすべてのインスタンスで使用されることをお勧めします。たとえば、プライマリインスタンスに対して db.t2.medium を使用する場合は、Aurora レプリカに対しても db.t2.medium を使用されることをお勧めします。

  • CPU クレジットバランス (CPUCreditBalance) をモニタリングして、持続可能なレベルにあることを確認します。つまり、CPU のクレジットは使用されるのと同じレートで累積されています。

    インスタンス用の CPU クレジットが枯渇した場合、利用可能な CPU が急減するため、そのインスタンスに対する読み込みおよび書き込みレイテンシーが長くなります。この状況になると、インスタンス全体のパフォーマンスが大幅に低下します。

    CPU クレジットバランスが持続可能なレベルにない場合、DB インスタンスを、サポートされている R3 DB インスタンスクラス (コンピューティングのスケール) の 1 つを使用するように変更することをお勧めします。

    モニタリングメトリクスの詳細については、「Amazon Aurora DB クラスターのモニタリング」を参照してください。

  • Aurora MySQL DB クラスターのプライマリインスタンスと Aurora レプリカ間のレプリカラグ (AuroraReplicaLag) をモニタリングします。

    プライマリインスタンスの前で Aurora レプリカの CPU クレジットが枯渇すると、プライマリインスタンスの背後での遅延により Aurora レプリカが頻繁に再起動することになります。このような結果になるのは一般的に、アプリケーション側で負荷の高い読み取りオペレーションが Aurora MySQL DB クラスター内の Aurora レプリカ間に分散されるときに、プライマリインスタンス側で書き込みオペレーションの負荷が最小限に抑えられている場合です。

    レプリカラグの増加が持続している場合、DB クラスターの Aurora レプリカの CPU クレジットバランスが枯渇していないことを確認します。

    CPU クレジット残高が持続可能なレベルにない場合は、サポートされているいずれかの R3 DB インスタンスクラスを使用するように DB インスタンスを変更すること (コンピューティングのスケーリング) をお勧めします。

  • バイナリログが有効な DB クラスターのトランザクションあたりの挿入の数を 100 万以下に維持します。

    DB クラスターの DB クラスターパラメータグループで binlog_format パラメータを OFF 以外の値に設定している場合、DB クラスターに 1,000,000 行以上の挿入を含むトランザクションがあると、DB クラスターでメモリが不足することがあります。解放可能なメモリ (FreeableMemory) メトリクスをモニタリングして、DB クラスターで使用可能なメモリが不足しているかどうかを判断できます。その後、書き込みオペレーション (VolumeWriteIOPS) メトリクスをモニタリングして、プライマリインスタンスで書き込みオペレーションの負荷が高いかどうかを確認します。メモリが不足し、書き込みオペレーションの負荷が高い場合は、トランザクションの挿入数を 100 万未満に制限するようにアプリケーションを更新することをお勧めします。または、サポートされているいずれかの R3 DB インスタンスクラスを使用するようにインスタンスを変更すること (コンピューティングのスケーリング) もできます。

AWS Lambda 関数の呼び出し

Amazon Aurora バージョン 1.16 以降を使用している場合は、ネイティブ関数 lambda_synclambda_async を使用して Lambda 関数を呼び出すことをお勧めします。

非推奨の mysql.lambda_async プロシージャを使用している場合は、mysql.lambda_async プロシージャの呼び出しをストアドプロシージャにラップすることをお勧めします。このストアドプロシージャは、トリガーやクライアントコードなどさまざまなソースから呼び出すことができます。この方法により、インピーダンス不整合の問題を回避し、データベースプログラマーが Lambda 関数を簡単に呼び出せるようにすることができます。

Amazon Aurora からの Lambda 関数の呼び出しについて詳しくは、「Amazon Aurora MySQL DB クラスターからの Lambda 関数の呼び出し」を参照してください。

Amazon Aurora での Asynchronous Key Prefetch の使用

注記

Asynchronous Key Prefetch (AKP) 機能は Amazon Aurora MySQL バージョン 1.15 以降で使用できます。Aurora MySQL バージョンの詳細については、「Amazon Aurora MySQL データベースエンジンの更新」を参照してください。

Amazon Aurora で AKP を使用すると、インデックス間でテーブルを結合するクエリのパフォーマンスが向上することがあります。この機能は、JOIN クエリで Batched Key Access (BKA) 結合アルゴリズムと Multi-Range Read (MRR) 最適化機能が必要な場合、クエリの実行に必要な行を予測することで、パフォーマンスを向上させます。BKA と MRR の詳細については、MySQL ドキュメントの「Block Nested-Loop 結合と Batched Key Access 結合」および「Multi-Range Read の最適化」を参照してください。

AKP 機能を利用するには、クエリで BKA と MRR の両方を使用する必要があります。通常、このようなクエリは、クエリの JOIN 句でセカンダリインデックスを使用するが、プライマリインデックスからの一部の列を必要とする場合に発生します。たとえば、JOIN 句が小さい外部テーブルと大きい内部テーブル間のインデックス値の等価結合を表し、大きいテーブルに対するインデックスの選択性が高い場合に、AKP を使用できます。AKP は、BKA および MRR と連携し、JOIN 句の評価時にセカンダリからプライマリへのインデックスのルックアップを行います。AKP は、JOIN 句の評価時にクエリの実行に必要な行を特定します。次に、バックグラウンドスレッドを使用して、クエリの実行前に、これらの行を含むページを非同期的にメモリ内にロードします。

Asynchronous Key Prefetch の有効化

AKP 機能を有効にするには、MySQL サーバー変数 aurora_use_key_prefetchon に設定します。デフォルトでは、この値は on に設定されます。ただし、BKA 結合アルゴリズムを有効にして、コストベースの MRR 機能を無効にするまでは、AKP を有効にすることはできません。そのためには、MySQL サーバー変数 optimizer_switch に以下の値を設定する必要があります。

  • batched_key_accesson に設定します。この値は BKA 結合アルゴリズムの使用を制御します。デフォルトでは、この値は off に設定されます。

  • mrr_cost_basedoff に設定します。この値は、コストベースの MRR 機能の使用を制御します。デフォルトでは、この値は on に設定されます。

現在、これらの値はセッションレベルでのみ設定できます。次の例は、これらの値を設定し、SET ステートメントを実行して現在のセッションで AKP を有効にする方法を示しています。

mysql> set @@session.aurora_use_key_prefetch=on; mysql> set @@session.optimizer_switch='batched_key_access=on,mrr_cost_based=off';

同様に、SET ステートメントを使用して AKP と BKA 結合アルゴリズムを無効にし、現在のセッションでコストベースの MRR 機能を再度有効にすることができます。次に例を示します。

mysql> set @@session.aurora_use_key_prefetch=off; mysql> set @@session.optimizer_switch='batched_key_access=off,mrr_cost_based=on';

batched_key_access および mrr_cost_based オプティマイザスイッチの詳細については、MySQL ドキュメントの「切り替え可能な最適化の制御」を参照してください。

Asynchronous Key Prefetch のクエリの最適化

クエリで AKP 機能を利用できるかどうかを確認できます。そのためには、EXPLAIN ステートメントで EXTENDED キーワードを使用し、クエリをプロファイリングしてから実行します。EXPLAIN ステートメントは、指定されたクエリで使用する実行プランに関する情報を提供します。

EXPLAIN ステートメントの出力で、Extra 列は実行プランに含まれている追加情報を示します。AKP 機能の適用先がクエリで使用されているテーブルである場合、この列には次のいずれかの値が含まれます。

  • Using Key Prefetching

  • Using join buffer (Batched Key Access with Key Prefetching)

次の例では、EXPLAIN で EXTENDED を使用することで、AKP を利用できるクエリの実行プランを表示しています。

mysql> explain extended select sql_no_cache -> ps_partkey, -> sum(ps_supplycost * ps_availqty) as value -> from -> partsupp, -> supplier, -> nation -> where -> ps_suppkey = s_suppkey -> and s_nationkey = n_nationkey -> and n_name = 'ETHIOPIA' -> group by -> ps_partkey having -> sum(ps_supplycost * ps_availqty) > ( -> select -> sum(ps_supplycost * ps_availqty) * 0.0000003333 -> from -> partsupp, -> supplier, -> nation -> where -> ps_suppkey = s_suppkey -> and s_nationkey = n_nationkey -> and n_name = 'ETHIOPIA' -> ) -> order by -> value desc; +----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+ | 1 | PRIMARY | nation | ALL | PRIMARY | NULL | NULL | NULL | 25 | 100.00 | Using where; Using temporary; Using filesort | | 1 | PRIMARY | supplier | ref | PRIMARY,i_s_nationkey | i_s_nationkey | 5 | dbt3_scale_10.nation.n_nationkey | 2057 | 100.00 | Using index | | 1 | PRIMARY | partsupp | ref | i_ps_suppkey | i_ps_suppkey | 4 | dbt3_scale_10.supplier.s_suppkey | 42 | 100.00 | Using join buffer (Batched Key Access with Key Prefetching) | | 2 | SUBQUERY | nation | ALL | PRIMARY | NULL | NULL | NULL | 25 | 100.00 | Using where | | 2 | SUBQUERY | supplier | ref | PRIMARY,i_s_nationkey | i_s_nationkey | 5 | dbt3_scale_10.nation.n_nationkey | 2057 | 100.00 | Using index | | 2 | SUBQUERY | partsupp | ref | i_ps_suppkey | i_ps_suppkey | 4 | dbt3_scale_10.supplier.s_suppkey | 42 | 100.00 | Using join buffer (Batched Key Access with Key Prefetching) | +----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+ 6 rows in set, 1 warning (0.00 sec)

拡張された EXPLAIN 出力形式の詳細については、MySQL 製品ドキュメントの「EXPLAIN EXTENDED 出力フォーマット」を参照してください。

Amazon Aurora MySQL でのマルチスレッドレプリケーションスレーブの使用

デフォルトでは、Aurora MySQL DB クラスターをレプリケーションスレーブとして使用するときに、Aurora ではシングルスレッドレプリケーションを使用します。マルチスレッドレプリケーションについては、Amazon Aurora では禁止されていませんが、MySQL から Aurora MySQL に継承されたいくつかの問題があります。本番稼働用環境ではマルチスレッドレプリケーションを使用しないようお勧めします。マルチスレッドレプリケーションを使用する場合は、完全にテストした上で使用することをお勧めします。

Amazon Aurora におけるレプリケーションの使用の詳細については、「Amazon Aurora とのレプリケーション」を参照してください。

Amazon Aurora を使用した MySQL データベースの読み取りスケーリング

MySQL DB インスタンスで Amazon Aurora を使用することで、Amazon Aurora の読み取りスケーリング機能を活用して MySQL DB インスタンスの読み取りワークロードを拡張できます。Aurora を使用して MySQL DB インスタンスの読み取りを拡張するには、Amazon Aurora MySQL DB クラスターを作成し、MySQL DB インスタンスのレプリケーションスレーブに指定します。これは、Amazon RDS MySQL DB インスタンス、または Amazon RDS の外部で実行されている MySQL データベースに適用されます。

Amazon Aurora DB クラスターの作成については、「Amazon Aurora DB クラスターの作成」を参照してください。

MySQL DB インスタンスと Amazon Aurora DB クラスターの間でレプリケーションを設定するときは、以下のガイドラインに従ってください。

  • Amazon Aurora MySQL DB クラスターを参照するときは、Amazon Aurora DB クラスターのエンドポイントアドレスを使用します。フェイルオーバーが発生すると、Aurora MySQL DB クラスターのプライマリインスタンスに昇格された Aurora レプリカで、引き続きこの DB クラスターのエンドポイントアドレスが使用されます。

  • マスターインスタンスのバイナリログが Aurora レプリカに適用されたことを確認するまで、これらのバイナリログを保持します。このメンテナンスによって、障害発生時にマスターインスタンスを復元できます。

重要

自己管理型レプリケーションを使用する場合、ユーザー自身で発生する可能性のあるすべてのレプリケーションの問題をモニタリングし、解決する必要があります。詳細については、「リードレプリカ間の遅延の診断と解決」を参照してください。

注記

Amazon Aurora MySQL DB クラスターでレプリケーションを開始するために必要なアクセス権限は限定されており、Amazon RDS マスターユーザーは使用できません。このため、Amazon Aurora MySQL DB クラスターと MySQL DB インスタンスの間でレプリケーションをセットアップするには、Amazon RDS の mysql.rds_set_external_master コマンドと mysql.rds_start_replication コマンドを使用する必要があります。

外部のマスターインスタンスと Amazon RDS 上の MySQL DB インスタンス間でレプリケーションを開始する

  1. ソース MySQL DB インスタンスを読み取り専用にします。

    mysql> FLUSH TABLES WITH READ LOCK; mysql> SET GLOBAL read_only = ON;
  2. ソース MySQL DB インスタンスで SHOW MASTER STATUS コマンドを実行して、binlog の場所を特定します。以下の例のような出力を受け取ります。

    File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------
  3. mysqldump を使用して、外部の MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターにデータベースをコピーします。非常に大きなデータベースでは、「わずかなダウンタイムでの Amazon RDS MySQL または MariaDB DB インスタンスへのデータのインポート」の手順を使用することが必要になる場合があります。

    Linux、OS X、Unix の場合:

    mysqldump \ --databases <database_name> \ --single-transaction \ --compress \ --order-by-primary \ –u <local_user> \ -p <local_password> | mysql \ --host aurora_cluster_endpoint_address \ –-port 3306 \ –u <RDS_user_name> \ –p <RDS_password>

    Windows の場合:

    mysqldump ^ --databases <database_name> ^ --single-transaction ^ --compress ^ --order-by-primary ^ –u <local_user> ^ -p <local_password> | mysql ^ --host aurora_cluster_endpoint_address ^ –-port 3306 ^ –u <RDS_user_name> ^ –p <RDS_password>

    注記

    -p オプションと入力するパスワードの間にスペースがないことを確認します。

    mysql コマンドで、‐‐host‐‐user (-u)‐‐port–p オプションを使用して、Aurora DB クラスターに接続するためのホスト名、ユーザー名、ポート、パスワードを指定します。このホスト名は、Amazon Aurora DB クラスターのエンドポイントの DNS 名 (たとえば mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com) です。エンドポイントの値は、Amazon RDS マネジメントコンソールでクラスターの詳細を確認できます。

  4. もう一度ソース MySQL DB インスタンスを書き込み可能にします。

    mysql> SET GLOBAL read_only = OFF; mysql> UNLOCK TABLES;

    レプリケーションで使用するバックアップの作成の詳細については、MySQL のドキュメントの「読み取り専用にすることによるマスターまたはスレーブのバックアップ」を参照してください。

  5. Amazon RDS マネジメントコンソールで、ソース MySQL データベースをホストするサーバーの IP アドレスを、Amazon Aurora DB クラスターの VPC セキュリティグループに追加します。VPC セキュリティグループの変更方法の詳細については、『Amazon Virtual Private Cloud ユーザーガイド』の「VPC のセキュリティグループ」を参照してください。

    ソース MySQL インスタンスと通信できるようにするために、Amazon Aurora DB クラスターの IP アドレスからの接続を許可するようにローカルネットワークを設定することも必要になる場合があります。Amazon Aurora DB クラスターの IP アドレスを確認するには、host コマンドを使用します。

    host <aurora_endpoint_address>

    このホスト名は、Amazon Aurora DB クラスターのエンドポイントからの DNS 名です。

  6. 選択したクライアントを使用して、外部の MySQL インスタンスに接続し、レプリケーションに使用される MySQL ユーザーを作成します。このアカウントはレプリケーション専用に使用され、セキュリティを強化するためにドメインに制限する必要があります。次に例を示します。

    CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY '<password>';
  7. 外部の MySQL インスタンスについて、REPLICATION CLIENTREPLICATION SLAVE の特権をレプリケーションユーザーに付与します。たとえば、すべてのデータベースに対する REPLICATION CLIENT および REPLICATION SLAVE 権限を "repl_user" ユーザーに付与するには、以下のコマンドを実行します。

    GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY '<password>';
  8. レプリケーションを設定する前に、レプリケーションスレーブになる Aurora MySQL DB クラスターのスナップショットを手動で作成します。DB クラスターをレプリケーションスレーブとしてレプリケーションを再構築する必要がある場合は、このスナップショットから Aurora MySQL DB クラスターを復元でき、MySQL DB インスタンスから新しい Aurora MySQL DB クラスターにデータをインポートする必要はありません。

  9. Amazon Aurora DB クラスターをレプリカとして指定します。Amazon Aurora DB クラスターにマスターユーザーとして接続し、mysql.rds_set_external_master コマンドを使用して、ソース MySQL データベースをレプリケーションマスターとして指定します。ステップ 2 で特定したマスターログファイル名とマスターログの場所を使用します。次に例を示します。

    CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0);
  10. Amazon Aurora DB クラスターで、mysql.rds_start_replication コマンドを実行してレプリケーションを開始します。

    CALL mysql.rds_start_replication;

ソース MySQL DB インスタンスと Amazon Aurora DB クラスター間のレプリケーションが確立されると、Aurora レプリカを Amazon Aurora DB クラスターに追加できます。その後で、Aurora レプリカに接続してデータの読み取りを拡張できます。Aurora レプリカの作成については、「コンソールを使用した Aurora レプリカの作成」を参照してください。

Amazon Aurora を使用した MySQL データベースの災害対策

MySQL DB インスタンスで Amazon Aurora を使用することで、災害対策用のオフサイトバックアップを作成できます。MySQL DB インスタンスの災害対策に Aurora を使用するには、Amazon Aurora DB クラスターを作成し、MySQL DB インスタンスのレプリケーションスレーブに指定します。これは、Amazon RDS MySQL DB インスタンス、または Amazon RDS の外部で実行されている MySQL データベースに適用されます。

重要

MySQL DB インスタンスと Amazon Aurora MySQL DB クラスターの間でレプリケーションを設定する場合、レプリケーションは Amazon RDS によって管理されません。レプリケーションを監視して、レプリケーションが正常に動作していることを確認し、必要な場合は修復する必要があります。

Amazon Aurora MySQL DB クラスターを作成して MySQL DB インスタンスのレプリケーションスレーブに指定する方法については、「Amazon Aurora を使用した MySQL データベースの読み取りスケーリング」の手順に従ってください。

MySQL から Amazon Aurora MySQL への移行に伴うダウンタイムの短縮

ライブアプリケーションをサポートする MySQL データベースから Amazon Aurora MySQL DB クラスターにデータをインポートするときは、移行中のサービス中断時間を短縮することが必要になる場合があります。そのためには、「わずかなダウンタイムでの Amazon RDS MySQL または MariaDB DB インスタンスへのデータのインポート」で説明している手順を使用できます。この手順は、巨大なデータベースを使用する場合に特に役立ちます。この手順を使用すると、ネットワーク経由で AWS に渡されるデータの量を最小限に抑えることで、インポートのコストを削減できます。

この手順では、データベースのデータのコピーを Amazon EC2 インスタンスに送信し、そのデータを新しい Amazon RDS MySQL DB インスタンスにインポートするステップを示します。Amazon Aurora は MySQL と互換性があるため、ターゲット Amazon RDS MySQL DB インスタンスの代わりに Amazon Aurora DB クラスターを使用することができます。

Amazon Aurora MySQL での XA トランザクションの使用

Aurora MySQL では eXtended Architecture (XA) トランザクションは使用しないことをお勧めします。これは、XA が PREPARED 状態の場合、復旧時間が長くなる可能性があるためです。Aurora MySQL で XA トランザクションを使用する必要がある場合は、以下のベストプラクティスに従ってください。

  • XA トランザクションを PREPARED 状態で開いたままにしない。

  • XA トランザクションを可能な限り小さくする。

MySQL で XA トランザクションを使用する方法の詳細については、MySQL のドキュメントの「XA トランザクション」を参照してください。

Aurora MySQL でのハッシュ結合の使用

等価結合を使用して大量のデータを結合する必要がある場合は、ハッシュ結合によりクエリのパフォーマンスが向上することがあります。Aurora MySQL に対してハッシュ結合を有効にすることができます。

ハッシュ結合列には任意の複合式を使用できます。ハッシュ結合列では、以下のようなデータ型間での比較が可能です。

  • intbigintnumericbit などの厳密数値データ型のカテゴリ内で項目を比較できます。

  • floatdouble などの近似数値データ型のカテゴリ内で項目を比較できます。

  • 文字列型間で文字セットと照合が同じであれば、文字列型間で項目を比較できます。

  • 日付およびタイムスタンプデータ型間で、型が同じあれば、項目を比較できます。

注記

異なるカテゴリのデータ型間での比較はできません。

Aurora MySQL のハッシュ結合には、以下の制限が適用されます。

  • 左右外部結合はサポートされていません。

  • サブクエリが最初にマテリアライズされない限り、サブクエリなどの準結合はサポートされていません。

  • 複数テーブルの更新や削除はサポートされていません。

    注記

    単一テーブルの更新や削除はサポートされていません。

  • BLOB および空間データ型の列をハッシュ結合の結合列にすることはできません。

ハッシュ結合を有効にする

ハッシュ結合を有効にするには、MySQL サーバー変数 optimizer_switchon に設定します。optimizer_switch パラメータは、デフォルトでハッシュ結合の on に設定されています。以下の例に示しているのは、ハッシュ結合を有効にする方法です。

mysql> SET optimizer_switch='hash_join=on';

この設定では、オプティマイザーはコスト、クエリの特徴、リソースの可用性に基づいてハッシュ結合を選択します。コスト見積もりが正しくない場合に、オプティマイザーにハッシュ結合を選択させることができます。そのためには、MySQL サーバー変数 hash_join_cost_basedoff に設定します。以下の例に示しているのは、オプティマイザーにハッシュ結合を選択させる方法です。

mysql> SET optimizer_switch='hash_join_cost_based=off';

注記

現在 Aurora ラボモードでは、Aurora MySQL にハッシュ結合を使用する必要があります。Aurora ラボモードの詳細については、「Aurora ラボモード」を参照してください。

ハッシュ結合のクエリの最適化

クエリでハッシュ結合を利用できるかどうかを調べるには、最初に EXPLAIN ステートメントを使用してクエリのプロファイリングを行います。EXPLAIN ステートメントは、指定されたクエリで使用する実行プランに関する情報を提供します。

EXPLAIN ステートメントの出力で、Extra 列は実行プランに含まれている追加情報を示します。クエリで使用するテーブルにハッシュ結合が適用される場合、この列には以下のような値が含まれます。

  • Using where; Using join buffer (Hash Join Outer table table1_name)

  • Using where; Using join buffer (Hash Join Inner table table2_name)

以下の例に示しているのは、EXPLAIN を使用してハッシュ結合クエリの実行プランを表示する方法です。

mysql> explain SELECT sql_no_cache * FROM hj_small, hj_big, hj_big2 -> WHERE hj_small.col1 = hj_big.col1 and hj_big.col1=hj_big2.col1 ORDER BY 1; +----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+ | 1 | SIMPLE | hj_small | ALL | NULL | NULL | NULL | NULL | 6 | Using temporary; Using filesort | | 1 | SIMPLE | hj_big | ALL | NULL | NULL | NULL | NULL | 10 | Using where; Using join buffer (Hash Join Outer table hj_big) | | 1 | SIMPLE | hj_big2 | ALL | NULL | NULL | NULL | NULL | 15 | Using where; Using join buffer (Hash Join Inner table hj_big2) | +----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+ 3 rows in set (0.04 sec)

出力では、Hash Join Inner table はハッシュテーブルの構築に使用されるテーブルであり、Hash Join Outer table はハッシュテーブルの検証に使用されるテーブルです。

拡張された EXPLAIN 出力形式の詳細については、MySQL 製品ドキュメントの「EXPLAIN EXTENDED 出力フォーマット」を参照してください。

Aurora MySQL での外部キーの使用

foreign_key_checks 変数が 0 (オフ) に設定されている場合は、データ定義言語 (DDL) ステートメントを実行しないことを強くお勧めします。

外部キーの制約に一時的に違反する行を挿入または更新する必要がある場合は、以下の手順に従います。

  1. foreign_key_checks0 に設定します。

  2. データ操作言語 (DML) に変更を加えます。

  3. 完了した変更が外部キーの制約に違反していないことを確認します。

  4. foreign_key_checks1 (オン) に設定します。

さらに、外部キーの制約に関する以下のベストプラクティスに従います。

  • クライアントアプリケーションが init_connect 変数の一部として foreign_key_checks 変数を 0 に設定しないことを確認します。

  • mysqldump などの論理バックアップからの復元が失敗するか、または不完全な場合は、同じセッションで他のオペレーションを開始する前に、foreign_key_checks1 に設定されていることを確認します。論理バックアップの開始時に foreign_key_checks0 に設定されています。

関連トピック