Оптимизируйте таблицу, чтобы уменьшить размер индекса

Question

У меня есть эта схема, которая сохраняет сообщения чата. В настоящее время у меня около 100 тыс. Строк, что составляет около 5,5 МБ данных. Размер индекса - 6,5 МБ. Когда размер данных составлял ~ 4 МБ, размер индекса составлял ~ 3 МБ, поэтому он растет экспоненциально?

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

Не беспокойтесь о росте индексов. Вероятно, это случайность; конечно, не «экспоненциальный».

Предполагая, что главный вопрос является выполнением

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 

Я вижу три метода, которые существенно помогут: Изменить OR в UNION, иметь дело с LIMIT в UNION, и не использовать OFFSET для пагинации.

 (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 discussion объясняет, почему OFFSET должны быть удалены. В нем обсуждаются другие методы, в том числе использование 26 (во всех трех местах) вместо 25, чтобы вы знали, является ли это «последней» страницей.

На первой итерации AND id < ? можно оторвать. Или (проще), вы можете заменить очень большое число.

Ваш индекс (author, dest, id) является оптимальным для моей формы.

Эта сложная формулировка будет светиться, так как messages получает больше и/или страницы пользователя дальше по списку.