这取决于几个因素，包括正在运行的特定查询、数据库中的数据量。子查询首先运行内部查询，然后从结果集中再次过滤出实际结果。而在join中运行并产生结果。

最好的策略是同时测试连接解决方案和子查询解决方案，以获得优化的解决方案。

使用EXPLAIN查看数据库如何对数据执行查询。这个答案中有一个很大的“视情况而定”……

PostgreSQL可以将子查询重写为连接，或将连接重写为子查询，如果它认为其中一个比另一个快。这完全取决于数据、索引、相关性、数据量、查询等。

我不是关系数据库专家，所以对此持保留态度。

子查询与连接的一般思想是较大查询的求值路径。

为了执行较大的查询，必须首先执行每个子查询，然后将结果集存储为与较大查询交互的临时表。

这个临时表没有索引，因此，任何比较都需要扫描整个结果集。

相反，当您使用连接时，所有索引都在使用中，因此，比较需要遍历索引树(或哈希表)，这在速度方面成本要低得多。

现在，我不知道最流行的关系引擎的新版本是否在反向执行求值，只是将必要的元素加载到临时表中，作为优化方法。

在大多数情况下，join比子查询快，子查询比子查询快的情况非常罕见。

在join中，RDBMS可以为您的查询创建一个更好的执行计划，并可以预测应该加载哪些数据来处理并节省时间，不像子查询，它将运行所有的查询并加载所有的数据来进行处理。

子查询的好处是它们比join更可读:这就是为什么大多数新学习SQL的人更喜欢它们;这是简单的方法;但是当涉及到性能时，join在大多数情况下更好，尽管它们也不难读。

摘自MySQL手册(13.2.10.11将子查询重写为连接):

LEFT [OUTER] JOIN可以比等效的子查询更快，因为服务器可以更好地优化它——这不是MySQL服务器独有的事实。

所以子查询可能比LEFT [OUTER] JOIN慢，但在我看来，它们的优势是可读性略高。

MSDN文档SQL Server说

Many Transact-SQL statements that include subqueries can be alternatively formulated as joins. Other questions can be posed only with subqueries. In Transact-SQL, there is usually no performance difference between a statement that includes a subquery and a semantically equivalent version that does not. However, in some cases where existence must be checked, a join yields better performance. Otherwise, the nested query must be processed for each result of the outer query to ensure elimination of duplicates. In such cases, a join approach would yield better results.

所以如果你需要

select * from t1 where exists select * from t2 where t2.parent=t1.id

尝试使用join代替。在其他情况下，这没有什么区别。

我说:为子查询创建函数可以消除混乱的问题，并允许您为子查询实现额外的逻辑。因此，我建议尽可能为子查询创建函数。

代码中的混乱是一个大问题，几十年来业界一直在努力避免它。