MySQL索引行为异常

Question

我有一个Mysql托管的Rails应用，在 rescheduled_reservation_id 列中有一个设置索引的 reservations 表（可空）。

在我的Rails应用程序中，有两部分通过rescheduled_reservation_id字段来查询预订，如下所示：

Transit::Reservation.find_by(rescheduled_reservation_id: 25805)

并产生以下日志输出：

Transit::Reservation Load (60.3ms)  SELECT  `transit_reservations`.* FROM `transit_reservations` WHERE `transit_reservations`.`deleted_at` IS NULL AND `transit_reservations`.`rescheduled_reservation_id` = 25805 LIMIT 1

但是应用程序的其他部分：

Transit::Reservation.where(rescheduled_reservation_id: 25805).last

，日志输出如下

Transit::Reservation Load (2.3ms)  SELECT  `transit_reservations`.* FROM `transit_reservations` WHERE `transit_reservations`.`deleted_at` IS NULL AND `transit_reservations`.`rescheduled_reservation_id` = 25805  ORDER BY `transit_reservations`.`id` DESC LIMIT 1

清楚地看到第一个查询

Transit::Reservation Load (60.3ms)  SELECT  `transit_reservations`.* FROM `transit_reservations` WHERE `transit_reservations`.`deleted_at` IS NULL AND `transit_reservations`.`rescheduled_reservation_id` = 25805 LIMIT 1

长达60毫秒，相比之下2毫秒可能没​​有正确使用索引

Transit::Reservation Load (2.3ms)  SELECT  `transit_reservations`.* FROM `transit_reservations` WHERE `transit_reservations`.`deleted_at` IS NULL AND `transit_reservations`.`rescheduled_reservation_id` = 25805  ORDER BY `transit_reservations`.`id` DESC LIMIT 1

我还尝试通过对两个查询运行解释来进一步调试，我得到了相同的结果，即正在使用索引rescheduled_reservation_id

有人遇到这个问题吗？我想知道Rails mysql连接（我正在使用mysql2 gem）是否可能导致Mysql服务器无法选择正确的索引

Answer 1

稀有，但正常。

可能的答案是，第一个匹配项没有找到它需要缓存在buffer_pool中的块。因此，它必须从磁盘中获取它们。在普通ole HDD上，经验法则是每个磁盘命中10ms。因此，可能需要提取6个块，导致60.3毫秒。

另一种可能性是其他活动正在干扰，从而减慢了此操作的速度。

2.3ms对于一个简单的查询是合理的，例如可以完全使用RAM中的缓存块执行

。

服务器最近重新启动了吗？重新启动后，缓存中没有任何内容。表格是否大于ContentProviderClient db = clientProvider.get(); ？如果是这样，那将导致60毫秒偶尔发生-区块会被撞掉。 （注意：不应该将buffer_pool设置得太大以至于发生“交换”。）

一个块为16KB；它包含一些数据行或BTree的索引行或节点行。根据表的大小，即使是“点查询”也可能需要查看6个或更多的块。

如果您最多 时间没有达到2.3毫秒，我们应该进行更深入的研究。 （我暗示过要调查的大小。）