将表拆分为常用表和存档表有用吗？

Question

我有一个包含 1.000.000 多个条目的表。只有最新的 100.000 个条目被频繁使用。其他 90% 很少使用。

将此表拆分为包含 100.000 个条目的常用表和一个存档表有用吗？

我将不得不移动大约。每天有 10.000 个元素到存档表。

查找元素的服务器逻辑是：

1. 在常用表中搜索。
2. 如果在那里找不到，请在存档表中搜索。

---

背景

我已经对一个小表和一个大表（数据量多 10 倍）中的随机数据进行了一些测试。一个SELECT为一个特定的元素查询了0.6倍以上的时间在大表比小的一个。我相信这会对每秒 1000 多个查询的整体性能产生影响。

---

@里克詹姆斯

创建是

CREATE TABLE IF NOT EXISTS `note` (
  `note_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `user_id` int(10) unsigned NOT NULL,
  `title` varchar(100) NOT NULL,
  `content` text NOT NULL,
  `date_added` datetime NOT NULL,
  `date_modified` datetime NOT NULL,
  PRIMARY KEY (`note_id`),
  KEY `FK_note_user` (`user_id`),
  CONSTRAINT `FK_note_user` FOREIGN KEY (`user_id`) REFERENCES `user` (`user_id`) ON DELETE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

测试查询只是：

SELECT *
FROM `note`
WHERE `note_id` = $note_id
LIMIT 1 

---

@沃尔特米蒂

你的第二个想法是我的意思。关键事务只发生在最新的 10% 的数据上。那么拆分有意义吗？

Answer 1

就我个人而言，我会拆分该表。一定要考虑 Rick James 的观点，即确保所有内容都正确索引并首先有效查询，但是，最终，您将删除 90% 的数据，您必须筛选这些数据才能获得您想要的数据。归档该数据将通过减少行数和显着缩小索引来加快查询速度。将会有更多索引，因为您必须在存档表上复制它们，因此磁盘空间会受到一点影响，但我的期望是性能会提高......

除非：唯一跳入脑海的部分会杀死我的建议，那就是移动到存档的数据的访问量是否比您想象的要多。在这种情况下，您现在正在查询两个表，总计比以前多（包括重复的索引/键）；不仅没有任何好处，而且您现在比原来的设置花费了更多的时间（以及更多的开销）。

简而言之：在移动存档数据之前，您需要非常确定访问存档数据的频率以及访问方式。