极光，我的数据在哪里？针对 MySQL 的极限 IOPS 优化

今天，我决定在Amazon Aurora上运行另一个荒谬的测试，这次使用的是不同的MySQL引擎。

MySQL和Aurora的荒谬实验

Amazon RDS 和 Amazon Aurora 完全支持 MySQL 数据库实例的 InnoDB 存储引擎。快照还原等功能仅支持InnoDB存储引擎。但InnoDB并不是RDS for MySQL或Aurora MySQL上唯一可用的引擎。

您可以看到所有启用的引擎都运行一个简单的：

MySQL> show engines;

+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
| MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+

InnoDB是默认引擎，也是您应该（几乎）用于每个表的引擎。除非您不关心表中存储的数据。

但InnoDB并不是RDS上最快，最轻的存储引擎。不，我不是在谈论MyISAM，我说的是垃圾桶，黑洞存储引擎：

BLACKHOLE存储引擎充当“黑洞”，接受数据但将其丢弃并且不存储它。检索始终返回空结果。

什么？

优化 IOPS 并减少数据问题的最佳方法是不要首先保留数据。好的，我们将存储更少的数据，但我们真的在 CPU 使用率方面有好处吗？存储（无用的）数据到底要花多少钱？

有什么真正的区别吗？

我们将运行一个小实验，以 4 ACU（约 8GB）的固定大小运行 Aurora 无服务器实例。

让我们创建一个简单的表和一个过程来填充一些（百万和无用的）记录。这里没有什么花哨的，只是一些随机数字和每次通话的 500 万条记录。

CREATE TABLE data
(id bigint(20) NOT NULL AUTO_INCREMENT,
datetime TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP,
value float DEFAULT NULL,
PRIMARY KEY (id)) ENGINE=InnoDB;

DELIMITER $$
CREATE PROCEDURE generate_data()
BEGIN
  DECLARE i INT DEFAULT 0;
  WHILE i < 5000000 DO
    INSERT INTO data (datetime,value) VALUES (
      FROM_UNIXTIME(UNIX_TIMESTAMP('2022-01-01 01:00:00')+FLOOR(RAND()*31536000)),
      ROUND(RAND()*100,2));
    SET i = i + 1;
  END WHILE;
END$$
DELIMITER ;

我们现在可以调用我们的简单过程（两次，以查看结果不是随机的和可重现的），并将数据库的指标与InnoDB和BLACKHOLE引擎进行比较。我们在执行之间休眠一段时间（200 秒），以获得更清晰的指标：

CALL generate_data();
SELECT sleep(200);
CALL generate_data();

SELECT sleep(200);
ALTER TABLE data ENGINE=BLACKHOLE;

CALL generate_data();
SELECT sleep(200);
CALL generate_data();