innodb_file_per_table を使用する理由

パフォーマンスの問題ではなく、管理の問題だと思います。

テーブルごとに個別のファイルを使用すると、たとえば、さまざまなデータベースをさまざまなストレージデバイスに格納できます。

大きなファイルを処理できないファイルシステム内の非常に大きなデータベースのケースに対処できます (少なくとも、1 つのテーブルがファイルサイズの制限に達するまで問題を延期します)。

制御不能なテーブルスペースの増加はありません。ドロップする大きなテーブルがいくつかある場合は、 ibdata ファイルは小さいままです。

パフォーマンスに何らかの影響を与える可能性のある側面の 1 つは、テーブルデータとインデックスの断片化です。これは、テーブルごとに制限されます。しかし、それを確認するにはテストが必要です.

<ブロック引用>

innodb_file_per_table を使用する理由

ファイルレベルでできるので、個別に管理しやすいからです。これは、サーバーがダウンしていても、テーブルファイルをコピーすることでデータをコピーできることを意味しますが、共有テーブルスペースを使用することはすべてをコピーすることを意味します。これは不必要に大規模になるか、サーバーを稼働させてデータを抽出する方法を見つける必要があります (16 進エディターを使用して手動でデータを抽出することは本当に望ましくありません)。

.ibd を単純にコピーして貼り付けることはできないと誰かが警告しましたあるサーバーから別のサーバーへのファイル。これは正しいかもしれませんが、同じサーバー上のバックアップには当てはまりません (バックアップ という用語を使用しています) ここでは、コピーを作成するという伝統的な意味で。つまり、全体を大幅に変更するわけではありません)。また、ibdata1 起動時に自動的に再作成されます (delete ibdata1 で見られるように) ほとんどの「file-per-table への変換」ガイドのステップ)。そのため、あなたはしない ibdata1 をコピーする必要があります .ibd に加えてファイル (およびそれらに対応する .frm などのファイル)。

失われたテーブルを回復しようとする場合は、その .ibd をコピーするだけで十分です。と .frm ファイル、および information_schema (これは多く ibdata1 より小さい）。そうすれば、それらをダミーサーバーに配置して、大規模なもの全体をコピーすることなくテーブルを抽出できます。

<ブロック引用>

ただし、パフォーマンスが向上するという主張には疑問があります。 … innodb_file_per_table では、より多くのディスク I/O 操作が必要です。これは、複雑な JOIN および FOREIGN KEY 制約で重要です。

当然のことながら、パフォーマンスは使用中の特定のデータベースに完全に依存します。人によって結果が (場合によっては大幅に) 異なります。

file-per-table を使用するとディスク I/O 操作が増えるのは事実ですが、わずか です。もっと。システムがどのように機能するかを考えてください。

モノリシックデータベースの場合:
<オール>
サーバーが開始されました
ibdata1 開かれています
ヘッダーとメタデータが読み取られます
構造とメタデータはメモリにキャッシュされます
クエリが発生する <オール>
サーバーはディスクにアクセスし、すでに開いている ibdata1 からデータを読み取ります
サーバーはデータをメモリにキャッシュする場合があります
テーブルごとのデータベースの場合:
<オール>
サーバーが開始されました
ibdata1 開かれています
ヘッダーとメタデータが読み取られます
各個人 .ibd ファイルが開かれます
ヘッダーとメタデータは各 .ibd から読み取られますファイル
構造とメタデータはメモリにキャッシュされます
クエリが発生する <オール>
サーバーはディスクにアクセスし、すでに開いている .ibd からデータを読み取りますファイル
サーバーはデータをメモリにキャッシュする場合があります

サーバーの実行中は、サーバーがデータファイルへのハンドルを開いているため、データファイルを移動できないことがわかります。これは、起動時にそれらを開き、開いたままにするためです。個々のクエリごとに開いたり閉じたりするわけではありません。

そのため、サーバーが起動する最初の I/O 操作だけがあります。実行中ではありません。さらに、個々の .ibd ファイルには独自の個別のオーバーヘッド (ファイル署名、構造など) があり、それらはメモリにキャッシュされ、クエリごとに再読み取りされることはありません。さらに、共有テーブルスペースを使用しても同じ構造が読み取られるため、必要なメモリが (あったとしても) ほとんど必要ありません。

<ブロック引用>

innodb_file_per_table は mysql のパフォーマンス向上に影響しますか?

実際、どちらかといえば、パフォーマンスは実際には悪いかもしれません .

共有テーブルスペースを使用する場合、サーバーが ibdata から一度に複数のテーブルからデータの見本を読み取るように、読み取り操作と書き込み操作を組み合わせることができます。 .

ただし、データが複数のファイルに分散している場合は、各ファイルに対して個別に個別の I/O 操作を実行する必要があります。

もちろん、これも問題のデータベースに完全に依存しています。実際のパフォーマンスへの影響は、サイズ、クエリの頻度、および共有テーブルスペースの内部断片化によって異なります。大きな違いに気付く人もいれば、まったく影響を感じない人もいます。

<ブロック引用>

テーブルスペースは単一の ibdata で共有されます。個別のテーブル専用のテーブルスペースはどのようにディスク容量を節約できますか?

そうではありません。どちらかといえば、増える ディスク使用量が多少あります。

テスト用の 60GB のデータベースはありませんが、WordPress のインストールと、個人使用および開発テスト用のいくつかの小さなテーブルを含む「わずかな」個人用データベースは、共有テーブルスペースを使用している間、約 30MB の重さでした。 file-per-table に変換した後、最大 85 MB に肥大化しました。すべてを落として再インポートしても、まだ 60MB を超えていました。

この増加は、次の 2 つの要因によるものです。

絶対最小 ibdata1 のサイズ information_schemaしかない場合でも、何らかの理由で10MBです
共有テーブルスペースでは、ibdata1 のみファイル署名、メタデータなどのオーバーヘッドがありますが、テーブルごとに、個々の .ibd ファイルにはそれがすべて含まれています。これは、合計 (たとえ <10MB ibdata1 ) は、少なくとも次の分だけ多少大きくなります:
```
GetTotalSizeofOverhead() * GetNumTables()
```

明らかに、これらは巨大にはなりません。増加します (データベースのサイズを制限するホストを使用したり、フラッシュドライブに保存したりしない限り)、それでも増加します。 ) table to file-per-table ibdata1 を縮小できます 10MB まで、全体の合計は常に それ以上 になります。

これが、常に innodb_file_per_table を使用する理由です:

テーブルごとのファイルがなければ、ibdata ファイルが圧縮、縮小、またはスペースを縮小することはありません。行を削除したり、テーブルやデータベースを削除したりするときではありません。アクティブなキューイングシステムがある場合、2GB のデータがすぐに 20GB のファイルになる可能性があります。

変更前に現在の 1GB テーブルのバックアップを作成し、後で削除するとします。 ibdata に GB の未使用スペースが残っています。残念。

一時的な手段によって単一のデータファイルが膨張する例はおそらく無限にありますが、私の意見では、innodb_file_per_table を使用しない理由はないと言うだけで十分です

また、こちらの記事もおすすめです:http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table