为什么 AWS RDS MYSQL INSERT 需要读取 IOPS？答案

【问题标题】：Why is AWS RDS MYSQL INSERT taking READ IOPS?为什么 AWS RDS MYSQL INSERT 需要读取 IOPS？
【发布时间】：2016-04-18 12:10:32
【问题描述】：

我有 4000 PIOPS 的 db.r3.2xlarge。我从 EC2 实例中插入了 10 亿行。现在有大约 40GB 的可用 RAM。

目前，在 4000 个 PIOPS 中，READ PIOPS 需要 3000 个，而我只需要 1000 个 WRITE PIOPS。所以，这是一篇低级的文章。

我如何检查哪个正在使用 READ PIOPS？以及如何加快速度？

谢谢。

编辑：

insert ignore into dna (hash, time, song_id) values (b%s, b%s, %s)

I'm using self.cursor.executemany(query, rows) 来自 python

hash + time + song_id 是复合主键。

我正在使用 AWS RDS InnoDB。

我有 4000 PIOPS。然而，它现在停留在 2000 的总数。我有 60MB/s 的写入吞吐量。

【问题讨论】：

【解决方案1】：

如果哈希是您的主键或已编入索引，则您没有按主 my 和/或索引顺序插入。

另外，您正在使用INSERT IGNORE，这表明您正在尝试避免不可避免的重复键错误，因为您插入的内容中有重复数据。

出于这两个原因，InnoDB 必须做很多准备工作，以便将磁盘上的表空间中的适当页面加载到内存中，以便在主索引和/或任何二级索引中找到下一行需要的位置去，如果该行是重复的，这可能会浪费精力，并且可能需要进行页面拆分，以便有可用空间将下一个哈希随机插入到适当的位置。

如果 hash 是主键，那么在插入时删除所有其他索引可能对您有利，然后在末尾添加它们，这样可以更有效地构建它们。

如果批次足够大并且哈希确实是主键，则通过哈希对插入进行预排序应该会有所帮助。

【讨论】：

我的显示创建表看起来像 - CREATE TABLE dna (hash bit(26) NOT NULL, time bit(14) NOT NULL, song_id mediumint(9) NOT NULL , 主键 (hash,time,song_id) 使用 BTREE ) ENGINE=InnoDB 默认字符集=latin1
bit(26) 是一个有趣的选择。我假设您意识到（如果我的数学是正确的）此列只能支持 67,108,864 (2^26) 个唯一哈希。您是否按 (hash,time,song_id) 的排序顺序插入行？
您好，我不确定您所说的排序顺序是什么意思。我的主键是（hash + time + song_id），所以它不仅仅是位（26）。在决定它是否唯一时，它还会考虑 time + song_id。不是吗？