ビッグデータ学習向けの高度な MYSQL-mysql チュートリアル-php.cn

ビッグデータ学習向けの高度な MYSQL

記事ディレクトリ

- 1.2 サーバーシステム
- 1.3 データベースストレージエンジン選択
- 1.4 データベースパラメータの構成
- 1.5 データベース構造設計とSQL文（重要なポイント）
- - 2.1.2 メモリ
  - - 2.1.2.2 ヒント
    - 2.1.2.3 メモリの選択方法
  ## 2.2 ディスク構成と選択
- 2.2.1 従来のマシンのハードディスクの使用
  - 2.2.2 RAID を使用して従来のマシンのハードディスクのパフォーマンスを強化する
  - 2.2.2.1 RAID とは
    - 2.2.2.2 RAID レベル
    - 2.2.2.2.1 RAID 0
      - 2.2.2.2.2 RAID 1
      - 2.2.2.2.3 RAID 5 - 共通 RAID グループ
      - 2.2.2.2.4 RAID 10 - 共通 RAID グループ
      - 2.2.2.3 RAID レベルの選択
    - 2.2.3 ソリッドステートストレージ SSD および PCIe カードの使用
    2.2.4 ネットワークストレージ NAS および SAN の使用
  - ##2.2.4.1 ネットワークストレージの使用シナリオ
  - 2.2.4.2 ネットワークパフォーマンスの制限
  - - 2.3 概要
- 5 MySQL アーキテクチャ
1 パフォーマンスに影響を与えるいくつかの側面

1.1 ハードウェアの側面

