一张大表 vs 大 + 缓存表答案

【问题标题】：One large table vs Large + cache table一张大表 vs 大 + 缓存表
【发布时间】：2014-03-29 19:37:46
【问题描述】：

我有大 MySQL 表（200K+ 记录）。从这张表中，我主要阅读最后 +-1000 条记录。对这个表，我每天插入大约 500 条记录。我的问题。我应该使用这张表并从中读取，还是应该使用一张较小的表，用作缓存。

我的缓存表的含义：每次插入到 large 表都会触发，将数据复制到 "cache" 表并删除旧表（以保持大小在范围内最多 1000 条记录）。现在，如果我读到一些东西，我会在 "cache" 中主要搜索“last entry records”。用户是否要读取“存档”数据，我从 large 表中读取。

这是一个好的解决方案，或者运行触发器并从 cache 表中删除会影响性能？或者..会有什么不同吗？

我主要运行的 SQL 查询由 SELECTs 和两个 JOINs 和范围内的搜索结果组成（使用 HAVING 子句）。我正在使用 MyISAM 数据库引擎。

【问题讨论】：

如果你有你的连接索引，所以你防止全表扫描，你的缓存表只会增加插入/更新的开销，但不会显着影响选择。
是的。我在比较或 JOINed 的列上有索引。

标签： mysql triggers large-data

【解决方案1】：

您可以自己检查 - 创建第二个表，使用

create table cache as select * from orig_table order by insertiontime desc limit 1000

然后将与原表相同的索引添加到缓存表中，并在原表上进行几次选择，在缓存表上进行相同的选择。测量每种情况的时间。

如果您有适当的索引，并且您的结果集大小相同（即您没有从原始表中选择缓存表没有的所有旧记录），则时间差不应该更大不到百分之几。

每天发送一次analyze table 可能会有所帮助，以防止 mysql 对密钥分配和使用次优连接顺序产生奇怪的想法。

如果您想排除无法阻止原始连接选择的旧记录，您可能需要阅读partitioning，它与您的缓存想法类似，但在数据库引擎中实现。

【讨论】：