如何将定期访问的数据放入数据库中的“快速访问”区域答案

【问题标题】：How can I put regularly accessed data into a "quick access" area in a database如何将定期访问的数据放入数据库中的“快速访问”区域
【发布时间】：2014-06-09 07:38:11
【问题描述】：

很快我将构建一个包含 200 万行的数据库结构。一般来说，每分钟查询的行数不超过 200 行，在这 200 行中，正在查询的行将是 10-20 行。

鉴于表的大小，我想将查询的行“存储”在某处，以便查询该行的任何其他最终用户能够“更快”地获取行数据。然后我希望通过此访问该行一段时间，然后在不再使用时将其放回主表中。我相信这将使访问更快、更高效。

使用以下架构，我将提供一个示例。在这种情况下，第 1 行已从应用程序层访问。应用层查询“已访问”表以查看该行是否存在。如果是，它使用它并使用任何更改的数据更新“访问”表。如果不是，则从主大表中查询并放入“已访问”表中，直到 cron 运行（例如 10 分钟后），此时所有“已访问”数据都被复制到主表中并从已访问表中删除.

http://sqlfiddle.com/#!2/d76f6/2

我正在尝试解决以下问题：

1) 这会提高效率吗（我想每个针对“已访问”而不是主要查询的查询会明显更快）？

2) 应该使用什么技术来存储“访问”数据？主表可能会存储在 MariaDB/MySQL 中，但是我很乐意在平面文件、sqlite、不同的实例中运行它，或者将它保存在同一个实例中……我愿意接受可以实现这一点的建议更高效，理论上应用层没有理由不能充当任何技术之间的中介

【问题讨论】：

这个问题让我变得更聪明了，谢谢。听起来你在正确的轨道上。
@Andrew - 谢谢！这是我最喜欢 Stackoverflow 的地方之一。尽管它不是一个“讨论”网站，但有很多观点和看待事物的方式，我发现自己不断地阅读改变我思维方式的东西！ :D.
我实际上不认为这是一个好主意。 RDBMS 有自己的缓存，我希望他们为您完成此类工作。这样做会使应用程序代码更加复杂，并且会涉及客户端和服务器之间的更多通信。我怀疑这会比服务器缓存提供更好的结果。我会尝试调整服务器缓存......或者在出现真正问题之前完全不用担心。
请将所有相关细节放在问题本身中，以防止人们不得不点击周围，如果他们无法这样做，人们就无法完全理解问题，并且如果出现这个问题，这个问题就没有意义SQLFiddle 曾因任何原因关闭或直接终止链接。
@Frazz - 这是一个公平的观点。我不知道缓存已完成 - 对于这种情况，有什么关于阅读好的 RDBMS 的建议吗？或者具体阅读 MariaDB/MySQL（我目前计划的技术）？如果可行，很高兴沿着这条路走下去

标签： mysql performance data-structures mariadb

【解决方案1】：

过早的优化。从过于复杂的设计开始。你要实现的是一个访问频率最高的缓存系统。但是，DMBS 系统的职责确实是为您做这些系统优化。磁盘级别、文件系统级别和数据库级别已经存在缓存。您的意思是，即使在系统到位之前，您就已经知道它不会按预期运行。

也许您知道的比您在问题中陈述的要多，但从表面上看，应该在之后进行优化，并进行适当的分析。

【讨论】：

我支持这个...实施简单的解决方案，只有在您意识到自己有问题后才担心优化。世界上到处都是包含数百万行的数据库，如果没有这种类型的解决方案，它们也能正常工作。
@koriander - 谢谢，这是一个很好的观点。你是完全正确的 - 我假设问题并在它发生之前寻找潜在的解决方案。我这样做是因为一旦有了数据，我就需要迅速做出反应，并有计划地走下去。不过我很欣赏你的观点，也许我会生成一些垃圾数据和测试脚本来提高性能。

【解决方案2】：

有很多方法可以缓存数据。

在 mysql 上，您可以使用内存表。内存表比 innodb-myisam 表快得多

您可以使用基于内存的键值存储系统，例如 redis、memcached

在应用层，您可以将数据缓存到文件系统

【讨论】：

谢谢@talhasch - 这些是一些很棒的具体提示！作为一般经验法则，文件系统存储的数据（例如，我假设您的意思是平面文件？）是否会比存储在内存表或普通 InnoDB 表中更快？ Memcached 也是一个好主意，我会研究一下。
我一直在阅读基于内存的表格。这些似乎非常适合只读访问，但是由于我将在将数据推回主表之前对其进行更新，我该如何保护这些数据？
将缓存数据存储到内存表中以供读取。需要时一起更新内存表和主表。