长话短说，我正在开发的应用程序的一部分需要在数据库中存储大量数据，以便应用程序的另一部分稍后获取。通常情况下，该行数小于 2000 行，但有时可能会超过 300,000 行。数据需要暂时保存，之后可以删除。
我一直在思考各种想法，今天想到了一件事。 LONGTEXT 数据类型最多可以存储 2^32 字节，相当于 4 GB。现在，要在一个表行中塞入很多东西。请注意，数据最多可能不会超过 60-80 MB。但我的问题是，实际这样做是个好主意吗？
我目前正在使用的两个解决方案是这样的:
- 将所有数据作为单独的行插入到“临时”表中，该表将在完成后被截断。
- 将所有数据作为序列化字符串插入到行中的
LONGTEXT列中，完成后将删除该列。
纯粹从性能角度来看，将数据存储为可能超过 300,000 个单独的行，还是存储为 60 MB 的 LONGTEXT 条目会更好吗？
如果是一次清洗，我可能会使用LONGTEXT选项，因为它将使应用程序中获取数据的部分更容易编写。它还可以与另一部分更好地结合，从而提高应用程序的整体性能。
如果对此有任何想法，我将不胜感激。
最佳答案
将所有数据序列化为LONGTEXT...亵渎!! :)
说真的，我突然想到，如果你这样做，你将别无选择，只能将其全部提取为一个巨大的部分。另一方面，如果将其分散到单独的行中，则可以让前端以较小的批处理获取它。
至少给自己这个选择似乎是明智之举。 (请记住，低估一次数据的 future 大小要求可能是一个 fatal error !)
如果您正确设计表格，我非常怀疑分布在 300.000 行上的 60MiB 数据是否会比获取 60MiB 文本并在前端解析它的效率低。
最终的问题是:你认为你的前端解析文本的效率比 MySQL 获取文本的效率高吗？
关于mysql - 我可以在一个表列中存储大量数据(<=4GB)。但这是个好主意吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2091541/