为什么将字符集从 utf8mb4 更改为 utf8 后表的索引存储大小更大？

Question

执行：alter table device_msg convert to character set 'utf8' COLLATE 'utf8_unicode_ci';"

正如我所料，表数据大小变小了。

但与此同时，表索引大小变大了？

发生了什么以及为什么？

ps：表数据大小和索引大小由information_schema.TABLES计算

---

数据库引擎：InnoDB

前表：

CREATE TABLE `device_msg` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `sn` varchar(30) COLLATE utf8_unicode_ci NOT NULL,
  `time` datetime(3) NOT NULL,
  `msg` json NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `device_UNIQUE` (`sn`,`time`)
) ENGINE=InnoDB AUTO_INCREMENT=62077733 DEFAULT CHARSET=utf8mb4;

之后的表格：

CREATE TABLE `device_msg` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `sn` varchar(30) COLLATE utf8_unicode_ci NOT NULL,
  `time` datetime(3) NOT NULL,
  `msg` json NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `device_UNIQUE` (`sn`,`time`)
) ENGINE=InnoDB AUTO_INCREMENT=62077733 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;


之前：

totalSize: 2.14 GB
indexSize: 282.98 MB
dataSize: 1.86 GB
avg_row_len:  297B

之后

totalSize: 1.93 GB
indexSize: 413.97 MB
dataSize: 1.52 GB
avg_row_len:  260B

如果information_schema.TABLES的数据不准确，

如何做到正确？

Answer 1

• utf8mb4 占用的空间，然后是 utf8（假设事先没有 4 字节字符）是相同的，不管你显示的数字是多少。

  李>

• 这个ALTER 需要重建表和索引。

• InnoDB 在 BTree 中构建数据和每个二级索引。

• 根据将元素插入 BTree 的顺序，会发生更多或更少的“块拆分”。

所以，你不能说到底是字符集改变还是重建导致索引变大而数据变小。

我说这是不是字符集更改。

Answer 2

在我看来

正如我在 MySQL 上阅读的有关限制的文档。

https://dev.mysql.com/doc/refman/5.6/en/innodb-restrictions.html

默认情况下，索引键前缀长度限制为767字节

如果索引列超过这个大小，它将被截断。 我假设您的索引列值有 255 个字符。

对于 utf8mb4，1 个字符 = 4 个字节，限制为 191 个字符左右。 因此 191 个字符将添加到索引中，其他 (255-191=64) 个字符将从索引中截断。

当您将编码更改为 utf8（当时 1 个字符 = 3 个字节）时，索引限制将变为大约 255 个字符。 这意味着您的列值，所有 255 个字符，将被添加到索引中而不被截断。

添加到索引的字符从 191 个字符增加到 255 个字符，因此索引大小也增加了。