创建表之后的MySQL表的意外尺寸增加，然后插入

Question

我正在尝试使用以下查询来复制MySQL（版本5.7.38-1）中的表格：

CREATE TABLE dest LIKE src;
INSERT INTO dest SELECT * FROM src;

创建表DENT并填充表SRC中的记录。到目前为止，一切都很好。您希望这两张桌子的尺寸大致相同。但是Table DEST具有646m，而Table SRC只有134m。创建步骤之后，表格为48K，或多或少是预期的。

引擎是InnoDB，默认行格式是动态的，并且压缩正在打开。

我已经执行了以下操作，以查看它是否会有所帮助，但无济于事：

ALTER TABLE dest ROW_FORMAT=COMPRESSED;
OPTIMIZE TABLE dest;

这是show create table src：

CREATE TABLE `src` (
  `meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `post_id` bigint(20) unsigned NOT NULL DEFAULT '0',
  `meta_key` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `meta_value` longtext COLLATE utf8mb4_unicode_ci,
  PRIMARY KEY (`meta_id`),
  KEY `post_id` (`post_id`),
  KEY `meta_key` (`meta_key`(191))
) ENGINE=InnoDB AUTO_INCREMENT=6046271 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

我知道MySQL版本已经过时了，但是更改了我的控制范围。

两个问题：

1. 这种意外行为的原因是什么？
2. 什么解决方案是使餐桌更小的解决方案？

感谢您的见解。

Answer 1

各种可能性。最有可能的是索引。

什么引擎？压缩了吗？哪种行格式？

请提供显示创建表Src。

插入...选择...一次将行馈入表格一（但比一个insert每行要快得多）。如果引擎为Innodb，则大概是src行在主键 order中。插入dst的最佳顺序也是该顺序。因此，我希望数据的btree有效地“碎片片”。

次要索引是另一回事。他们可能会有效订购或可能不会有效。 “更改缓冲区”可能会或可能不会补偿订购。每个二级索引的最终btree可能会“碎片碎片”。

哪个版本的MySQL/Mariadb？我可能有一个工具可以更深入地研究这个问题。