我正在修改原始查询，只是从预订表中提取预订，以加入单位的表格，该表格会加入建筑物的表格，以便检索每次预订的建筑物名称和单位ID。
我为此创建了一个SQLFiddle，并在查询前面加了解释。根据@Alex，我在bookings.unit_number上添加了一个索引，它在SQLFiddle中是bookings.external_system_id。 （忽略辅助字段）。
当我为所有预订全面导出时，这仍然需要一些时间（分钟）。我只是尽力优化这一点，因为我意识到完全导出仍需要一段时间（总计13019077个结果）。
答案 0 :(得分：4)
您正在处理SQL的复杂方面。您可能需要阅读http://use-the-index-luke.com
尊重你的陈述
除非你向我们展示这些过滤器的样子，否则有日期范围和属性的过滤器，但这些是可选的
可能会让你从我们这里获得的任何建议毫无价值。但是，我仍然会尝试提供帮助。
在units (unit_number, id)和buildings(id,name)上创建复合covering indexes，看看性能是否有所改善。这些复合索引应有助于提高性能如果您在bookings.arrival上进行过滤，那么您也可以在bookings (arrival, unit_number)上为同一目的创建复合索引。
在InnoDB 中，没有必要将主键作为复合索引中的最后一列; MySQL将等价物放在每个索引上。 在MyISAM 中，如果您的查询需要，您应该将PK放在那里。以主键开头或以其他方式包含它的复合索引仍然可能有用。
单列索引的集合无法实现与精心选择的复合索引相同的目的。拥有大量索引会增加查询计划程序为给定查询找到有用索引的机会。但覆盖为您的查询设计的索引可以从根本上加快速度。
索引占用的空间与它们包含的数据量大致成比例。如今，硬盘空间非常便宜。
在您的Sql Fiddle 中，您应该更改units表上的索引。摆脱external_system_id上的单列索引，并将其替换为此复合索引。
INDEX `units_joindex` (`external_system_id`, `building_id`)
像这样：（http://sqlfiddle.com/#!9/e5ffd/2/0）。请注意，EXPLAIN结果和查询计划在很大程度上取决于表中的内容和行数以及索引。像你这样的查询必然会拉一整个表，所以你不会在那里看到很多索引利用。