多连接或简单可读的数据库调用

Question

好奇其他开发人员对此有何感想。我遇到了一些非常讨厌的sql连接，我确信我们都会这样做。为了可读性和简单性，我更喜欢发出更多的数据库调用，而不是要维护一个大型SQL语句；大约3-4连接。对于性能参数，我会为了可读性放弃一些性能。

例如:进行第一个调用，过滤数据，然后查询第二个表，依此类推。

你的喜好是什么？

Answer 1

根据我的经验，较大的查询为Server提供了更多出错的机会。使用较小的查询可以帮助Server使用良好的查询计划。例如，在您的开发环境中，Server可能会按照您编写的顺序执行一个大型查询。稍后，当代码迁移到生产时，突然之间数据就大不相同了。Server可能会做出错误的假设，并选择在中间启动查询，突然之间，您会以疯狂的联接结束，从而创建了数十亿条临时记录，这些记录会被假脱机地转移到tempdb。

针对大型数据库的复杂查询性能各不相同。有时，有一个复杂的查询效果更好，因为它只处理数据一次。有时，分离步骤的速度更快，可读性更强，因为在执行其余步骤之前，可以确保第一个查询的结果将数据限制为一小部分行。

我尝试对不同的逻辑步骤使用单独的查询。我将用注释记录每一步，以便更容易地记住它试图完成的任务。例如：

1. 做一些预处理，找出用户想要什么。
2. 收集数据，过滤用户的选择
3. 从定价表中填写一些基于日期的数据。
4. 丢弃一些由于某些罕见的情况而不相关的记录。
5. 填写一些字段以供报告之用
6. 返回结果

如果您正在加入多个子查询级别(如Bill的示例)，那么将子查询拆分成单独的步骤可以提高性能。

还请注意，在创建、填充、索引和从临时表中选择时，您的计划可能会产生更多的I/O。

最后，如果它没坏--别修好它！

Answer 2

如果它只是3-4个简单的联接，我可能不会太担心它；在任何相当大的数据库中，这一点都不多。我已经看到SQL查询接近于这个数目的几十个联接，子联接到子联接--现在它开始变得难以处理了！通常，当孤立的时候，几乎每一个都有一个很好的理由，但在某个时候，它从合理到不合理到完全疯狂，只需要“多一个”条件或领域。在某些时候，您需要考虑对查询进行重构(当您发现为了获得合理的性能，连接排序变得非常重要，或者需要查询提示，这通常是一个很大的警告标志)，并将其分解为多个较小的查询，但除非这些连接确实可怕，否则我认为您还没有达到这个程度。

不过，最重要的一条规则是实际尝试。看看执行计划。数据库服务器是否最有效地利用了索引，或者您是否可以在某些表上添加一个过滤的索引，以帮助性能而不会对其他地方造成太大的伤害？重写查询，比较执行时间、I/O需求和执行计划。它真的有用吗？还请记住，在任何重要的查询中，通过重写它(即使看起来“简单”)，您就有引入bug的风险。

Answer 3

提示:可以对SQL查询进行注释，以帮助理解它们是如何工作的。同样的技巧也适用于正则表达式。

如果您认为多个查询优于一个大型(编写良好)查询，则应该使用RDMS服务器进行尝试，该服务器与应用程序服务器不在同一台机器上运行。