在大型只写表上的MySQL性能

在此先感谢您的回答，并为我的英语不好对不起，我不是母语人士。

我们实际上是在开发带有后端的手机游戏。在此手机游戏中，我们有一个货币系统，我们会跟踪每笔交易以进行验证。

为了读取用户余额，我们有一个中间表，该表中的每笔交易都会更新用户余额，因此用户永远不会直接读取交易表，以减轻高流量的负担。

事务表是在后台不时唯一读取的。

这是事务表的架构:

create table money_money_transaction (
  `id`              BIGINT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,
  `userID`          INT UNSIGNED NOT NULL,
  `amount`          INT NOT NULL,
  `transactionType` TINYINT NOT NULL,
  `created`         DATETIME NOT NULL,

  CONSTRAINT money_money_transaction_userID FOREIGN KEY (`userID`) REFERENCES `user_user` (`id`)
    ON DELETE CASCADE
);

我们计划有很多用户，交易表可能会增长到10亿行，所以我的问题是:

它会影响其他表的性能吗？

如果数据库太大而无法容纳在RAM中，那么MySQL是否有某种优化措施，仅将读取最多的表存储在RAM中？

MySQL是否能够正确扩展到这一十亿行？知道我们主要进行插入操作，并且唯一索引在id上(详细信息需要id)，并且没有“批量插入”(在此表上不会同时执行1M插入操作)

另外，我们在RDS服务器上，因此我们可以切换到Aurora，并在需要时尝试进行主-主或主-从复制。您认为在这种情况下会有所帮助吗？

最佳答案

您可能会考虑使用MyRocks(请参阅http://myrocks.io)，它是第三方存储引擎，旨在实现快速INSERT速度和压缩数据存储。我不建议您切换到MyRocks，因为我没有足够的信息来明确说明您的工作负载。但是，我建议您值得花时间评估它，看看它是否对您的应用程序更好。



是的，MySQL(假设InnoDB存储引擎)将部分表存储在缓冲池的RAM中。它将表分解为页面，并在查询请求时将页面放入缓冲池中。就像一个缓存。随着时间的流逝，请求最多的页面保留在缓冲池中，而其他页面则被逐出。因此，它或多或少地平衡了尽可能快地为您的大多数查询提供服务的时间。阅读https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html以获取更多信息。



表没有性能-查询有性能。

缓冲池具有固定大小。假设您有六个需要共享的表，那么它们的页面必须适契约(Contract)一缓冲池。无法为每个表设置优先级，也不能为某些表分配缓冲池空间或将它们“锁定”在RAM中。所有表的所有页面共享相同的缓冲池。因此，当您的查询请求来自各个表的页面时，它们之间确实会相互影响，因为一个表中的频繁请求页面可能会将另一表中的页面逐出。



MySQL具有许多功能来尝试帮助提高性能和可伸缩性(这些功能不相同)。同样，查询具有性能，而不是表。没有查询的表就坐在那儿。是通过不同技术优化的查询。



索引确实会增加插入的开销。您无法消除主键索引，这是每个表的必要部分。但是例如，您可能会发现删除包含索引的FOREIGN KEY值得。

通常，大多数表读取的内容多于写入的内容，因此值得保留一个索引以帮助读取(甚至使用WHERE子句的UPDATE或DELETE)。但是，如果您的工作量几乎全部是INSERT，那么外键的额外索引可能纯粹是开销，并且对任何查询都没有好处。



我在2017年初研究了Aurora的基准测试，发现对于我们测试的应用程序来说，它不适用于高写入流量。您应该始终为您的应用程序对其进行测试，而不是依赖于互联网上某人的猜测。但是我预测，当前形式(大约2017年)的Aurora将完全占用您的所有写入工作负载。

关于在大型只写表上的MySQL性能，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/48036966/