回答:
show table statusテーブルで実行していて、Data_freeフィールドがibdata1ファイルサイズの大部分を占めている場合は、多くの無駄なスペースがある可能性があります。大量の挿入/削除が問題になります。これが当てはまり、一時的な挿入と削除がデータの大部分を占めている場合は、テーブルごとのファイルに適切なケースがあります。
ただし、これは自動的な「はい」ではありません。InnoDBファイル内の内部断片化については世界中で多くの話がありますが、ファイルごとのファイルとしてファイルシステムに配置すると、断片化がデータベースレベルではなくファイルシステムレベルに移動します。
InnoDBファイルは、ファイルではなくファイルシステムと考えてください。多くのファイルがある場合は、大きなファイルシステムが必要になります。
ほとんどの場合、ファイルシステムはテラバイト単位のデータと数えきれないほどの数のファイルを処理するためのスケールアップに非常に適しています。インデックス作成が不十分な問題（パフォーマンスに影響が出る前のディレクトリ内のファイル数の制限など）に遭遇することもありますが、最新のファイルシステムは、ほとんどの場合、テラバイトの範囲にうまく移行できます。
InnoDBは同じように機能します。データファイルのサイズは非常に大きくなる可能性があります。また、大きなファイルシステムと同様に、データのバックアップで問題が発生する可能性があります。ただし、ファイルシステムを複数のパーティションに分割しても問題が解決しないのと同様に、innodbを操作することもできません。innodb_file_per_tableを使用できますが、お勧めすることはほとんどありません。
あなたのファイルシステムと同じように、より良い答えは、内部で制限を知り、その中で機能することです。インデックスを理解し、適切に適用します。InnoDBを分割しようとしないでください。それは、そのためのものではありません。
私は建設的にコンセプトを伝えるのに苦労しているので、ここでは言葉がこれよりも優れていることを簡単に読みます。テラバイトはビッグデータではなく、ペタバイトはです。
お客様が数テラバイトのデータウェアハウスを実行していた本当に古いMySQLマーケティングスライドを覚えています。何年も前に。InnoDBまたはMyISAMのどちらでも機能します。これは、標準的なMySQLのものです。
15GBのデータベースを心配する必要はありません。
InnoDB free: 7364608 kB
ibdataファイルは縮小されません-最近いくつかのテーブルを削除したり、多数の行を削除したりした場合-構成内のinnodbはファイルシステムに空き領域を解放しません。私はあなたをお勧めします：
このようにして、innodbテーブル/データベースをドロップするたびにスペースを取り戻すことができます。関連するIDBファイルはすぐに削除されます。