如何使MySQL数据库完全在内存中运行？

我注意到我的数据库服务器支持内存数据库引擎。我想让运行InnoDB的数据库完全在内存中运行，以提高性能

---

我该怎么做？我研究了PHPMyAdmin，但找不到“更改引擎”功能。

假设您了解使用评论中提到的内存引擎的后果，以及通过搜索找到的其他一些（无事务安全、锁定问题等），您可以按以下方式进行操作：

---

内存表的存储方式与InnoDB不同，因此需要使用导出/导入策略。首先使用

SELECT*fromtablename将每个表分别转储到一个文件中，并将其放入输出文件“table\u filename”

。创建内存数据库并使用以下语法重新创建要使用的表：

Create TABLE tablename（…）ENGINE=MEMORY。然后，您可以使用
将数据填充“table_filename”加载到每个表的table table name
中导入数据。
如果您的数据库足够小（或者如果您添加了足够的内存），您的数据库将有效地在内存中运行，因为它会在第一次请求后缓存您的数据

更改数据库表定义以使用内存引擎可能比您需要的更复杂

如果您有足够的内存使用
内存
引擎将表加载到内存中，那么您就有足够的内存来调整innodb设置以缓存所有内容。
内存引擎不是您要寻找的解决方案。你失去了所有你在第一时间访问数据库的东西（即ACID）

以下是一些更好的选择：

不要使用连接-很少有大型应用程序会这样做（如谷歌、Flickr、NetFlix），因为它不适合大量连接
左[OUTER]联接可能比等效子查询快，因为
服务器可能能够更好地优化它—事实并非如此
只针对MySQL服务器

-

确保要查询的列具有索引。使用EXPLAIN确认正在使用它们
使用并增加索引的查询缓存和内存空间，以将它们存储在内存中并存储频繁的查找
去规范化您的模式，特别是对于简单连接（即从barMap获取fooId）
最后一点是关键。我过去喜欢联接，但后来不得不在几个有100多行的表上运行联接。无益。最好是将要连接的数据插入到目标表中（如果不是太多的话），并对索引列进行查询，这样您就可以在几毫秒内得到查询

希望这些帮助。
 < P>代替内存存储引擎，可以考虑MySQL集群。据说，它具有类似的性能，但支持磁盘备份操作以提高耐用性。我没有尝试过，但它看起来很有希望（并且已经开发了很多年）


“我该怎么做？我研究了PHPMyAdmin，但找不到“更改引擎”功能。”

为了直接回答这部分问题，您可以发布一个
altertable tbl engine=InnoDB也可以将MySQL数据目录放置在tmpfs中，从而加快数据库的写入和读取调用。这可能不是最有效的方法，但有时您不能仅仅更改存储引擎

这是我的MySQL数据目录的fstab条目

none            /opt/mysql/server-5.6/data  tmpfs   defaults,size=1000M,uid=999,gid=1000,mode=0700          0       0

您可能还想查看innodb_flush_log_at_trx_commit=2设置。也许这会大大提高MySQL的速度

innodb_flush_log_at_trx_commit更改mysql磁盘刷新行为。当设置为2时，它仅每秒刷新一次缓冲区。默认情况下，每次插入都会导致刷新，从而导致更多IO负载。
其他想法：

Ramdisk-设置MySQL用作RAM磁盘的临时驱动器，非常容易设置

memcache-memcache服务器易于设置，使用它可以在X个时间段内存储查询结果。
您应该首先了解您在那里做什么。使用内存引擎有一定的影响。在内存中运行意味着一旦重新启动MySQL守护程序（或它崩溃），数据就会被删除，最好使用query_cache for MySQL或memcached for caching Results。我不确定这是否是您想要的。您的性能问题到底是什么？我的数据库现在非常慢。我的查询有很多JOIN语句，而且一些查询的数据集非常庞大。我认为把所有这些数据放进RAM会加快速度，对吧？不太可能。添加/调整索引。整合您的查询以提高效率。这样的东西通常更有效，应该是您的初始方法。最后一点可能对性能有好处，但如果使用不当，它可能会成为数据一致性和维护的杀手。触发器更新或类似的缓存复制策略可以在这方面有所帮助，但是缓存非规范化数据的方式不应该被认为是理所当然的…@PinnyM很好。这是一个人必须决定什么是最重要的地方。RDBMS非常适合原子性和一致性，但不适合扩展和性能，尤其是连接。6NF（星型模式）很正常，但加入时很开心。您仍然可以以规范化的方式保留某些表中的数据，并使用触发器和计划任务从规范化表（读/写）中更新非规范化（只读）表。1和4 for是有史以来最糟糕的建议。@达尔文感谢否决票。选择一致性或比例。对于数十亿行，一致性通常不值得花费开销，这取决于您的用例（例如，与我在工作中使用的所有Col存储一样）。@JosephLust您是对的，“选择一致性或规模”。大约99%的数据库最好具有一致性。大多数开发人员从未使用过大型数据库。总的来说，我的意思是，在我的记忆中不能有一个合理的公关