长话短说，我正在处理的应用程序的一部分需要在数据库中存储大量数据，以供稍后应用程序的另一部分获取。通常这将小于 2000 行，但偶尔会超过 300,000 行。数据需要临时存储，之后可以删除。
我一直在玩各种想法，今天想到了一件事。该LONGTEXT数据类型最多可存储 2^32 个字节，相当于 4 GB。现在，有很多东西要塞进一个表格行。请注意，数据最多可能不会超过60-80 MB。但我的问题是，实际上这样做是个好主意吗？
我目前正在使用的两种解决方案是这样的：
LONGTEXT完成后将被删除的行中的列中。纯粹从性能的角度来看，将数据存储为可能超过 300,000 个单独的行或存储为 60 MBLONGTEXT条目会更好吗？
如果是清洗，我可能会选择该LONGTEXT选项，因为它会使获取数据的应用程序部分更易于编写。它还将与另一部分更好地结合，这将提高应用程序的整体性能。
我将不胜感激对此的任何想法。
将所有这些数据序列化为LONGTEXT......亵渎神明！:)
不过说真的，我突然想到，如果你这样做，你别无选择，只能把它全部提取成一个巨大的碎片。另一方面，如果将其分散到单独的行中，则可以让前端以较小的批次获取它。
至少给自己这个选择似乎是明智之举。（请记住，低估一次数据的未来大小要求可能是一个致命的错误！）
And if you design your tables right, I doubt very much that 60MiB of data spread over 300.000 rows would be any less efficient than fetching 60MiB of text and parsing that on the front-end.
Ultimately the question is: do you think your front-end can parse the text more efficiently than MySQL can fetch it?
This should be fine as long as you use a memory storage engine. In MySQL, this means using the MEMORY storage engine instead of InnoDB or MyISAM. Otherwise disk usage will bring your app to its knees.
什么样的数据以及如何使用？在应用程序的内存中存储和处理它可能会好得多。至少，它会快得多并且不会加载数据库引擎。
You could always store it in the database as the 300,000 row format and use memcached to cache the data so you don't have to do it again. Please note that memcached stores it in the memory of the machine so if your using a lot of this data you may way to set a low expire on it. But memcached significantly speeds up the time to fetch data because you dont have to do queries every page load.
If you're going to just be writing a large, temporary BLOB you might consider writing to a temporary file on a shared file system instead.