加快大表和小表之间的内部联接

翰墨之林

这可能是一个愚蠢的问题，但可能会为联接在内部的工作方式提供一些启示。
假设我有一个大表L和一个小表S（100K行vs. 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相比如何？

解决方案:


            不，顺序无关紧要。
几乎所有的RDBMS（例如MS Access，MySQL，SQL
Server，ORACLE等）都基于列统计信息使用基于成本的优化器。在大多数情况下，优化师将选择正确的计划。在您提供的示例中，顺序无关紧要（提供的统计信息是最新的）。

为了决定使用哪种查询策略，Jet Engine优化器使用统计信息。以下因素是这些统计数据所基于的一些因素：
表中的记录数
表中的数据页数
桌子的位置
是否存在索引
索引的独特性

注意：您不能查看Jet数据库引擎优化方案，也不能指定如何优化查询。但是，您可以使用数据库文档管理器来确定是否存在索引以及索引的唯一性。
然后，基于这些统计信息，优化器将选择最佳内部查询策略来处理特定查询。
每当编译查询时，统计信息就会更新。当您保存对查询（或其基础表）的任何更改以及压缩数据库时，该查询都会标记为编译。如果查询被标记为要编译，则下次运行查询时将进行统计信息的编译和更新。编译通常需要一秒钟到四秒钟。
如果您在数据库中添加了大量记录，则必须打开然后保存查询以重新编译查询。例如，如果您使用一小组样本数据设计然后测试查询，则必须在将其他记录添加到数据库之后重新编译查询。执行此操作时，您要确保在使用应用程序时实现最佳查询性能。

参考。
可能感兴趣：ACC：如何在Microsoft Access 2.0，Microsoft Access 95和Microsoft Access
97中优化查询
Tony Toews的Microsoft Access Performance
FAQ值得一读。
需要注意的是“加入顺序无关紧要”。
如果您的RDBMS基于成本的查询优化器在创建查询计划时超时，则连接顺序可能很重要。基于成本的优化器在构造查询计划时具有有限的资源（CPU时间和内存）。如果他们在编译阶段超时，那么您将获得迄今为止找到的最佳计划。
TLDR；如果您的复杂查询收到计划编译超时（而不是查询执行超时），则应将限制性最强的联接放在首位。这样，在查询计划优化器超时的那一点上，它将增加找到“更好”计划的机会。
当然，如果遇到查询计划编译超时，则可能应该简化查询。

加快大表和小表之间的内部联接

翰墨之林 LV1