手動でインポート/エクスポートまたはデータベース

Question

をダンプし、私はむしろ、重いデータベース を持っている私は、サーバーを変更する必要があるので、私はダンプとデータベースをエクスポートし、その後、私は、私の新しいサーバー

にしかし、それをインポートした後、それを取得しデータベースのサイズが異なります。

• 旧サーバー：772 Moの
• 新サーバー：414 Moの

差が膨大である、私が心配する必要がありますか？ （あなたに欠けているものがあると思いますか？） インポートを手動でインポートする方が良いのですか？

Answer 1

ファイルシステム（du -chなど）からのこれらのサイズ番号、またはクエリからのサイズ番号については言及していません。私は彼らがファイルシステムから来たと推測しています。インポートエラーが発生していない限り、あなたのデータはおそらくOKです。

あなたのSOURCEテーブルにあるを確認してください。それが、あなたのソースがあなたのターゲットよりも大きい理由です。基本的には、行が更新されると、同じデータブロックに収まらなくなり、そのデータブロックが2つに分割され、2つのブロック（ディスク上では16KB、データファイルでは9KB）に空き領域が残ります。 fragmented tablesため

チェック：使用される総ディスクとの合計空き領域 select ENGINE, TABLE_NAME,Round(DATA_LENGTH/1024/1024) as data_length , round(INDEX_LENGTH/1024/1024) as index_length, round(DATA_FREE/ 1024/1024) as data_free from information_schema.tables where DATA_FREE > 0;

チェック： select sum((DATA_LENGTH + INDEX_LENGTH)/1024/1024) as TTL_MB_USED , sum(DATA_FREE)/1024/1024 as TTL_MB_FREE from information_schema.tables where table_schema='<your schema>'; ソースとターゲットの大きさの違いのアカウントを助けるかもしれません。

私はこの答えはフラグメンテーションを記述するのに優れていることが判明： https://serverfault.com/a/265885

最初にすべてのあなたは、行が更新されたときにMySQLのテーブルが断片化し得るので、それは正常な状況だということを理解する必要があります。テーブルが作成されると、データ付きのダンプを使用してインポートされ、多くの固定サイズのページにはすべての行が断片化なしで格納されます。可変長の行を更新すると、この行を含むページが2つ以上のページに分割されて変更が保存され、これらの新しい2つ（またはそれ以上）のページには、未使用領域を埋める空白が含まれます。