なぜinnodb_file_per_tableを使用するのですか？
innodb_file_per_tableの必要性を誇張している記事はたくさんあります（もちろんIMHO）。 innodb_file_per_tableを使用すると、個々のテーブルをより適切に制御できるはずです。各テーブルを個別にバックアップするように。ただし、パフォーマンスの向上に対する主張には疑問があります。
私のテストでは、60GBのデータベースのinnodb_file_per_tableとibdata1のパフォーマンスに違いはありません。もちろん、これは通常のクエリを使用した単純なテストであり、実際の複雑なクエリでは状況が異なる場合があります（これが私がこの質問をした理由です）。 ext4を備えた64ビットLinuxは、大きなファイルを効果的に処理できます。
innodb_file_per_tableを使用すると、より多くのディスクI/O操作が必要になります。これは、複雑なJOINsおよびFOREIGN KEY制約で重要です。
テーブルスペースは単一のibdataで共有されます。個別のテーブル専用のテーブルスペースがディスクスペースをどのように節約できるか？もちろん、ALTERを使用して各テーブルのテーブルスペースを解放する方が簡単ですが、それでも（テーブルロックを使用して）負荷の高いプロセスです。
質問：innodb_file_per_tableは、mysqlのパフォーマンスに影響を与えますか？はいの場合、なぜですか？
パフォーマンスの問題ではなく、管理の問題だと思います。
テーブルごとに個別のファイルを使用すると、たとえば、さまざまなデータベースをさまざまなストレージデバイスに保存できます。
大きなファイルを処理できないファイルシステム内の非常に大規模なデータベースの場合に対処できます（少なくとも、1つのテーブルがファイルサイズの制限に達するまで問題を延期します）。
制御されていないテーブルスペースの増加はありません。大きなテーブルをいくつかドロップすると、ibdataファイルは小さくなります。
パフォーマンスに何らかの影響を与える可能性のある側面の1つは、テーブルデータとインデックスの断片化であり、テーブルごとに制限されます。ただし、テストを確認する必要があります。
これが常にinnodb_file_per_tableを使用する私の理由です。
テーブルごとのファイルがない場合、ibdataファイルは決してスペースを圧縮または縮小または縮小しません。行を削除したり、テーブルやデータベースを削除したりするときではありません。アクティブなキューシステムがある場合、2 GBのデータはすぐに20 GBのファイルになる可能性があります。
変更の前に現在の1GBテーブルのバックアップを作成し、後で削除するとします。 ibdataに未使用のGBスペースが残っています。残念。
一時的な措置が単一のデータファイルを膨らませる例はおそらく無限にありますが、私の意見では、innodb_file_per_tableを使用しない理由は決してない、と言って十分です
また、ここに読むのに適した投稿があります： http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table
innodb_file_per_tableを使用しないにする理由はパフォーマンスです。
Mysql 5.5.45 Linux CentOSリリース6.7で450テーブルを含むデータベースのテストをいくつか行いました
ユニットテストの場合、各テストの前にフィクスチャをデータベースに挿入し（毎回すべてのテーブルを使用するわけではありません）、データベース自体で多くのテスト（挿入、更新、削除、選択）も行いますパフォーマンスは3〜5倍向上しましたデータベーステーブルがより多くのファイルに分割されなかった場合。
Innodb_file_per_tableを使用する前に、使用するクエリでデータベースをテストして比較することをお勧めします
本番サーバーではinnodb_file_per_tableを使用できますが、単体テストを開始する（統合を継続する）CI環境では（DBを頻繁に使用します）、単体テストを頻繁に開始する開発者は、パフォーマンスのためにそれを使用しない方がよいことがわかります。
以下の記事にあるように、パフォーマンスはデータの管理（クラス操作自体）ではなく、オブジェクトの作成と削除に関するものです。
innodb_file_per_tableを使用すると、大量のオブジェクトの作成と削除がibdataストレージよりも遅くなり、本番環境には適用できませんが、継続的なテストには関連性があります。
https://www.percona.com/blog/2015/02/24/mysqls-innodb_file_per_table-slowing/
未使用のスペースを再利用できるため、データが管理しやすくなります。これは素晴らしいことです。
データベースが主に選択クエリに使用されている場合、パフォーマンスにはあまり影響しないと思います。それでも、同じ量のデータを読み取る必要があります。データの読み取り元のファイルはそれほど重要ではないと思います。
ただし、多くの挿入と更新を行うデータベースでは、パフォーマンスが低下する可能性があります。これは、トランザクションをコミットした後、mysqlがストレージファイルに対してfsync（）を呼び出すためです。ファイルが1つしかない場合は、1つの呼び出しを行い、呼び出しが完了するのを待ちます。多くのファイルがある場合、commitコマンドが戻る前に、呼び出しを複数回行い、それらすべての呼び出しが戻るのを待つ必要があります。
これは、この問題が発生した人からの投稿です： http://umangg.blogspot.com/2010/02/innodbfilepertable.html
私見では、innodb_file_per_tableを使用するほうが安全です。それを使用しない場合、4 GBのファイルしか許可されていないFAT32システムで問題が発生する可能性があります。私はそれについてスロバキア語で記事を書きました（ https://www.itsoft.sk/preco-sa-neuvolni-miesto-na-disku-po-zmazani-mysql-tabulky/ ）。