基本问题:查询数据和性能权衡

时间:2011-07-31 17:29:31

标签: mysql database json database-design

假设我的表中有100行,有3列数字。我不需要所有的行,每次获取数据时只需要大约一半的行。我只想要更新的行,其余部分将是多余的。

添加一个字段并给它一个datetime字段来表示自上次我提取它以来它已更新(并在SELECTing时将其用作标准)是否更好?或者最好只是每次都下载所有数据(目前数据是作为JSON文件发回的)。

在这两个选项之间的速度,带宽使用和服务器CPU使用方面有哪些权衡?前者是否比后者更好?

3 个答案:

答案 0 :(得分:1)

始终(或至少在可能的情况下)仅选择完成任务所需的数据。反之亦然:永远不要选择必须过滤的数据。结果:为更新添加时间戳字段,并仅选择时间戳为>的这些行。比给定的。

答案 1 :(得分:1)

如果您不介意服务器在少于几十毫秒的时间内返回数​​据,那么表中有100行和3列数字,您使用哪种方法无关紧要。如果频繁查询,那么行无论如何都将在内存中。它还使您的json代码更简单,您的客户端代码更简单(这可能是好的,更易于维护)。

如果你有几百万行表只需要一小部分数据,你自然希望限制返回集,最简单的方法是使用SQL WHERE子句,例如WHERE dt_modified > my_timestamp。在正确优化的数据库上,即使这个查询也可能在100毫秒以内。

问题可能更多地与数据在线上花费的时间,客户花费多少时间重新生成页面或根据返回的数据更新数据有关。客户端处理时间通常是该过程中最慢的部分。只有在不同的浏览器和不同的网络速度上进行测试才能在服务器端tweek,网络修复(例如gzipping压缩数据)和优化javascript调用之间找到最佳平衡。

答案 2 :(得分:1)

Jens Struwe和roycl都是对的 - 但是当你提出一个假设的问题时,你会得到正确矛盾的答案。

如果只有一半的数据是相关的,那么客户如何确定要显示哪些数据?如果可以通过软件做出决定,那么在数据库上做这件事会更有效率 - 但它也更符合逻辑。

对于100行的表,性能既不在这里也不在那里;可维护性和长期可升级性是一个更大的交易。大多数开发人员都希望在数据库而不是客户端上进行逻辑数据库设计和排序/过滤。