我正在尝试使用以下查询在mysql(版本5.7.38-1)中复制一个表:
CREATE TABLE dest LIKE src;
INSERT INTO dest SELECT * FROM src;
创建了表dest并填充了来自表src的记录。到目前为止,一切都很顺利。您可能希望两个表的大小大致相同。但是表dest有646 M,而表src只有134 M。在创建步骤之后,表dest为48 K,与预期的差不多。
引擎为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.出现这种意外行为的原因是什么?
1.什么是使Table dest更小的解决方案?
谢谢你的见解。
1条答案
按热度按时间uujelgoq1#
各种可能性。最有可能的是索引。
什么引擎?压缩打开了吗?什么行格式?
请提供
SHOW CREATE TABLE src
。INSERT ... SELECT ...
将一次一行地将行输入到表中(但是比每行一条INSERT
语句快得多)。如果引擎是InnoDB
,那么src
行可能是按PRIMARY KEY
顺序的。插入到dst
的最佳顺序也是这个顺序。所以我希望数据的BTree能被有效地“整理碎片”。辅助索引是另一回事。它们可能被有效地排序,也可能没有。“更改缓冲区”可能补偿排序,也可能没有。每个辅助索引的结果BTree可能被“碎片整理”,也可能没有。
什么版本的mysql/mariadb?我可能有一个工具来更深入地研究这个问题。