读写环境中的 MEMORY(HEAP) 与 InnoDB答案

【问题标题】：MEMORY(HEAP) vs. InnoDB in a Read and Write Environment读写环境中的 MEMORY(HEAP) 与 InnoDB
【发布时间】：2010-05-04 16:53:36
【问题描述】：

我想使用 MySQL 编写一个实时应用程序。

它需要一个小表（少于 10000 行），该表将承受繁重的读取（扫描）和写入（更新和一些插入/删除）负载。我说的是每秒 10000 次更新或选择。这些语句将仅在少数（少于 10 个）打开的 mysql 连接上执行。

该表很小，不包含任何需要存储在磁盘上的数据。所以我问哪个更快：InnoDB 或 MEMORY (HEAP)？

我的想法是：

这两个引擎可能会直接从内存中提供 SELECT，因为即使是 InnoDB 也会缓存整个表。更新呢？ (innodb_flush_log_at_trx_commit?)
我主要关心的是锁定行为：InnoDB 行锁与 MEMORY 表锁。这会成为 MEMORY 实现的瓶颈吗？

感谢您的意见！

【问题讨论】：

【解决方案1】：

如果你真的需要有那么多并发更新，那么几乎可以肯定 innodb 会表现得更好，因为 HEAP 表只有表级锁，而不是像 Innodb 这样的行级锁。

如果您是从头开始，我会使用 MySQL 5.5 或 Percona 的 XtraDB 进行研究，因为它们都比现有的 MySQL 5.1 包含许多可扩展性改进。

【讨论】：

谢谢！您认为 MySQL 5.5 有哪些改进？它只是在相同的表定义上表现更好，还是设计必须显着不同。如果是，我如何找出在 5.5 中应该以不同方式实现哪些部分。与5.1相比？任何方向
它应该在相同的定义上表现更好，这得益于各种内部 innodb 结构中更细粒度的锁定和更智能的自适应算法。在 IO 和 CPU 绑定的工作负载中，多核机器上的加速应该是显而易见的。

【解决方案2】：

这不仅仅是行锁的问题 - InnoDB 也有 MVCC http://en.wikipedia.org/wiki/Multiversion_concurrency_control 所以读者甚至不会阻止作者。

但我认为您的问题缺少所有重要的细节 - 您存储的是哪种数据？如果您需要能够恢复崩溃后的 MEMORY，则不是一种选择。

如果您不需要在崩溃后恢复，那您为什么要使用数据库？为什么不使用 memcached 或 redis 之类的东西？

【讨论】：

相信坚如磐石的实施并不是一个坏主意。知道需要对复杂的数据结构执行操作，因此很难对缓存的数据执行多个操作（创建子集合、排序等）（甚至不计算可能的错误和所需的测试）。数据库擅长这类东西，因此使用它们对开发人员来说是一个巨大的解脱。顺便说一句，您的解决方案在理论上是合乎逻辑的，如果您提及执行我所说的数据库擅长的操作的工具会更好。