☰

如何从 MySQL 转储计算 AWS RDS 实例的大小？

tag-icon • tag-icon amazon-web-services mysql amazon-rds
如何从 MySQL 转储计算 AWS RDS 实例的大小？

我们正在从 mysqldump 将大型历史数据库导入 RDS

gzip 压缩的 SQL 文件为 3GB，未压缩的 SQL 文件为 18GB。

我们创建了一个 30GB 的 AWS RDS 实例并导入了文件...RDS 实例空间不足。

我们创建了一个 50GB 的 AWS RDS 实例，导入了文件...RDS 实例空间不足。

如何计算导入此转储所需的 AWS RDS 实例的大小？

尝试预先回答任何问题...

  • 我们无法访问产生转储的机器，因此无法尝试以这种方式确定其大小。
  • 我以为可能是 RDS 二进制日志或慢日志占用了空间，但查看之前的实际数据库大小发现它实际上都在数据库中...... 
    mysql>  SELECT table_schema "Database Name", sum( data_length + index_length ) / 1024 / 1024 "Database Size in MB"  FROM information_schema.TABLES GROUP BY table_schema ; 
+--------------------+----------------------+
| Database Name      | Database Size in MB  |
+--------------------+----------------------+
| xxxxxxxxxx         |       41658.15374756 |
| information_schema |           0.00976563 |
| mysql              |           5.96341228 |
| performance_schema |           0.00000000 |
+--------------------+----------------------+
4 rows in set (28.39 sec)

答案1

如果对正在使用的索引一无所知，就无法估计实时数据库所需的存储空间。每个索引本质上都是一张地图，地图的“键”越多，该地图所需的存储空间就越大。

如果索引列的数据类型大于 bigint，索引的基数（数据“形状”，本质上是唯一“键”的数量以及它们如何映射到包含该键的行）也变得很重要。对于相同的表大小，具有大量唯一组合（高基数）的 varchar(60) 索引列将比具有低基数的索引列占用更多的存储空间，因为映射中的键比映射中的数据指针占用更多的存储空间。

更新：感谢下面的迈克尔，我当然应该说，我关于基数和存储大小的断言取决于存储引擎。

例如，一个数据库有两个 InnoDB 表，每个表都有 2176 行，每行 3 列，并且 VARCHAR(32) 列有一个索引。这两个表的数据的唯一区别在于，tt1 的 VARCHAR 列有 2176 个唯一值，而 tt2 的 VARCHAR 列有相同的值。

您将看到索引大小仅相差约 16kb：

mysql> select TABLE_NAME, TABLE_ROWS, DATA_LENGTH, INDEX_LENGTH from TABLES where TABLE_SCHEMA='t_idb1';
+------------+------------+-------------+--------------+
| TABLE_NAME | TABLE_ROWS | DATA_LENGTH | INDEX_LENGTH |
+------------+------------+-------------+--------------+
| tt1        |       2031 |      180224 |       147456 |
| tt2        |       2031 |      180224 |       131072 |
+------------+------------+-------------+--------------+

请注意，InnoDB 数据存储有 2 个组件：数据字典（默认存储在 mysql 数据目录中的全局表空间文件 ibdata1 中）和表数据（存储在数据目录子目录中的 .frm 文件中）。

这就是为什么 Michael，您看不到 .frm 文件的存储大小有什么不同。如果您使用 innodb_file_per_table=1 指令重新启动 MySQL，您会看到此差异反映在表空间文件中：

drwx------. 2 mysql mysql   4096 Dec 19 10:52 .
drwxr-xr-x. 4 mysql mysql   4096 Dec 19 10:52 ..
-rw-rw----. 1 mysql mysql     65 Dec 19 10:52 db.opt
-rw-rw----. 1 mysql mysql   8610 Dec 19 10:52 tt1.frm
-rw-rw----. 1 mysql mysql 393216 Dec 19 10:52 tt1.ibd
-rw-rw----. 1 mysql mysql   8610 Dec 19 10:52 tt2.frm
-rw-rw----. 1 mysql mysql 376832 Dec 19 10:52 tt2.ibd

InnoDB 存储的独特之处在于，表数据实际上是数据字典的索引，这为某些操作带来了一些性能优势。因此，基数对存储要求的影响（在本例中约为 10%）与 MyISAM 大不相同：

mysql> select TABLE_NAME, TABLE_ROWS, DATA_LENGTH, INDEX_LENGTH from TABLES where TABLE_SCHEMA='t_msm';
+------------+------------+-------------+--------------+
| TABLE_NAME | TABLE_ROWS | DATA_LENGTH | INDEX_LENGTH |
+------------+------------+-------------+--------------+
| tt1        |       2126 |       85040 |        87040 |
| tt2        |       2126 |       85040 |         7168 |
+------------+------------+-------------+--------------+

drwx------.  2 mysql mysql  4096 Dec 19 09:50 .
drwxr-xr-x. 13 mysql mysql  4096 Dec 19 10:29 ..
-rw-rw----.  1 mysql mysql    65 Dec 19 09:28 db.opt
-rw-rw----.  1 mysql mysql  8610 Dec 19 09:31 tt1.frm
-rw-rw----.  1 mysql mysql 85040 Dec 19 09:48 tt1.MYD
-rw-rw----.  1 mysql mysql 87040 Dec 19 09:48 tt1.MYI
-rw-rw----.  1 mysql mysql  8610 Dec 19 09:50 tt2.frm
-rw-rw----.  1 mysql mysql 85040 Dec 19 09:51 tt2.MYD
-rw-rw----.  1 mysql mysql  7168 Dec 19 09:51 tt2.MYI

希望这可以解释得更清楚一些。

相关内容