数据库表获取太多数据 - 需要另一个解决方案

Question

我有一个网站，人们可以在其中添加他们最喜欢的电视剧。有一项功能可以让您核对已看过的剧集。

选中的每一集都会在数据库表中创建一条记录（包含 user_id、show_id 和 Episode_id）。
该表现在已超过 600.000 行，并且增长速度非常快！

我已经设置了索引，但是我感觉查询这个表时的性能越来越差。

我对新解决方案的想法：

因此，

user_id | show_id | episode_id  
1 ....... 123 ......7675  
1 ....... 123 ......7676   
1 ....... 123 ......7677  
1 ....... 456 ......5678  
1 ....... 456 ......5679  
1 ....... 456 ......5680  

我可以这样做：

user_id | show_id | episode_ids  
1 ....... 123 ......7675,7676,7677  
1 ....... 456 ......5678,5679,5680

然后我必须将字符串拆分为数组，并使用 array.include?(some-id)。
这应该可以减轻数据库的负担，但是 Ruby 需要处理更繁重的数组代码。

我走在正确的轨道上吗？或者有人能想到更好的解决方案吗？

Answer 1

不不不，这绝对不是构建这样一个数据库的方式。 varchar 字段中的逗号分隔列表是您应该考虑的最不理想的反模式。

在我看来，您的性能问题似乎是基于猜测。因此，应该：

• 确定是否确实存在问题
• 使用适当的工具查找问题原因
• 在非生产环境中测试可能的解决方案。

600k 行不算什么（在具有三个整数的表中）。真的。即使是最小的服务器上的内存也可以使用。从内存中查询表应该很快，您不必担心。

如果您完成了第 1 步（确实存在问题），请提出进一步的问题，其中包含整个相关架构、精确查询、解释计划和计时数据。

Answer 2

是否对数据进行非规范化是一个有争议的问题。在特定情况下它可能有其优点，但从关系的角度来看，它可能不应该是您的首选。相反，解决这个问题的首选第一步应该是分析它并实施不改变数据结构但主要处理数据库系统及其环境的解决方案。因此：

• 您的问题根源真的是数据库吗？或者是其他系统（网络、网络服务器、rails 等）？
• 就查询响应时间而言，什么是可接受的？找出数据库在所有情况下都应遵守的具体数字。
• 哪些查询变慢了？也许您有可以重构的缓慢、低效的查询。制定一个查询计划，看看优化器在做什么。
• 您是否以正确的方式使用索引？
• 调整您的 mysql 实例。通过调整您可以取得很多成果。
• 看看您可以在硬件方面做一些事情（获得更多内存、更快的磁盘等）
• 为最常用的查询创建视图（如果有）
• 如果完成上述所有操作，您仍然可以进行分片。这会增加应用程序的一些复杂性，但它允许您在很大程度上扩展系统而不需要太多的努力。
• 最终您可能会得出这样的结论：您必须使用“真正可扩展的”分布式键/值存储（nosql）。但对于 600k 行，要达到这一点还有很长的路要走。

话虽这么说，如果您发现您提出的解决方案是提高性能的最佳方法，请继续进行非规范化。关键是，您应该了解所有选项，并根据具体的性能相关目标选择最佳选项。

Answer 3

以下是我构建表的方式：

USERS
userid INTEGER PRIMARY KEY 
username text/varchar/whatever

SHOWS
showid INTEGER PK
showname   varchar or nvarchar or text  [depending on what database I was using]
etc etc


EPISODES
episodeid INTEGER PK
showid    INTEGER  FK references SHOWS   [index this field]
ordinal   DECIMAL   [indicates which episode  -- DECIMAL makes it easier to insert later an episode you overlooked] 
episodename text/varchar/nvarchar whatever   
etc etc

SEENIT
id  INTEGER AUTOINCREMENT  PK
userid  INTEGER    foreign key ref USERS
episodeid  INTEGER foreign key ref EPISODES

您可以在 (userid, Episodeid) 上放置一个备用的唯一复合索引，或者使用单独的索引，一个在 userid 上，一个在 Episodeid 上。我可能会选择后者。

Answer 4

我会坚持使用标准化数据。这听起来更像是一个查询优化问题。请记住，mysql（假设您正在使用它）每个查询仅使用一个索引，并且通过设置复合索引可能会获得更好的性能。
还可以使用 mysql 查询浏览器中的 EXPLAIN 语句。更多信息请点击这里：
http://dev.mysql.com/doc/refman/5.1/en /解释.html