加速大表和小表之间的内部连接

Question

这可能是一个愚蠢的问题，但它可能会揭示连接是如何在内部工作的。

假设我有一个大的表L和一个小的表S (100K行与100行)。

以下两个选项在速度方面是否存在差异？

OPTION 1:                 OPTION 2:
---------                 ---------
SELECT *                  SELECT *
FROM L INNER JOIN S       FROM S INNER JOIN L
ON L.id = S.id;           ON L.id = S.id;

请注意，唯一的区别是表的联接顺序不同。

我意识到不同的SQL语言可能会有不同的性能。如果是这样的话，MySQL和Access相比会怎么样呢？

Answer 1

不，顺序并不重要。

几乎所有的关系型数据库管理系统(如MS Access、MySQL、SQL Server、ORACLE等)都使用基于列统计信息的基于成本的优化器。在大多数情况下，优化器会选择一个正确的计划。在您给出的示例中，顺序并不重要(只要统计数据是最新的)。

为了决定使用哪种查询策略，

引擎优化器使用统计信息。以下是这些统计数据所基于的一些因素：

• 表中的记录数

表中的数据页数

• 表的位置
• 是否存在索引<

>H111索引的唯一性

备注：您不能查看Jet数据库引擎优化方案，也不能指定如何优化查询。但是，您可以使用数据库文档管理器来确定索引是否存在以及索引的唯一性。

然后，优化器根据这些统计信息选择用于处理特定查询的最佳内部查询策略。

每次编译查询时，都会更新统计信息。当您保存对查询(或其基础表)所做的任何更改以及压缩数据库时，查询将被标记为要编译。如果查询被标记为要编译，则统计信息的编译和更新将在下次运行该查询时进行。编译通常需要一秒到四秒。

如果向数据库中添加了大量记录，则必须打开并保存查询才能重新编译查询。例如，如果使用一小部分示例数据设计并测试查询，则必须在将其他记录添加到数据库后重新编译查询。执行此操作时，您希望确保在使用应用程序时实现最佳查询性能。

Ref。

可能会感兴趣：ACC: How to Optimize Queries in Microsoft Access 2.0, Microsoft Access 95, and Microsoft Access 97

Tony Toews的Microsoft Access Performance FAQ值得一读。

有一个警告，“连接顺序无关紧要”。

如果您的RDBMS的基于成本的查询优化器在创建查询计划时超时，那么连接顺序可能会很重要。基于成本的优化器有有限的资源( CPU时间和内存)来构建查询计划。如果它们在编译阶段超时，您将获得到目前为止找到的最佳计划。

如果您有收到计划编译超时(而不是查询执行超时)的复杂查询，那么将限制性最强的连接放在第一位。这样，当查询计划优化器超时时，它将增加找到“更好”计划的机会。

当然，如果遇到查询计划编译超时的情况，您可能应该简化查询。

Answer 2

我知道Oracle不在您的列表中，但我认为大多数现代数据库都会这样做。

您可以在下面的执行计划中看到，这两个语句之间没有区别。

它是对两个表中每个表的完全访问(在我的例子中没有索引)，然后是一个HASH JOIN。由于您想要两个表中的所有内容，因此两个表都需要读取和联接，因此序列不会产生影响。

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |   100 |   700 |    42  (12)| 00:00:01 |
|*  1 |  HASH JOIN         |      |   100 |   700 |    42  (12)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| S    |   100 |   300 |     2   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| L    |   100K|   390K|    38   (8)| 00:00:01 |
---------------------------------------------------------------------------