通常、パーソナルコンピュータの動作が遅いのは、コンピュータのハードウェアの問題 (通常は CPU、メモリ、ディスク IO、など、この問題はサーバーでも発生します。

1.2 サーバーシステム

一般にパソコンのオペレーティングシステムは Windows ですが、Windows システムのバージョンが異なればパフォーマンスが異なったり、特定のパラメータの設定により性能が異なったりすることがあります。性能の違い。これはサーバーシステムでも同様であり、パラメータ設定はサーバーのパフォーマンスにも影響します。

1.3 データベースストレージエンジンの選択

MySQL にはプラグインストレージエンジンがあり、さまざまなビジネスニーズに応じてさまざまなストレージエンジンを選択できます。

ストレージエンジンが異なれば、特性も異なります。

MyISAM: トランザクションとテーブルレベルのロックはサポートされません。

InnoDB: トランザクションレベルのストレージエンジン。行レベルのロックとトランザクション ACID 機能を完全にサポートします。

1.4 データベースパラメータの構成

ストレージエンジンが異なると、パラメータの構成も異なります。一部のパラメータはストレージエンジンに最小限の影響を与えますが、一部のパラメータは影響を与えません。パフォーマンスにおいて決定的な役割を果たします。したがって、選択したストレージエンジンとさまざまなビジネスニーズに基づいてパラメーターを最適化することも重要です。

1.5 データベース構造設計と SQL ステートメント (キーポイント)

データベース構造を設計するときは、データベース上でどのような SQL ステートメントを実行するかを考慮する必要があります。、テーブル構造をクエリして更新するこの方法でのみ、要件を満たすテーブル構造を設計できます。

遅いクエリの場合、これがパフォーマンス低下の主な原因であり、データベーステーブル構造の不合理な設計が原因です。このタイプの SQL は、プロジェクトがオンラインになるとデータベーステーブル構造を変更するのが難しいため、最適化が最も困難です。したがって、データベースのパフォーマンスの最適化に重点を置くのは次のとおりです。

データベーステーブル構造の設計

SQL ステートメントの準備と最適化
以下は各側面の詳細な説明です。

2.1 CPU リソースと利用可能なメモリサイズ

2.1.1 CPU の選択方法

通常、CPU を選択するとき、CPU の周波数とコア数の両方ができるだけ高いことを望みますが、コストやさまざまな要因により、CPU のみを選択せざるを得なくなることがよくあります。それらの中の一つ。では、最適なソリューションをどのように選択すればよいのでしょうか?したがって、CPU を購入する際には、次のようないくつかの問題に注意する必要があります。

アプリケーションは CPU に負荷をかけていますか?
- アプリケーションが CPU を大量に使用する場合、SQL 処理を高速化するには、明らかに more CPU ではなく、better CPU が必要です。
- 現在の MySQL では、duoCPU は同じ SQL の同時処理をサポートしていません。
システムの同時実行性はどれくらいですか?
- システムがより多くのスループットを必要とする場合、CPU の数が多いほど良いです。 CPU が 40 個あると仮定すると、同時に 40 個の SQL を処理できますか?
- データベース処理能力の測定: QPS、同時に処理される SQL の数を指します。ただし、この指標は 1 秒間に処理される SQL の数ですが、前のポイントで説明した同時処理はナノ秒の次元です。
- MySQL は通常、Web アプリケーションで使用され、同時実行の量が比較的大きいことが多く、このとき、CPU 周波数よりも CPU の数が重要です。
私たちが使用する MySQL のバージョン
- バージョン 5.0 より前の MySQL はマルチコア CPU を十分にサポートしておらず、システムに対する制限は非常に深刻でした。現在の 5.6 および 5.7 バージョンでは、マルチコア CPU のサポートが大幅に改善されました。したがって、より良いパフォーマンスを実現するには、最新バージョンの MySQL を使用することをお勧めします。
32 ビットまたは 64 ビットの CPU を選択しますか?
- 現在、サーバー CPU はデフォルトですべて 64 ビットアーキテクチャですが、システムの 64 ビットシステム上に 32 ビットサーバーバージョンがインストールされているかどうかを注意して確認してください。これはサーバーのパフォーマンスに重大な影響を与えます。。

2.1.2 メモリ

メモリのサイズは、データベースのパフォーマンスに直接影響します。現在、メモリはディスクよりもはるかに効率的です。したがって、データをメモリにキャッシュすると、サーバーのパフォーマンスが大幅に向上します。

2.1.2.1 一般的に使用される MySQL ストレージエンジン

一般的に使用されるストレージエンジンは、MyISAM と InnoDB の 2 つです。
MyISAM:
インデックスはメモリに保存され、データはハードディスクに保存されます。
ビッグデータ学習向けの高度な MYSQL
InnoDB:
インデックスとデータはメモリに保存されるため、データベースの運用効率が向上します。

2.1.2.2 ヒント

メモリは多いほど優れていますが、システムパフォーマンスへの影響は限定的です。
データベース内のデータが 100G の場合、128G 程度のメモリを選択すると最大のパフォーマンスが得られますが、このときすべてのデータがホットデータであればメモリにキャッシュされます。ただし、より大きなメモリを選択すると、オペレーティングシステムなどの他のサービスのパフォーマンスも向上するため、短期的にはメモリのアップグレードを検討する必要はありません。
メモリキャッシュ書き込み操作の場合、データベースへの負荷を軽減するために書き込みを遅らせることができます。
メモリはすでに読み取り操作を適切にサポートしており、書き込み操作もメモリ内で完了できます。最終的には、データをディスクに書き込む必要があります。ディスクへの書き込み操作を避けることはできませんが、遅延させることはできます。書き込み操作を実行し、複数の書き込みを 1 つの書き込みにマージして、データベースへの負荷を軽減します。データベースには同様の機能があり、複数の書き込み操作をキャッシュプール内の 1 つにマージし、最終的にディスクに書き込むことができます。

2.1.2.3 メモリの選択方法

マザーボードが最大周波数をサポートできるメモリを使用するようにしてください。
データベースのサイズに基づいてメモリを選択します。

2.2 ディスク構成と選択

メモリはデータベースのパフォーマンスに大きな役割を果たしますが、パフォーマンスに対する IO サブシステムの影響を無視することはできません。現在、一般的に次の 4 種類のディスクオプションを使用しています。

2.2.1 従来のマシンのハードドライブの使用

特徴: 大容量のストレージスペース、低価格、ほとんどの使用されている、最も一般的な、読み取りと書き込みが遅い

#ストレージ容量

伝送速度
アクセス時間
スピンドル速度
物理的サイズ

2.2.2 RAID を使用して従来のマシンのハードドライブのパフォーマンスを向上させる

##2.2.2.1 RAID

RAID とはディスク冗長性 Redundant Arrays of Independent Disks の略で、簡単に言うと、RAID の機能は、複数の小さな容量のディスクを組み合わせて、より大きな容量のディスクのグループにし、データの冗長性を提供してデータの整合性を確保することです。

#2.2.2.2 RAID レベル

##2.2.2.2.1 RAID 0

RAID 0 は最も初期の RAID モードであり、データストライピングとも呼ばれます。コンポーネントディスクアレイの中で 最も単純な形式であり、2 台以上のハードディスクのみが必要で、低コスト であり、ディスク全体のパフォーマンスとスループットを向上させることができます。 RAID 0 は冗長性やエラー回復機能を提供しませんが、実装コストは最も低くなります。ただし、データの回復と信頼性の要素を考慮すると、RAID 0 が最も高価な構成になります。これは、RAID 0 には冗長性がなく、データ損傷の可能性が単一ディスクの場合よりも高いためです。どのディスクでもデータが損傷するとデータが失われるためです。たとえば、3 つのディスクで構成される RAID 0 は、1 つのハードディスクよりも損傷する可能性が 3 倍高くなります。したがって、RAID 0 は、いつでも他のデータベースからクローンを作成できるスタンバイデータベースや、一度だけ使用する必要があるデータベースなど、単一のデータが失われることがない状況に適しています。

ビッグデータ学習向けの高度な MYSQL 簡単に言えば、RAID 0 は、ハードディスクを直列に接続して、次のような大きなディスクを形成することです。

また、同時プロセスでは、同等のディスクに達することができます。単一ハードドライブの 3 倍のパフォーマンス。

2.2.2.2.2 RAID 1

RAID 1 は

ディスクミラーリングとも呼ばれ、その原理は、あるディスクのデータを別のディスクにミラーリングすることです。 1 つのディスクへの書き込み中に、パフォーマンスに影響を与えることなくシステムの信頼性と修復可能性を最大限に確保するために、イメージファイルが別の制限されたディスクに生成されます。 RAID 0 との違いは、中央に等号が描かれていることです。両方のディスク上のデータは同じであり、優れた冗長性機能を備えていますが、その分コストが増加します。ディスク障害が発生した場合、正常に実行できますが、障害が発生したディスクを交換する必要があり、そうしないとシステムがクラッシュします。
新しいディスクを交換すると、データの同期に時間がかかり、データアクセスには影響しませんが、システムのパフォーマンスが低下します。ビッグデータ学習向けの高度な MYSQL RAID 1 は、多くの場合、良好な
read
パフォーマンスを提供し、異なるディスク間でデータを冗長化できるため、データの冗長性が非常に優れています。 RAID 1 は RAID 0 よりも読み取りに優れているため、ログや同様のタスクの保存に適しています。
2.2.2.2.3 RAID 5 - 共通 RAID グループ

RAID 5 は分散パリティディスクアレイとも呼ばれます。

データは分散パリティブロックを通じて複数のディスク

に分散されているため、ディスクデータに障害が発生した場合でもパリティブロックから再構築できます。ただし、2 つのディスクに障害が発生した場合、ボリューム全体のデータを回復することはできません。

各ディスクにはそれぞれ Dp、Cp、Bp、Ap があることがわかります。いずれかのディスクに問題がある場合は、データとパリティ値に基づいてディスクを再計算できます。他の 3 つのディスクのデータ。
RAID 0 および RAID 1 の場合、アレイ構成全体に必要な容量は 1 台のディスクのみであるため、これは最も経済的な冗長構成です。ビッグデータ学習向けの高度な MYSQL RAID 5 では、保存されたパリティ桁の値を計算するために各書き込みで 2 回の読み取りとディスク間での 2 回の書き込みが必要になるため、書き込みが遅くなります。ただし、ランダム読み取りとシーケンシャル読み取りはどちらも高速です。これは、パリティビットを計算する必要がないためです。したがって、RAID 5 は読み取り指向のデータベースサービスに適しています。
RAID 5 で発生する最大の問題は、ディスクに障害が発生した場合です。データを他のディスクに再割り当てする必要があり、ディスクのパフォーマンスに重大な影響を与えるため、次のような場合には RAID 5 を使用するのが最適です。再読。

2.2.2.2.4 RAID 10 - 一般的に使用される RAID グループ

RAID 10 はシャードミラーリングとも呼ばれます。最初にディスクで RAID 1 を実行し、次に 2 組の RAID 1 ディスクで RAID 0 を実行するため、読み取りと書き込みのパフォーマンスが高く、RAID 5 と比較して再構築が容易で高速です。

RAID 10 では、1 台のハードディスクが破損すると、読み取りおよび書き込みプロセス中に 2 つの隣接するディスクが同時に読み取られる可能性があるため、パフォーマンスに重大な影響を及ぼします。が破損すると、単一のディスクからのみ読み取りが可能になるため、最悪の場合、パフォーマンスが 50% 低下します。

2.2.2.3 RAID レベルの選択

##RAID 0安価、高速、危険NoNfastfastRAID 1高速読み取り、シンプルそして安全はい2高速低速RAID 5セキュリティとコストのトレードオフhasN 1fast最も遅いディスクに応じて #RAID 10 高価、高速、安全Have2Nfastfast#

2.2.3 ソリッドステートストレージ SSD および PCIe カードの使用

ソリッドステートストレージはフラッシュメモリとも呼ばれます。
機能:

メカニカルディスクと比較して、ソリッドステートディスクはランダム読み取りおよび書き込みパフォーマンスが優れています。
メカニカルディスクと比較して、ソリッドステートディスクは同時実行性のサポートが優れています。
メカニカルディスクと比較して、ソリッドステートディスクは損傷を受けやすいです

SSD の機能:

SATA インターフェイスを使用すると、従来のディスクは
SATA インターフェース SSD は RAID テクノロジーもサポート

#ソリッドステートストレージ PCIe カードの機能:

SATA インターフェースは使用できません独自のドライバーと構成が必要です
価格は SSD より高価ですが、パフォーマンスは SSD より優れています

ソリッドステートストレージの使用シナリオ

大量のランダム I/O シナリオがある状況に適しています
# シングルスレッド負荷の I/O ボトルネックを解決するために使用します

#2.2.4 ネットワークストレージ NAS と SAN を使用する

SAN (ストレージエリアネットワーク) と NAS (ネットワーク接続ストレージ) は、外部ファイルストレージデバイスをサーバーにマウントする 2 つの方法です。

SAN: SAN 装置は光ファイバーでサーバーに接続されており、ブロックインターフェースを介してアクセスされ、サーバーはハードディスクとして使用できます。

ビッグデータ学習向けの高度な MYSQL SAN の特性:

NAS: NAS デバイスは、NFS や NFS などのファイルベースのプロトコルを介したネットワーク接続を使用します。 SMB でアクセスします。

2.2.4.1 ネットワークストレージを使用するシナリオ

データベースのバックアップに適しています。

2.2.4.2 ネットワークパフォーマンスの制限

ネットワークパフォーマンスの制限は、主に遅延と帯域幅です。

2.2.4.3 ネットワークがパフォーマンスに及ぼす影響

ネットワーク品質がパフォーマンスに及ぼす影響
推奨事項:
- 複数のネットワークカードをバインドして可用性と帯域幅を強化します
- ネットワークをできるだけ分離します可能な限り

2.3 概要

CPU:

#同時実行性が比較的高いシナリオの場合、周波数よりも CPU の数が重要です
CPU 集中型のシナリオや複雑な SQL の場合、周波数が高いほど良い

メモリ:

#マザーボードが使用できる最高周波数のメモリを選択してください

メモリのサイズはパフォーマンスにとって非常に重要であるため、できるだけ大きくします
I /O サブシステム:

PCIe -> SSD -> RAID10 -> ディスク -> SAN

3 オペレーティングシステムのパフォーマンスへの影響

MySQL に適したオペレーティングシステム: Windows、FreeBSD、Solaris、Linux

3.1 CentOS システムパラメーターの最適化

カーネル関連パラメータ (/etc/sysctl.conf)

net.core.somaxconn = 65535
リスニング状態のポートには独自のリスニングキューがあり、このパラメータは各ポートの最大リスニングキューを決定します。このパラメータのデフォルト値は比較的小さい場合があり、大規模なサーバーには十分ではありませんが、通常は 2048 以上の値に変更されます。
net.core.netdev_max_backlog=65535
##net.ipv4.tcp_max_syn_backlog=65535 backlog パラメーターは、各ネットワークインターフェイスで受信されるデータの量を決定します。パケットレートがカーネルプロセッサよりも速い場合、キューに送信できるパケットの最大数、および別のパラメータによって、相手側の接続をまだ取得していないリクエストをキューに保存できるかどうかが決まります。番号。この値を超える接続は破棄される可能性があるため、同時にサイズを大きくしてください。
net.ipv4.tcp_fin_timeout = 10 このパラメータは、TCP 接続処理の待機状態のタイムアウトを制御するために使用されます。比較的頻繁に接続するシステムでは、通常、多数の接続が待機状態にありますが、このパラメータの設定は、接続タイムアウト時間を短縮し、TCP リサイクルを高速化することを目的としています。 TCP 接続に影響を与える次の 2 つのパラメータもあります:

net.ipv4.tcp_tw_reuse = 1、net.ipv4.tcp_tw_recycle = 1 これら 3 つこれらのパラメータは主にＴＣＰリサイクルを高速化するためのものであり、高負荷システムではＴＣＰコネクションが満杯になるとデータベース５００への接続エラーが発生するため、これら３つのパラメータは非常に有用である。
net.core.wmem_default = 87380、net.core.wmem_max = 16777216、net.core.r0mem_default = 87380、net.core.rmem_max = 16777216 上記の 4 つのパラメータは、TCP 接続の受信および送信バッファサイズのデフォルト値と最大値を決定します。データベースの場合、これらのパラメータの値を少し大きく調整する必要があります。
net.ipv4.tcp_keepalive_time = 120、net.ipv4.tcp_keepalive_intvl = 30、net.ipv4.tcp_keepalive_probes = 3上記の 3 つのパラメーターは、失敗した接続によって占有される TCP システムリソースの量を減らし、リソースのリサイクルの効率を高めるために使用されます。
net.ipv4.tcp_keepalive_time は、tcp が tcp_keepalive 検出メッセージを送信する時間間隔を表します。秒単位。TCP 接続が有効かどうかを確認するために使用されます。 net.ipv4.tcp_keepalive_intvl は、tcp 接続が応答しないことを検出した後、数秒以内に検出メッセージを再送信するために使用されます。net.ipv4.tcp_keepalive_probes は、tcp 接続が認識されていることを示します失敗する前に送信する必要がある tcp_keepalive プローブメッセージの数。これら 3 つのパラメータのデフォルト値は通常のシステムには少し大きすぎるため、ここでは小さな値に変更します。
kernel.shmmax = 4294967295 このパラメータは、Linux カーネルパラメータの中で最も重要なパラメータの 1 つであり、単一の共有メモリセグメントの最大値を定義するために使用されます。

Note:
- この値のサイズは 64 ビット Linux システム用です。可能な最大値は物理メモリ値 - 1 バイトです。推奨値は物理メモリセグメントの半分より大きくなります。一般に、これは次のとおりです。 Innodb バッファプールのサイズよりも大きく、物理メモリ - 1 バイトを使用できます。
vm.swappiness = 0 このパラメータは、メモリが不十分な場合のパフォーマンスに大きな影響を与えます。このパラメータは、仮想メモリが完全にいっぱいでない限り、Linux システムカーネルにスワップ領域を使用しないように指示します。

Linux システムメモリスワップパーティション : Linux システムをインストールすると、
システムスワップパーティション と呼ばれる 特別なディスクパーティション が作成されます。 free -m を使用してシステムを表示すると、次のような内容が表示されます。swap はスワップパーティションです。オペレーティングシステムに十分なメモリがない場合、オペレーティングシステムは仮想メモリをディスクのスワップ領域 に書き込み、メモリスワップが発生します。 MySQL サービスが配置されている Linux システム上のスワップパーティションを完全に無効にすると、次の 2 つのリスクが生じます。
- メモリオーバーフロー
- 、 クラッシュ 、または オペレーティングシステムによって強制終了されました

limit.conf
このファイルは、実際にはプラグイン認証モジュールである Linx PAM の構成ファイルです。 より重要なパラメータ設定の 1 つは、開いているファイルの数の制限です。

結論: 開いているファイルの数を 65535 に増やして、十分なファイルハンドルを開くことができるようにします。ビッグデータ学習向けの高度な MYSQL 注: このファイルへの変更を有効にするには、再起動する必要があります。

ディスクスケジューリングポリシー (/sys/block/devname/queue/scheduler)
コマンド cat /sys/block/sda/queue/scheduler を使用して、によって使用されるスケジューリングポリシーを表示できます。現在のディスク。次の noop 予想期限 [cfq] は、システムのデフォルトの cfq スケジューリングポリシーです。
MySQL データベースサービスでは、cfq は、MySQL の作業プロセス中にキューに不要なリクエストを挿入し、応答時間が低下するため、適切ではありません。
ビッグデータ学習向けの高度な MYSQL
cfq スケジュール戦略に加えて、次の戦略もあります。
noop (エレベータースケジュール戦略):

Deadline (デッドラインスケジュール戦略):

anticipatory (予測 I/O スケジューリングポリシー):
ビッグデータ学習向けの高度な MYSQL
次のコマンドを入力して、ディスクスケジューリングポリシーを変更できます:
echo スケジューラ名 &gt ; / sys/block/sda/queue/scheduler
例: エコー期限 > /sys/block/sda/queue/scheduler

4ファイルシステムペアパフォーマンスへの影響

XFS ファイルシステムを使用することをお勧めします。次のパラメータを EXT3 および EXT4 で設定する必要があります:
ビッグデータ学習向けの高度な MYSQL
ファイルシステムペアのマウントパラメータEXT3/4 システム (/etc/fstab ):

data=writeback | requested |journal
このパラメータには 3 つのオプションの値、writeback があります。メタデータのみが書き込まれることを意味します。ログを入力するとき、メタデータの書き込みとデータの書き込みは同期されません。これは最も高速な構成であり、InnoDB には元々独自のトランザクションログがあるため、通常は InnoDB にとって最良の選択です。 ordered はメタデータのみを記録しますが、一貫性の保証を提供します。メタデータを書き込む前に、一貫性を保つためにデータが最初に書き込まれます。このオプションは writeback よりもわずかに遅くなりますが、衝突した方が安全です。 journal データが最終ログに書き込まれる前にログに記録されるアトミックログの動作を提供します。このオプションは明らかに InnoDB には不要であり、3 つのオプションの中で最も遅いです。
noatime、nodiratime
これら 2 つのオプションは、ファイルのアクセス時間とディレクトリの読み取り時間を記録するために使用されます。これら 2 つのパラメータを設定すると、書き込み操作の一部を減らすことができます。システムは、ファイルとディレクトリを読み取るときに、上記の 2 回を記録する操作を記述する必要はありません。
ファイル /dev/sda1/ext4 内の構成の一部を次に示します。
noatime,nodiratime,data=writeback 1 1

#5 MySQL アーキテクチャ

アーキテクチャの最上位層はクライアントと呼ばれ、この層は、PHP、JAVA、C などの mysql 接続プロトコルを通じて mysql に接続できるクライアントを表します。 API、.Net、ODBC、JDBC など。ここから、この層は mysql アーキテクチャに固有のものではないことがわかります。ほとんどの CS アーキテクチャサービスはこのアーキテクチャを採用しています。この層は主に、接続処理、認可認証、セキュリティなどのいくつかの機能を完了します。 mysql に接続されている各クライアントには、サーバープロセスにスレッドがあります。この接続のクエリは、このスレッドでのみ実行されます。前述したように、各接続クエリは 1 つの CPU コアのみを使用します。

次に、このシステムの 2 番目の層では、次の図に示すように、ほとんどの mysql コアサービスがこの層にあります。

ビッグデータ学習向けの高度な MYSQL 一般的に使用される DDL または DML ステートメントは、このレイヤーで定義されます。ただし、1 つだけ覚えておく必要があるのは、この層はサービス層とも呼ばれるため、すべてのクロスストレージエンジン機能はこの層に実装されるということです。
私たちの構造システムの 3 番目の層はストレージエンジン層です。MySQL は非常に優れたオープンソースデータベースであり、一連のストレージエンジンインターフェイスを定義しています。ストレージエンジンの要件を満たす限り、MySQL を開発できます。一般的に使用されている InnoDB など、ニーズを完全に満たすストレージエンジンを考え出します。現在、次の図に示すように、mysql でサポートされているストレージエンジンが多数あります。
: ストレージエンジンこれはライブラリではなくテーブル用です (ライブラリ内の異なるテーブルは異なるストレージエンジンを使用できます)
以下では、簡単な説明のために一般的に使用されるストレージエンジンをいくつか選択します。データベースのパフォーマンスは直接影響しますので、ストレージエンジンを使用する前に、ストレージエンジンの特性のいくつかをよく理解していただければ幸いです。ビッグデータ学習向けの高度な MYSQL