MySQL 大型只写性能 table

Question

提前感谢您的回答，抱歉我的英语不好，我不是母语人士。

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

为了读取用户余额，我们有一个中介 table，其中用户余额在每次交易时都会更新，因此用户永远不会直接读取交易 table ，以减少高流量的负载。

交易table在后台不时被唯一读取。

这是交易的架构 table :

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
);

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

会影响其他table的性能吗？
如果数据库太大而无法放入 RAM，MySQL 是否进行了某种优化，仅将最常读取的 table 存储在 RAM 中？
MySQL 是否能够正确扩展到这一十亿行？知道我们主要是插入并且唯一的索引在 id 上（详细信息需要 id）并且没有 "bulk insert"（不会有 1M insert 在这个 table 上并发执行）
此外，我们在 RDS 服务器上，因此我们可以切换到 Aurora 并在需要时尝试主-主或主-从复制。您认为这对这种情况有帮助吗？

Answer 1

您可能会考虑 MyRocks（请参阅 http://myrocks.io），这是一个第三方存储引擎，专为快速 INSERT 速度和压缩数据存储而设计。我不会建议您应该切换到 MyRocks，因为我没有足够的信息来针对您的工作量做出关于它的明确声明。但我会建议您值得花时间对其进行评估，看看它是否更适合您的应用程序。

If the database is too large to fit in RAM, does MySQL have some sort of optimisation, storing in RAM only the most read table ?

是的，MySQL（假设是 InnoDB 存储引擎）将部分 table 存储在内存中的缓冲池中。它将 table 分解为页面，并在查询请求时将页面放入缓冲池中。这就像一个缓存。随着时间的推移，请求最多的页面会保留在缓冲池中，其他页面会被逐出。因此，它或多或少地平衡了尽快为您的大部分查询提供服务。阅读 https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html 了解更多信息。

Will it affect the performance of other tables ?

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

缓冲池有固定大小。假设您有六个 table 需要共享它，它们的页面必须适合同一个缓冲池。无法为每个 table 设置优先级，也无法在 RAM 中为某些 table 或 "lock" 指定缓冲池 space。所有 table 的所有页面共享同一个缓冲池。因此，当您的查询请求来自不同 table 的页面时，它们确实会相互影响，因为来自一个 table 的频繁请求的页面可能会驱逐来自另一个 table 的页面。

Does MySQL will be able to scale correctly up to this billion row ?

MySQL 有许多功能可以帮助提高性能和可扩展性（它们不是一回事）。同样，查询具有性能，而不是 tables。没有查询的 table 只是坐在那里。它是通过不同技术优化的查询。

Knowing we do mostly insert and that the only index is on the id (the id is needed for details) and that there is no "bulk insert" (there will not be 1M insert to do concurrently on this table)

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

通常，大多数 table 的读取次数多于写入次数，因此值得保留一个索引来帮助读取（甚至是使用 WHERE 子句的 UPDATE 或 DELETE）。但是，如果您的工作负载几乎都是 INSERT，那么外键的额外索引可能纯粹是开销，对任何查询都没有任何好处。

Also, we're on a RDS server, so we could switch to Aurora and try a master-master or master-slave replication if needed. Do you think it would help in this case ?

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

MySQL 大型只写性能 table

MySQL performance on large, write-only table

mysql

sql

database

amazon-aurora