假设我有一个包含 25,000 行左右的表：
item_id, item_name, item_value, etc...
我的应用程序将允许用户生成动态列表，每个列表包含 2-300 个项目。
我应该将所有这些关系存储在一个带有列的巨型表中dynamic_list_id, item_id吗？每个动态列表最终将在此表中包含 2-300 行，并且表的大小可能会膨胀到数百万甚至数十亿。
这个表也将被非常频繁地查询，每秒检索几个这样的动态列表。 一张大桌子是最好的选择吗？将其拆分为动态表是否有意义，可能由用户命名？
在为这样的大量数据准备数据库时，我真的很茫然，所以任何见解都将不胜感激。
它是一个关系数据库，它是为这种事情而设计的——去做吧。仅仅几百万行甚至不算“巨大”。不过，请仔细考虑索引 - 您必须平衡插入/更新性能、存储空间和查询性能。
是的，我建议您采用您提出的设计：“一个包含 dynamic_list_id、item_id 列的巨型表。”
通过索引选择、增加主轴和读/写臂的数量以及 SSD 缓存，可以根据需要轻松解决性能问题。
而且从整体上看，这个数据库看起来并不是特别大。如今，成为一个 BIG 数据库需要数十或数百 TB。
对于如此大的表，请确保将引擎设置为 InnoDB 以获取行级锁。
确保您明智地使用索引。
如果您的查询开始拖动，请增加 Innodb_buffer_pool 的大小以进行补偿。