MySQL添加依赖LEFT JOIN后booking表未自动使用索引的原因咨询

• 查询复杂度升高，优化器成本估算转向
  只关联user和booking时，逻辑简单，优化器能明确user_id_status_end_timestamp索引可以高效完成关联或过滤。但加入address表后，多表关联+跨表OR条件让查询逻辑变复杂，优化器需要计算更多执行路径的成本。如果它预估使用索引后，关联address表的开销加上索引查找的总成本，比全表扫描更高，就会放弃索引选择全表扫。

• 跨表OR条件打乱索引适配逻辑
  你的查询里的(booking.id IS NULL OR address.country_id = :countryId)是跨两个表的OR条件。user_id_status_end_timestamp索引是针对booking表的，优化器没法用这个索引同时处理“booking无匹配”和“address匹配指定国家”这两种分支场景。这种情况下，它会觉得索引无法覆盖所有需要的逻辑，不如全表扫描来得直接。

• MySQL 5.7优化器的固有局限
  5.7版本的优化器在处理多表LEFT JOIN+复杂条件的场景时，成本估算模型不够精准。它没法准确计算用user_id_status_end_timestamp索引后，后续关联address表的实际开销，误判全表扫描的成本更低。而手动指定索引能强制走索引路径，实际执行效率也验证了索引的有效性，这说明优化器的成本估算出现了偏差。

内容的提问来源于stack exchange，提问作者littleibex