A：データの断片化の理由
なぜなら、断片化のMySQLの異なるエンジンも異なっています。
InnoDB内で、スペースは回復し、実際にリリースされていませんので。
1：私はリサイクル解放できないので、「削除」と、本当に物理的にインデックスから削除されないとしてだけでマークされた行の一部を削除してください。これらの役に立たないインデックスキーと行をクリーンアップするためのInnoDBのパージ非同期スレッド。しかし、これらはまだ多くの空のページがあるもたらすことができる、オペレーティングシステムの再利用にスペースバックを解放しませんでした。動的テーブル構造は、長さフィールドが含まれている場合、これらの空隙があっても、スペースの十分なスペース長の、新しいInnoDBの行を保存するために再使用することはできません
2：データファイルの不連続な空きスペースが得られたランダム削除操作の多くは、。従って、不連続データ格納場所で、その結果、空のスペースを使用するデータを挿入するとき。データの断片である異なる論理ソート順の物理的な格納順序、
3：UPDATEの多数のために、ファイルの断片が生成され、物理記憶装置のINNODB最小割り当てはページ（ページ）であるが、また、ページが疎になり、ページ分割UPDATE（ページ分割）、頻繁な分割ページにつながる可能性最終的なデータが断片化されるように、不規則で満たされています
2：データの断片化のタイプ
1：行の断片（行断片）
データ線を指すが、複数箇所の複数のセグメントとして記憶されます。クエリがインデックスから1行しかアクセスする場合であっても。行の断片化は、パフォーマンスの低下につながることができます。
2：インター断片（行内fragmentaion）
これは、論理ページの順にライン間の断片を指す、または行は、ディスク上に順次格納されていません。これらの操作は、ディスク上に記憶されたデータの元の順序から利益を得ることができるので、線の間には、そのようなスキャンとしてフラグメンテーション動作とフルテーブルスキャンクラスタ化インデックスに大きな影響を与えます。
3：残りのスペースデブリ（空き領域の断片化）
空き領域の断片化は、データページに空き領域をたくさんしている参照します。これは、不必要な大量のデータを読み取るために、サーバーが発生します。無駄になります。
MyISAMテーブルの場合は、断片化の3つのタイプが発生する可能性があります。しかし、InnoDBはライン片の短いではありません。InnoDBは線を移動し、短いセグメントを書いてます。InnoDBは、短い線分を移動し、再書き込ま
3：ディスカバリーデータの断片化の深刻なテーブル
1：方法
1.1：使用XXXXからテーブルのステータスを表示LIKE 'XXXX' \ G;
第XXX：データベーステーブルの名前が配置され、第二XXX：テーブル名のクエリに。この方法には限界、断片化、断片化は、データベースまたはインスタンス全体の下にあるすべてのテーブルを照会することができない唯一の単一テーブルのクエリを有します
1.2：クエリ情報INFORMATION_SCHEMA.TABLESがテーブルを取得断片化
2：主なパラメータ
DATA_LENGTH：データ長。
INDEX_LENGTH：インデックス長。
free_data：だからここに空きスペースや破片の大きさがあります。
PT-オンライン・スキーマ変更ツールでオンラインテーブル構造、収集破片や他の操作を整理することができます
4：治療の選択肢
1：OPTIMIZE表
これは、OPTIMIZEが一時的に作動し、テーブルをロックし、収納スペースを削減し、IOアクセステーブルの使用効率を向上させるために、物理的に保存されたテーブルとインデックスを組換え、およびより大きなデータ量を、それは長い時間がかかります。関連するとOPTIMIZE TABLEの後に、変更テーブルのストレージエンジン
MyISAMテーブル
次のようにPTIMIZE TABLEは動作します：
テーブルは、行または分割行が（スプリット行）を削除した場合は、テーブルを修復します。
あなたはインデックスページ上にない場合、それらは、ソート、ソートされました。
統計情報テーブルが最新ではありません（と修復を完了するために、インデックスでソートすることができない）場合は、それらを更新。
InnoDBの
OPTIMIZE TABLEタッチ再建から発行され、ALTER TABLE ... FORCEカバーの下に完成。準備フェーズと操作のコミットフェーズ中に排他表ロックだけ簡単に。準備フェーズでは、メタデータを更新し、中間テーブルを作成します。応募期間中に、テーブルのメタデータの変更に提出されます。
以下の条件で表レプリケーションの再構成法を使用してOPTIMIZE TABLEのテーブル：
ときold_alter_tableシステム変数を有効にします
ときはmysqldを--skip-新しいオプションを有効にします
FULLTEXTインデックスをサポートしていないInnoDBテーブル用OPTIMIZE TABLEは、オンラインDDLが含まれています。代わりにテーブルをコピーする方法を用いました。
InnoDBは、データを格納するためではなく、（例えば、MyISAMのような）従来のストレージエンジンのような過剰な断片化しやすいように、ページの割り当て方法を使用します。最適化を実行するかどうかを検討するには、ワークロードのトランザクションを処理するサーバーを考えてみます。
断片化のある程度が期待されています。InnoDBはページを分割することなく、更新のためのスペースを残して、ページのわずか93％を埋めます。
欠失は、左側の空白になり、それは価値のあるテーブルを最適化するために作ることが予想されるようにページを埋めることがあります。
2：ALTER表table_nameエンジン= INNODB。
これは実際にNULL操作で、表向きは何もしないように、実際には、最適化を実行する際のフラグメントを再構成するために、実際の実装は空ALTERコマンドですが、このコマンドはまた、その最適化に役割を果たしますテーブル全体を再構築し、未使用のブランク・スペースを削除
3：PT-オンライン・スキーマ変更ツールは、オンラインのテーブル構造、収集破片や他の操作を整理することができます
比較します
InnoDBエンジン、ALTER TABLE XXXXエンジン用= INNODB空ALTER TABLE操作を行っています。OPTIMIZE TABLEはALTER TABLE ... FORCEに相当します。参照は、上述したいくつかのケースでは、最適化TABLEまたはALTER TABLE XXXX ENGINE = INNODB実質的に同じ。しかし、いくつかのケースでは、ALTER TABLE xxxxはENGINE = INNODBより良いです。例えばold_alter_tableシステム変数が有効になり、そうではありません。MyISAMテーブル型テーブルに加えて、ALTER TABLE XXXXエンジンを使用= INNODBは有意に良好OPTIMIZE表よりも、この方法です。
