事実
を使用していると言いましたext4。ファイルサイズの制限は16TBです。したがって、Sample.ibdいっぱいにしないでください。
あなたはあなたinnodb_data_file_pathが言ったibdata1:10M:autoextend。したがって、ibdata1ファイル自体には、OSを除き、そのサイズの上限はありません。
このメッセージが表示されるのはなぜですか？「ディスク...がいっぱいです」ではなく、「テーブル...がいっぱいです」というメッセージに注意してください。このテーブルの完全な状態は、論理的な観点からのものです。InnoDBについて考えてください。どのような相互作用が起こっていますか？
私の推測では、InnoDBは93GBのデータを単一のトランザクションとしてロードしようとしています。Table is Fullメッセージはどこから発信されますか？ibdata1は、その物理的なサイズ（既に除外されている）ではなく、どのトランザクション制限に達しているかという観点から見ていきます。
innodb_file_per_tableが有効になっていて、新しいデータをMySQLにロードする場合、ibdata1の内部には何がありますか？
私の疑いは、元に戻すログややり直しログが原因だと教えてくれます。
これらのログは何ですか？よるブック
第10章：「ストレージエンジン」段落3,4は次のように述べています。
InnoDBエンジンは、UndoログとRedoログの2種類のログを保持します。元に戻すログの目的は、トランザクションをロールバックすることと、それを必要とするトランザクション分離レベルで実行されているクエリの古いバージョンのデータを表示することです。元に戻すログを処理するコードはstorage / innobase / buf / log / log0log.cにあります。
REDOログの目的は、クラッシュリカバリで使用される情報を保存することです。クラッシュの前に完了した場合と完了していない場合があるトランザクションを、回復プロセスで再実行できます。これらのトランザクションを再実行した後、データベースは一貫した状態になります。REDOログを処理するコードはstorage / innobase / log / log0recv.cにあります。
分析
ibdata1内には1023個の取り消しログがあります（ロールバックセグメントと取り消しスペースを参照）。元に戻すログは、リロード前に表示されたデータのコピーを保持するため、1023個すべての元に戻すログが制限に達しました。別の観点からは、1023のすべてのUndoログは、Sampleテーブルをロードする1つのトランザクション専用にすることができます。
ちょっと待って...
おそらく「空のSampleテーブルをロードしています」と言っているでしょう。元に戻すログはどのように関係しますか？Sampleテーブルに93GBのデータが読み込まれる前は、空でした。存在しなかったすべての行を表すには、Undo Logsでハウスクリーニングスペースを使用する必要があります。1023個のUndo Logがいっぱいになるのは、大量のデータが流入することを考えるとささいなことibdata1です。私はこれを疑う最初の人ではありません：
MySQL 4.1ドキュメントから、次のことに注意してくださいPosted by Chris Calender on September 4 2009 4:25pm。
5.0（5.0.85より前）および5.1（5.1.38より前）では、InnoDBがUndoスロットを使い果たすと、InnoDBテーブルの「テーブルがいっぱいです」エラーを受け取る可能性があることに注意してください（バグ＃18828）。
MySQL 5.0のバグレポートは次のとおりです。http：//bugs.mysql.com/bug.php？id = 18828
提案
Sampleテーブルのmysqldumpを作成するときは、-no-autocommitを使用してください
mysqldump --no-autocommit ... mydb Sample > Sample.sql
これによりCOMMIT;、すべての後に明示的になりますINSERT。次に、テーブルをリロードします。
これは仕事が（ない場合は、あなたがこれを好きになるだろうされていない）、これを行います
mysqldump --no-autocommit --skip-extended-insert ... mydb Sample > Sample.sql
これにより、各INSERTの行が1つだけになります。mysqldumpははるかに大きく（10倍以上）、リロードに10〜100倍長くかかる可能性があります。
どちらの場合でも、これにより、UndoログがLog濫するのを防ぐことができます。
試してみる ！！！
更新2013-06-03 13:05 EDT
追加の提案
InnoDBシステムテーブル（別名ibdata1）がファイルサイズの制限に達し、Undoログを使用できない場合、別のシステムテーブルスペース（ibdata2）を追加するだけで済みます。
ちょうど2日前にこの状況に遭遇しました。古い投稿を自分のやっていることで更新しました：テーブルサイズの制限の頭痛を避けるために、データベースデザイン-複数のデータベースの作成を参照してください
本質的に、新しいシステムテーブルスペースファイルに対応するためにinnodb_data_file_pathを変更する必要があります。方法を説明しましょう：
シナリオ
ディスク（ext3）で、クライアントのサーバーには次のものがありました。
[root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql 362807296 Jun 2 00:15 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun 2 00:15 ibdata2
設定は
innodb_data_file_path=ibdata1:346M;ibdata2:500M:autoextend:max:10240000M
ibdata2は2196875759616に成長したことに注意してください2145386484M。
のファイルサイズibdata2をinnodb_data_file_path に埋め込み、追加する必要がありましたibdata3
innodb_data_file_path=ibdata1:346M;ibdata2:2196875759616;ibdata3:10M:autoextend
mysqldを再起動すると、動作しました：
[root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql 362807296 Jun 3 17:02 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun 3 17:02 ibdata2
-rw-rw---- 1 s-em7-mysql s-em7-mysql 32315015168 Jun 3 17:02 ibdata3
40時間で、ibdata331G に成長しました。MySQLは再び機能しました。