您可以禁用许多 InnoDB 配置以实现持久性，但会增加丢失数据的风险。但有时您想操作Running with scissors mode 中的数据库，因为原始数据安全地存储在其他地方，而您的测试数据库中的副本很容易重新创建。
这篇博客描述了Reducing MySQL durability for testing。除了测试之外，您不会看到任何官方 MySQL 推荐这样做！
以下是您可以在 /etc/my.cnf 中进行的更改的摘要：
[mysqld]
# log_bin (comment this out to disable the binary log)
# sync_binlog=0 (irrelevant if you don't use the binary log)
sync_frm=0
innodb_flush_log_at_trx_commit=0
innodb_doublewrite=0
innodb_checksums=0
innodb_support_xa=0
innodb_log_file_size=2048M # or more
他还建议增加innodb_buffer_pool_size，但大小取决于你的可用内存。
为了它的价值，我最近尝试在我为团队开发人员构建的默认 Vagrant 框中的配置中设置 innodb_flush_log_at_trx_commit=0，但我不得不取消该更改，因为它给开发人员造成了太多时间浪费谁得到了损坏的数据库。只是思考的食物。有时这不是一个好的权衡。
这并不完全符合您的要求（将最后 1GB 的数据保留在 RAM 中），因为它仍然使用事务日志记录运行 InnoDB，并且日志每秒刷新一次磁盘。在 MySQL 中无法关闭它。
您可以尝试使用 MyISAM，它对数据和索引使用缓冲写入，并依赖于文件系统缓冲区。因此它可以缓存你的一些数据（实际上我发现缓冲区会很快刷新到磁盘，所以你不可能在任何时候都有完整的 1GB 内存）。 MyISAM 还有其他问题，比如缺乏对事务的支持。使用 MyISAM 进行开发，然后在生产中使用 InnoDB 可能会给您带来一些尴尬的惊喜。
为了提高性能，您可以在 MySQL 会话中进行其他一些更改，但我不建议即使用于开发，因为它会改变您的应用程序行为。
set session unique_checks=0;
set session foreign_key_checks=0;
有些人建议使用 MEMORY 存储引擎。这有其自身的问题，例如大小限制、表锁定和缺乏对事务的支持。
我也尝试过尝试将表格或tmpdir 放到 tmpfs 上，但我发现这并没有带来您所期望的性能提升。 RDBMS 中存在与磁盘 I/O 不直接相关的开销。
您可能还想尝试 MyRocks，这是一个 MySQL 版本，包括用于 MySQL 的 RocksDB 存储引擎。 Facebook 开发了它并将其作为开源发布。见Facebook rocks an open source storage engine for MySQL（信息世界）。他们承诺它可以减少 I/O、压缩数据以及做其他简洁的事情。
但同样，让您的开发环境尽可能接近生产环境是一个很好的经验法则。使用不同的存储引擎会产生在代码投入生产之前无法发现某些错误的风险。
底线：调优 MySQL 不是灵丹妙药。也许您应该考虑设计您的应用程序，以更多地使用微服务、缓存和消息队列，并减少对直接 SQL 查询的依赖。
另外，我建议始终为您的开发人员提供您负担得起的最快的基于 SSD 的工作站。在 CPU 和 RAM 以及磁盘速度方面力争上游。