如何优化 MySQL 以处理小型数据库，即 < 100mb？

Posted 2023-02-24

【中文标题】如何优化 MySQL 以处理小型数据库，即 < 100mb？

【英文标题】：How to optimize MySQL for handling a small database, i.e. < 100mb?

【发布时间】：2012-04-07 05:21:55

【问题描述】：

我正在设计一个可能保持小于 100 MB、拥有自己的服务器并且将通过 Intranet Java EE Web 应用程序读取和修改的基础。我找到了很多关于优化大型基础的参考资料，我知道这是一个更关键的问题，但我有很多时间，读取/插入速度是项目的优先事项，我很确定我可以以某种方式利用如此小的总数据库大小。当然，除非 mysql 已经自然地针对这种小型基准进行了优化。

当然，它确实适合内存，但我需要将其数据实际保存在磁盘上，或者至少在不久之后将其保存到磁盘；我想到了一些听起来很疯狂的替代方案，例如在第一次需要时（可能是在用户连接时？）按顺序将整个基础加载到内存中，然后以某种方式将其提交到磁盘。

但我认为最好在这里问一下，看看是否有人以前遇到过这种情况，并且有一个从小规模获利的好主意。

我更多地考虑数据库访问而不是结构，但如果有人有针对小型基础的结构设计技巧并认为他们使访问优化问题完全无关紧要，说明这可能是适当的回应。

提前致谢。

编辑：这个应用程序有点关键，在我完成后它将由最习惯 MySQL 的人开发，所以不同的 DBMS 不是一个很好的选择，除非它们与 MySQL 非常相似.

【问题讨论】：

只要确保 mysql 的缓存设置为大于 db 的大小，当您在表上工作时它会自然地将自己缓存在内存中。

我已经想到了，但不确定它会以这种方式工作。看起来很顺利，我很确定我会这样做。谢谢！

您真的遇到了性能问题吗？看来您可能正在尝试过早优化。首先，实现应用程序，然后对其进行基准测试，如果基准测试显示严重瓶颈，则最后对其进行优化。

我没有遇到性能问题，这是关于最佳实践的。我想知道是否存在设计小型数据库的最佳方法，即考虑到它们的大小；如果以这种优化的方式进行不会产生任何额外的开发时间或成本，那么就没有理由以非优化的方式开发解决方案。当然，这不太可能对我的项目产生太大影响，但是如果这个问题得到了一个零成本的解决方案，并且这个站点中的每个人都开始用它优化他们的小型数据库，也许我们会在全球范围内节省一些处理 lol

【参考方案1】：

数据库就是为处理这类事情而设计的，所以大部分基础设施都为您准备好了。

您有责任：

根据数据、卷和 dbms 创建适当的索引。

标准化数据。

应用良好的验证 - 不是空值、唯一值等。

使用解释计划查看如何加快查询速度 - 每种情况都不同。

使用缓存来提高性能。

确保所有表都定义了唯一的主键（可能很明显，但仍然需要）。

【讨论】：

嗯，这对于各种尺寸的底座来说都是常识，不是吗？虽然我猜你可能会专门为小型基础定制索引，也许是通过选择一些在低阶情况下更好地检索的更高复杂性类结构......当你简单地说“使用缓存来提高性能”时，你的意思是缓存整个基地还是更复杂的东西？谢谢！

我的意思是设置缓存，以便单个查询的重复运行更快。

【参考方案2】：

您可以尝试查看 membase - 我被告知有关性能和持久性的非常好的事情。本质上是一个持久化到磁盘的内存“数据库”。

【讨论】：

听起来很有趣，但我从 2011 年中期在 membase 板上看到了一些帖子，很明显它还不够稳定，无法部署在生产环境中，是不是更好现在？另外，它与 MySQL 有多相似？完成项目后我要离开这个国家，而之后要维护它的人真的只习惯了 MySQL。谢谢！

显然它现在被称为 Couchbase？ ：couchbase.com/membase 所以它看起来肯定是从你上次的观点开始的。就兼容性而言，我无法真正发表评论——我已经在一些 php 项目中看到 membase 与 mysql 一起使用，并且总是认为它们密切相关——我可能假设的比我应该做的多一点。跨度>

看起来很有意思，它基于memcached，已经相当稳定了，key-value存储肯定能满足我的需求。尽管如此，与大多数 NoSQL 服务器一样，它似乎是为跨分布式集群等扩展而设计的。你见过的那些 PHP 项目，有那么大吗？我担心这种面向分发的方式可能会使它的 API 对于像我这样的小项目来说有点麻烦。