我遇到了一个有趣的情况，虽然不是实际问题，但我无法理解为什么会发生这种情况。
我们有一个 mongo 数据库，主要由存储在数组中的一些批量数据组成。由于团队中超过 90% 的人熟悉 mysql，而只有少数人熟悉 mongo，再加上这不是关键数据库，所有查询都是在 2 个字段(客户端或产品)上完成的)我们决定将数据移到 mysql 中，在这样的表中
[idProduct(bigint 无符号)、idClient(bigint 无符号)、数据 (json)]
其中数据是一个巨大的 json，包含数百个属性及其值。
我们还通过 idClient 上的哈希将其划分为 100 个分区。
PARTITION BY HASH(idClient)
PARTITIONS 100;
一切正常，但我注意到一个有趣的事实:
原始的 mongo 数据库大约有 70 GB，或多或少。 mysql 版本(实际上包含较少的数据，因为重新删除了我们在 mongo 中用作索引的一些重复项)超过 400 GB。
为什么它需要这么多空间？理论上bson实际上应该比json略大(至少在大多数情况下)。即使 mysql 中的索引更大...差异也是巨大的(超过 5 倍)。
最佳答案
我做了一个演示How to Use JSON in MySQL Wrong ( video )，其中我将 Stack Overflow 数据转储导入到 MySQL 中的 JSON 列中。我发现我测试的数据比使用每列的常规数据类型将相同数据导入到普通表和列中所占用的空间多出 2 到 3 倍。
JSON 对相同数据使用更多空间，例如，因为它将整数和日期存储为字符串，还因为它在每一行存储键名称，而不是仅在表头中存储一次。
这是比较 MySQL 中的 JSON 与 MySQL 中的普通列。我不确定 MongoDB 如何存储数据以及为什么它要小得多。我读到 MongoDB 的 WiredTiger 引擎支持压缩选项，并且 snappy compression is enabled by default since MongoDB 3.0 。也许您应该启用 compressed format in MySQL看看这是否可以提高存储效率。
MySQL 中的 JSON 存储方式类似于 TEXT/BLOB 数据，因为它被映射到一组 16KB 的页面中。前 32 页(即最多 512KB)一次分配一个页。如果内容长于此，则以 64 页 (1MB) 为增量进行进一步分配。因此，如果单个 TEXT/BLOB/JSON 内容为 513KB，则可能会分配 1.5MB。
关于mysql json vs mongo - 存储空间，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/66873490/