MySQL-textパフォーマンスの最適化--レコード1

最近、プロジェクトを引き継いだばかりで、ビジネス側からDBを最適化するのは最もやりがいのあることです.
プロジェクトには仕事を急ぐ現象がある.多くの機能と最適化が最後に置かれています.プレイヤーがゲームカードに反応すると、みんな手が回らなくなります...
本題に戻ります.TEXTフィールドタイプを含むテーブルは、独立して1つのテーブルにする必要があります.
12個のフィールドとmediumtextのフィールドが含まれている表がありますが、これは最も悩んでいます.オンラインになったばかりのしばらくの間、他のテーブルはMレベルで、textタイプを含むテーブルは23 Gに達しました!!!
このテーブルはフロントエンド戦闘計算のデータにのみ提供され、後期に戦闘記録を追跡する可能性がある.だから多くのデータは削除できます.
最適化シナリオ:1、表を分割し、このフィールドを独立して単一の表にします.アプリケーション側はクエリーを複数回行います(開発もDBAも変更します).
2、テーブルを削除し、定期的に一部のデータを削除し、optimizeを行う(DBAの端で済む)
3、NOSQLをアップして、redisのようなKVストレージシステムを使うと、もっと効率的になるはずです.
4、最良の方法:プレイヤーの戦闘記録に対してデータを計算し、memcachedに保存し、DBを全く必要としない
現在は2つ目の方式が採用されているが、4つ目の方式は、アプリケーション側が実現できないためである(メモリ個を手動で空にすることが多いことが残念である.)
削除方法:ストレージ・プロシージャが書かれ、一部のデータが削除されます.これによりslaveが大きな事務で引きずられるのを避けることができます.

   CREATE  PROCEDURE `del_sleep`(num int)
   begin
   declare a int default 1;
   while a<=num do delete from user_fight_xml limit 100;
   select sleep(1); set a=a+1;
   end while;
   end$$

optimize table回収スペース、破片整理の際、以下の情報を提示します.

  note     | Table does not support optimize, doing recreate + analyze instead 
  status   | OK      

最初は理解できませんでした:なぜrecreate+analyzeに置き換えられ、ドキュメントをクエリーします.
  http://dev.mysql.com/doc/refman/5.5/en/optimize-table.html
MyISAMテーブルの場合:
1、deleteの場合、repairを行う
2、索引ページの並べ替え
3、テーブルの更新は最新(the repair could not be accomplished by sorting the index)
InnoDBではalter tableにマッピングされるのでrecreate+analyzeの場合
slaveに書き込みたくなければNO_WRITE_TO_BINLOGキーワード!