这个问题出自一位朋友的评论。他说，当一个查询有很多子查询时，这是一个信号，表明数据库有设计缺陷，必须避免。他还表示，许多书籍都表明了这一点。子查询是否是邪恶的？
我同意部分内容，但我认为这些查询具有复杂的逻辑，需要大量的子查询，或者为了避免子查询，查询的物化视图或大量数据冗余。
那么，子查询的真相是什么？他们必须总是避免吗？他们没有问题？他们是否指出数据库设计缺陷？有没有可能有一个数据库设计，允许复杂的查询没有数据冗余？
不，子查询的存在并不一定意味着数据库架构设计不佳。
Correlated subqueries应该谨慎使用（即当内部条件引用外部条款时）。
除此之外，子查询通常是解决问题的有用和自然的方法。我倾向于在可能的情况下使用连接而不是子查询。
许多查询优化器会将某些类型的子查询转换为连接。
我倾向于同意你的朋友，如果你经常需要子查询，这是一个迹象表明数据库没有以易于查询的方式组织。对于规范化规则而言，这可能是完美的，但对于关于数据的常见问题却不方便。如果是这样，解决方案通常会创建一个视图或中间表，以更可搜索的方式将数据集中到一起。
我也同意米奇小麦说，子查询通常是有用的。这个问题的有用性与如何最好地组织数据以使其易于查询的问题是正交的。
“相关子查询”（即其中where条件取决于从包含查询的行获得的值的那个）将针对每行执行一次。一个不相关的子查询（其中where条件独立于包含的查询）将在开始时执行一次。 SQL引擎自动进行这种区分。
子查询可能正在执行“全表扫描”。换句话说，不使用索引并返回太多的行，以至于主查询中的Where需要过滤掉。
通常它的优化器无法确定子查询可以作为连接执行，在这种情况下，它会为表中的每条记录执行子查询，而不是在子查询中将表连接到表中你在查询。一些更“企业”的数据库在这方面更好，但他们有时仍然会错过它。
所以更喜欢加入子查询来获得更快和更精确的结果。
你的朋友的逻辑是有缺陷的。尽管SQL及其各种实现在关系模型上有点松散，但它缺少许多基本的关键字或简写，特别是半连接，半差异（又称反连接）和分裂。我经常使用子查询在SQL代码中编写半连接和半差异;至于除法，我不确定是否可以在不使用子查询的情况下在单个查询中执行！
所以我使用的子查询是由SQL语言的可疑设计，而不是我使用的数据库的设计。
p.s.我想知道你和/或你的朋友是否使用术语“数据库”来表示数据库（数据集合）和DBMS（管理数据的软件系统）是可交换的。如果是这样，在上下文中，你的意思是DBMS，那么声明“当查询有很多子查询时，这是DBMS有设计缺陷的'味道'”可能确实如此。
你指的是任何特定的数据库？ – ajreal
@ajreal我使用PostgreSQL，但我认为这适用于任何RMDBS。 –