假设我有一个包含25,000行左右的表：
item_id, item_name, item_value, etc...
我的应用程序将允许用户生成每个2-300个项目的动态列表。
我是否应该将所有这些关系存储在包含dynamic_list_id, item_id列的巨型表中？每个动态列表最终会在此表中有2-300行，并且表的大小可能会膨胀到数百万甚至数十亿。
此表也会经常查询，每秒检索几个动态列表。 最好的方式是一张巨大的桌子吗？将它拆分为动态表是否有意义，可能由用户命名？
在为这样的大量数据准备数据库时，我真的很茫然，所以任何洞察都会非常感激。
答案 0 :(得分：3)
这是一个关系型数据库，它专为此类设计而设计 - 只需要它。仅仅几百万行甚至不算“巨人”。尽管如此，请仔细考虑索引 - 您必须平衡插入/更新性能，存储空间和查询性能。
答案 1 :(得分：2)
是的，我建议使用你提出的设计：“一个包含列dynamic_list_id，item_id的巨型表。”
通过索引选择，增加主轴和读/写臂数以及SSD缓存，可以根据需要轻松解决性能问题。
在宏观方案中，这个数据库看起来并不是特别大。这些天需要数十或数百TB作为BIG数据库。
答案 2 :(得分：1)
使用如此大的表格时，请确保将引擎设置为InnoDB以进行行级锁定
确保明智地使用索引。
如果您的查询开始拖动，请增加Innodb_buffer_pool的大小以进行补偿。