テーブルを最適化してインデックスサイズを小さくする

Question

私はチャットメッセージを保存するこのスキーマを持っています。現在私は、約5.5MBのデータである約100k行を持っています。インデックスのサイズは6.5MBです。データサイズが〜4MBだったとき、インデックスサイズは〜3MBだったので、が指数関数的にになっていますか？

CREATE TABLE `messages` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT, 
    `author` int(11) unsigned DEFAULT NULL, 
    `time` int(10) unsigned DEFAULT NULL, 
    `text` text, 
    `dest` int(11) unsigned DEFAULT NULL, 
    `type` tinyint(4) unsigned DEFAULT NULL, 
    PRIMARY KEY (`id`), 
    KEY `history` (`author`,`dest`,`id`) USING BTREE, 
    KEY `messages_ibfk_1` (`dest`), 
    FULLTEXT KEY `msg` (`text`), 
    CONSTRAINT `au` FOREIGN KEY (`author`) REFERENCES `users` (`id`) ON DELETE CASCADE ON UPDATE CASCADE, 
    CONSTRAINT `messages_ibfk_1` FOREIGN KEY (`dest`) REFERENCES `users` (`id`) ON DELETE CASCADE ON UPDATE CASCADE 
) ENGINE=InnoDB AUTO_INCREMENT=105895 DEFAULT CHARSET=utf8; 

私は2人

SELECT id, time, text, dest, type, author 
FROM `messages` 
WHERE (
    (author = ? AND dest = ?) OR (author = ? AND dest = ?) 
) AND id <= ? ORDER BY id DESC LIMIT ?, 25 

間のチャットのためのページ分割の履歴を表示する必要がある場合、私は、この表に対して実行されていることだし、私はそれを最適化しようとしたことを主なクエリがありますヒストリの他のクエリは、検索タームまたは日付範囲に追加のフィルタがある以外は同じです。

インデックスサイズを縮小し、最適なパフォーマンスを維持するためにできることはありますか？

Answer 1

インデックスの増加について心配する必要はありません。それはたぶんたぶんです。確かに "指数関数的"ではない。 UNIONにLIMITを扱う、UNIONに変更OR、およびページネーションのためのOFFSETを使用していない：主な問題を想定し

は、私が大幅に役立つ3つの手法を参照してください

SELECT id, time, text, dest, type, author 
FROM `messages` 
WHERE (
    (author = ? AND dest = ?) OR (author = ? AND dest = ?) 
) AND id <= ? ORDER BY id DESC LIMIT ?, 25 

のパフォーマンスです。

 (SELECT id, time, text, dest, type, author 
      FROM `messages` 
      WHERE author = ? -- one author & dest 
       AND dest = ? 
       AND id < ? -- where you "left off" 
      ORDER BY id DESC 
      LIMIT 25 
     ) UNION ALL 
     (SELECT id, time, text, dest, type, author 
      FROM `messages` 
      WHERE author = ? -- the other author & dest 
       AND dest = ? 
       AND id < ?  -- same as above 
      ORDER BY id DESC 
      LIMIT 25 
     ) 
     ORDER BY id DESC 
     LIMIT 25;   -- get the desired 25 from the 50 above 

Pagination discussionOFFSETを除去しなければならない理由を説明します。それは25の代わりに26を（3つの場所すべてで）使用することを含む他のテクニックについて議論し、これが最後のページかどうかを知ることができます。

最初の反復では、AND id < ?をオフにすることができます。または（より単純な）、あなたは非常に大きな数を代用することができます。

あなたのインデックス（author、dest、id）は私の処方に最適です。

messagesが大きくなったり、ユーザーページがリストのさらに遠くになると、この複雑な配合が輝きます。