任何SQL数据库:什么时候提取整个表而不是查询特定的行更好?

我坚信在最初的情况下,选项1应该是首选的。 当您遇到性能问题时,您可以查看如何使用缓存优化它。(Dijkstra曾经说过,预先优化是万恶之源)。

另外,请记住,如果您选择选项3,那么您也将通过网络发送完整的表内容。这也会影响性能。

在10公里到10万行的比赛中,第一名是我最明显的赢家。如果它是<1K,我可能会说让它缓存在应用程序中,但是有了这么多行,让DB做它设计要做的事情。有了适当的索引,数字1将是最好的选择。

如果您每次都在提取相同的数据集,那么缓存结果也可能是一个更好的选择,但是当您要在不同的时间段使用不同的数据集时,最好让数据库来处理它。

不过,正如我所说的,只要确保在所有适当的字段上索引良好即可。

在我看来, 设计 对于信息的快速搜索、切片和切分,要比一般开发人员的代码快得多。另一方面,您没有提到的一些因素包括与应用程序相关的数据库服务器的位置或潜在位置——在较慢的网络上返回大型数据集肯定会有利于“全部获取并在本地搜索”选项。我认为,在“一般”情况下,我建议查询您想要的内容,但在特殊情况下,其他选项可能更好。

根据我的经验,最好是查询您想要的内容,并让数据库找出最好的方法。您可以检查查询计划,看看您是否有任何可以由索引帮助的瓶颈。

首先,让我们驳回2。搜索表是数据服务器存在的原因,而且它们几乎肯定会比您编写的任何即席搜索做得更好。

对于3,您只需说“根据需要过滤输出”,而不必说在哪里完成了过滤。如果它在应用程序代码中如2所示,那么,与2所示,您会遇到与2相同的问题。

专门创建了数据库来处理这个确切的问题。他们很擅长。让他们去做吧。

这个 只有 使用选项1以外的任何内容的原因是 WHERE 条款本身是巨大的(即如果 哪里 子句分别标识每一行,例如 WHERE id = 3 or id = 4 or id = 32 or ... )

还有什么改变你的数据吗?让SQL引擎以最佳方式进行切片和切块是一个很好的方法。但是,如果您使用的是一个数据库,并且没有“其他人”更改数据的可能性,那将是非常令人惊讶的。如果可以在其他地方进行更改,您肯定希望经常重新查询。

相信SQL Server在缓存和筛选方面所做的工作会比您自己所能做的更好(除非性能测试另有说明)。

请注意,我说过“做得起”而不仅仅是“做”。你也许可以做得更好,但你的报酬(大概)是提供功能而不是缓存。

问问你自己…是否花费时间编写缓存管理代码来帮助您完成需求文档?

如果你这样做:

SELECT * FROM users;

MySQL应该执行两个查询:一个是了解表中的字段,另一个是返回所需的数据。

做

SELECT id, email, password FROM users;

MySQL只访问数据,因为字段是显式的。

关于限制:总是ss最好查询您将需要的行的数量,不多不少。更多的数据意味着有更多的时间来驱动它