0

データベースを復元するために mysql -u root -p gf < ~/gf_backup.sql を実行しました。しかし、プロセス リストを見ると、1 つのクエリが長時間アイドル状態になっていることがわかります。理由はわかりません。

mysql> show processlist;
    +-----+------+-----------+-------------+---------+-------+-----------+------------------------------------------------------------------------------------------------------+
    | Id  | User | Host      | db          | Command | Time  | State     | Info                                                                                                 |
    +-----+------+-----------+-------------+---------+-------+-----------+------------------------------------------------------------------------------------------------------+
    | 662 | root | localhost | gf | Query   | 18925 | query end | INSERT INTO `gf_1` VALUES (1767654,'90026','Lddd',3343,34349),(1 |
    | 672 | root | localhost | gf | Query   |     0 | NULL      | show processlist                                                                                     |
    +-----+------+-----------+-------------+---------+-------+-----------+------------------------------------------------------------------------------------------------------+
4

2 に答える 2

1

df -h コマンドで空き容量を確認してください (Linux/Unix の場合) 容量が不足している場合は、容量を解放して変更に追いつくまで、MySQL を強制終了または再起動しないでください。

my.cnf の max_allowed_pa​​cket 設定を確認して、256M などに設定することもできます。http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_max_allowed_pa​​cket を参照してください。

于 2012-06-04T05:23:59.773 に答える
0

おそらく、ダンプは非常に大きく、多くの正規化されたデータが含まれています (レコードは多数のテーブルに分割され、多数の外部キー制約、インデックスなどがあります)。

その場合は、SQL ファイルからすべての制約とインデックス定義を削除してから、データをインポートし、以前に削除されたディレクティブを再作成してみてください。これは、インポートを高速化するためのよく知られたトリックです。これは、INSERT制約の検証を行わないコマンドの方がはるかに高速であり、その後のインデックスの作成などを 1 回のトランザクションで実行できるためです。

参照: http://support.tigertech.net/mysql-large-inserts

もちろん、最初にクエリを強制終了する必要があります。そして、それがすでに作成したすべてのフラグメントを削除します。

于 2012-06-04T04:14:44.230 に答える