这可能是一个愚蠢的问题，但它可能会揭示联接的内部工作原理。
假设我有一个大表
LS以下两个选项在速度方面会有什么区别吗？:
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 相比如何？
不，顺序并不重要。
几乎所有 RDBMS（例如 MS Access、MySQL、SQL Server、ORACLE 等）都使用基于列统计信息的基于成本的优化器。在大多数情况下，优化器会选择正确的计划。在您给出的示例中，顺序并不重要（只要统计数据是最新的）。
决定使用什么查询策略， 喷气发动机优化器使用 统计数据。以下因素是 这些因素中的一些 统计数据基于：
- 表中的记录数
- 表中数据页的数量
- 桌子的位置
- 索引是否存在
- 索引有多独特
注意：您无法查看Jet数据库引擎优化方案，并且您 无法指定如何优化 询问。但是，您可以使用 数据库记录器确定 索引是否存在以及如何存在 索引是唯一的。
根据这些统计数据， 然后优化器选择最好的 内部查询处理策略 具有特定的查询。
每当出现以下情况时，统计数据都会更新 查询已编译。查询已标记 当您保存任何内容时进行编译 对查询（或其 基础表）并且当 数据库已压缩。如果一个查询是 标记为编译，编译 并更新统计数据 下次运行查询时。 编译通常需要从一个 第二到四秒。
如果您添加大量 记录到您的数据库，您必须 打开然后将您的查询保存到 重新编译查询。例如，如果 您设计并测试查询 使用一小组样本数据，您 之后必须重新编译查询 附加记录被添加到 数据库。当你这样做时，你想要 以确保最优查询 当您的 应用程序正在使用中。
参考。
可能感兴趣：ACC：如何优化 Microsoft Access 2.0、Microsoft Access 95 和 Microsoft Access 97 中的查询
Tony Toews 的 Microsoft Access 性能常见问题解答 值得一读。
有一个警告“加入顺序并不重要”。
如果您的 RDBMS 基于成本的查询优化器在创建查询计划时超时，那么连接顺序可能很重要。基于成本的优化器具有有限的资源（CPU 时间和内存）来构建查询计划。如果它们在编译阶段超时，您将获得迄今为止找到的最佳计划。
TLDR; 如果您的复杂查询收到计划编译超时（而不是查询执行超时），则首先放置最严格的连接。这样，当查询计划优化器超时时，它将增加找到“更好”计划的机会。
当然，如果您遇到查询计划编译超时，您可能应该简化查询。
我知道 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 |
---------------------------------------------------------------------------