Rails中MySQL索引异常求助：同条件查询性能差异显著

我之前碰到过类似的查询耗时差异情况，结合你的描述，给你几个排查方向和可能的原因：

1. 缓存与数据冷热的影响 #

这是最常见的诱因：

• 第二个where(...).last查询可能刚好命中了MySQL的查询缓存（若你的MySQL版本开启了该功能），或是InnoDB缓冲池已经加载了对应的数据页；而第一个find_by是首次执行，需要从磁盘读取数据，自然耗时更长。
• 你可以重复执行几次find_by查询，看后续耗时是否会降到和where(...).last接近，以此验证是不是缓存的问题。

2. 查询逻辑的隐性差异 #

虽然两个查询都是过滤rescheduled_reservation_id，但SQL的执行逻辑有本质区别：

• find_by生成的SQL没有排序，MySQL会按照rescheduled_reservation_id索引的顺序返回第一条匹配记录。如果这个索引的顺序和数据存储差异大，或是匹配的记录较多，遍历到第一条符合条件的记录可能需要扫描更多索引节点。
• where(...).last默认按id DESC排序，生成的SQL带ORDER BY transit_reservations.id DESC LIMIT 1。由于id是主键，主键索引天然有序，MySQL可能会优化执行路径：要么通过rescheduled_reservation_id索引找到所有匹配记录后，按主键排序取最后一条；甚至可能切换到主键索引反向扫描，直接找到第一个匹配rescheduled_reservation_id=25805的记录（这种情况EXPLAIN可能还是显示用了rescheduled_reservation_id索引，但实际执行效率更高）。

你可以对比两个查询EXPLAIN结果里的rows字段，看看预估扫描的记录数是否有差异，这能直接反映MySQL执行时的工作量不同。

3. 数据库连接的会话参数差异 #

虽然都用mysql2 gem，但不同的数据库连接可能带有不同的会话参数（比如optimizer_switch的设置），这会影响MySQL优化器的选择：

• 你可以在两段代码前后分别执行ActiveRecord::Base.connection.execute("SHOW SESSION VARIABLES LIKE 'optimizer_switch'")，对比两个连接的参数是否一致。
• 另外，建议尝试升级mysql2 gem到最新稳定版，旧版本的gem可能存在会话参数传递的小bug。

4. 表碎片与索引状态 #

如果transit_reservations表有大量删除、更新操作，可能产生表碎片，导致索引扫描变慢：

• 可以在低峰期尝试执行OPTIMIZE TABLE transit_reservations（注意该操作会锁表），整理表和索引的碎片后再测试查询耗时。

验证步骤建议 #

1. 直接在MySQL客户端手动执行两段SQL，排除Rails框架或mysql2 gem的影响，看耗时是否依然有差异。
2. 查看两个查询EXPLAIN结果的Extra字段，第一个查询是否有Using index condition，第二个是否有Using filesort或Using index（覆盖索引场景）。
3. 统计rescheduled_reservation_id=25805的记录数量，如果数量较多，两种查询的执行效率差异会更明显。

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