Question

CREATE [TEMPORARY] TABLE [IF NOT EXISTS] tbl_name
    (create_definition,...)
    {DATA|INDEX} DIRECTORY [=] 'absolute path to directory'

我的表仅供搜索，需要8G磁盘空间（4G数据+ 4G索引），行数为80M 我无法使用ENGINE = Memory将整个表存储到内存中，但我可以通过DIRECTORY表选项将数据或索引存储在RAM驱动器中

从理论知识来看，最好将数据或索引存储在RAM中吗？

Answer 1

MySQL的默认存储引擎是InnoDB。当您对InnoDB表运行查询时，该表或其读取的索引的部分将复制到内存中的InnoDB Buffer Pool。这是自动完成的。因此，如果您稍后查询同一个表，很可能它已经在内存中了。

如果对其他表运行查询，它也会将这些表加载到内存中。如果缓冲池已满，它将驱逐属于您的第一个表的某些数据。这不是问题，因为它只是磁盘上的内容的副本。

没有办法在内存中专门“锁定”索引。如果需要，InnoDB将加载数据或索引。 InnoDB足够智能，不会驱逐您使用过一千次的数据，只需要一次请求另一个表。

随着时间的推移，这会趋于平衡，使用内存作为每个表和索引中最常查询的子集。

因此，如果您有系统内存可用，请将更多内容分配给您的InnoDB缓冲池。缓冲池具有的内存越多，存储所有经常查询的表和索引的能力就越强。

当然，最大可达数据+索引的大小。从数据+索引复制的内容仅在内存中存储一次。因此，如果您只有8G数据+索引，则无需为缓冲池提供越来越多的内存。

不要为缓冲池分配比服务器能够承受的更多系统内存。分配内存会导致交换磁盘内存，这对性能不利。

不要理会{DATA|INDEX} DIRECTORY选项。当你需要在另一个磁盘卷上找到一个表时，这些是因为你的空间不足。它不太可能有助于提升表现。将更多系统内存分配给缓冲池将更加可靠地完成。

Answer 2

但我可以通过DIRECTORY表选项将数据或索引存储在RAM驱动器中......

简短回答：让数据库和操作系统完成它。

使用RAM磁盘可能在10 - 20年前有意义，但是现在软件管理缓存磁盘到RAM。磁盘本身有自己的RAM缓存，特别是如果它是hybrid drive。操作系统将缓存RAM中的文件系统访问。然后MySQL本身将自己进行缓存。

如果它的SSD已经非常快，那么RAM缓存不太可能显示出很大的改进。

因此，制作自己的RAM磁盘不可能做任何已经发生的事情。你将所做的就是从操作系统和MySQL中获取资源，而这些资源本身可能会更智能地管理，可能会减慢该机器上的所有内容。

您正在描述 微优化 。这是为了使个人操作更快。它们往往会增加复杂性并降低整个系统的性能。使用微优化可以做多少优化是有限的。例如，如果您必须搜索1,000,000行，并且每行需要1毫秒，则为1,000,000毫秒。如果你每行0.9毫秒，那么900,000毫秒。

您要关注的是 算法优化 ，这是对算法的改进。这些往往会使代码更简单，更简单，但通常需要更多地考虑数据结构，因为您的工作量较少。获取相同的1,000,000行并添加索引。不要查看1,000,000行，而是花费100毫秒来查看索引。

这些数字已经弥补，但我希望你明白这一点。如果＆＃34;你想要的是速度＆＃34;，算法优化将带你到没有微优化的地方。

还有使用数据库考虑的代码的性能，它通常是使用未经优化的查询的真正瓶颈，用于获取相关数据的不良模式，以及不利用缓存。

微优化及其复杂性和特殊配置往往会使算法优化变得更加困难。因此，从长远来看，你可能会因为担心微观优化而放慢脚步。此外，当你对这个东西将如何被使用或执行或瓶颈所在的模糊想法时，你一开始就这样做。

花时间优化数据结构和索引，而不是数据库存储的细节。一旦你完成了它，如果它仍然不够快，那么看看调整设置。

作为旁注，使用DIRECTORY有一个 可能的 好处。您可以将数据和索引放在不同的物理驱动器上。然后可以使用每个驱动器的完整I / O吞吐量同时访问它们。

虽然您刚刚将磁盘发生故障和复杂备份的可能性提高了两倍。使用SSD和/或RAID可能会更好。

并考虑云数据库是否实际上可能超出您可能承受的任何硬件。