优化表以减小索引大小

Question

我有这个保存聊天消息的架构。目前我有大约 100k 行，即大约 5.5MB 的数据。索引大小为 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

不用担心索引的增长。这可能是侥幸；当然不是“指数”。

假设主要问题是性能

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，在UNION 中处理LIMIT，以及不要使用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 变大和/或用户在列表中的页面更远，这个复杂的公式将大放异彩。