提示：公众号展示代码会自动折行，建议横屏阅读

背景

客户发现一个非预期内的锁等待现象，线上频繁出现锁告警，出现问题的case可以简化成以下SQL：

# 表结构和表数据CREATE TABLE `tab1` (  `id` bigint unsigned NOT NULL AUTO_INCREMENT,  `value` int NOT NULL,  `status` tinyint unsigned NOT NULL DEFAULT '1',  PRIMARY KEY (`id`),  KEY `idx_value` (`value`));insert into tab1 (value) values (5);insert into tab1 (value) values (10);

#seesion 1:begin;update `tab1` set `status` = 3 where (`value` = 10);

#session 2:update `tab1` set `status` = 3 where (`value` >= 4) and (`value` < 6); #阻塞

用户贼郁闷，隔离级别用的是 RC，两个session又都只更新一条数据，并且更新的还是两条不一样的数据，按理来说没有冲突，不应该造成阻塞。

原因分析

原始的场景中，用户的二级索引是建立在datetime类型上的，一开始怀疑是datetime类型在InnoDB层的比较出现了问题。

但是后面在int类型的二级索引上复现了该问题，因此可以排除是datetime类型导致的。

使用select * from performance_schema.data_lock_waits; 查看session 2等待的锁信息：

可以看到，session 2等待的锁是在idx_value这个索引的<10, 2>这条记录上，而这条记录正是被session 1持有的。

根据以上线索，透露出来的信息是，session 2尝试去加了session 1锁住的记录<10, 2>的锁，也就是说(value < 6)这个条件并没有在innodb层过滤掉<10, 2>这条记录。

通过分析源码，这个流程可以简化成：

Server层调用read_range_next()会循环调用innodb层的row_search_mvcc函数，在row_search_mvcc函数中执行以下步骤：

btr_pcur_open_with_no_init // mode = page_cur_ge，如果是第一次调用，找到第一条>= start_range的记录，如果不是第一次调用，找到pcur->next_rec
sel_set_rec_lock // 对pcur指向的rec记录加锁，如果加锁失败，返回等待。
row_search_idx_cond_check // 检查rec记录是否满足index condition。

ICP_RESULT row_search_idx_cond_check(    byte *mysql_rec,          /*!< out: record                              in MySQL format (invalid unless                              prebuilt->idx_cond == true and                              we return ICP_MATCH) */    row_prebuilt_t *prebuilt, /*!< in/out: prebuilt struct                              for the table handle */    const rec_t *rec,         /*!< in: InnoDB record */    const ulint *offsets)     /*!< in: rec_get_offsets() */{  ICP_RESULT result;  ulint i;
  ut_ad(rec_offs_validate(rec, prebuilt->index, offsets));
  if (!prebuilt->idx_cond) { // 如果index condition pushdown了，prebuilt->idx_cond为true，这里end_range并没有下推，所以这里直接返回了    return (ICP_MATCH);  }
  MONITOR_INC(MONITOR_ICP_ATTEMPTS);
  /* Convert to MySQL format those fields that are needed for  evaluating the index condition. */
  if (prebuilt->blob_heap != nullptr) {    mem_heap_empty(prebuilt->blob_heap);  }
  for (i = 0; i < prebuilt->idx_cond_n_cols; i++) {    const mysql_row_templ_t *templ = &prebuilt->mysql_template[i];
    /* Skip virtual columns */    if (templ->is_virtual) {      continue;    }
    if (!row_sel_store_mysql_field(            mysql_rec, prebuilt, rec, prebuilt->index, prebuilt->index, offsets,            templ->icp_rec_field_no, templ, ULINT_UNDEFINED, nullptr,            prebuilt->blob_heap)) {      return (ICP_NO_MATCH);    }  }
  /* We assume that the index conditions on  case-insensitive columns are case-insensitive. The  case of such columns may be wrong in a secondary  index, if the case of the column has been updated in  the past, or a record has been deleted and a record  inserted in a different case. */  result = innobase_index_cond(prebuilt->m_mysql_handler); // 通过该函数去判断记录是否满足下推条件  switch (result) {    case ICP_MATCH:      /* Convert the remaining fields to MySQL format.      If this is a secondary index record, we must defer      this until we have fetched the clustered index record. */      if (!prebuilt->need_to_access_clustered ||          prebuilt->index->is_clustered()) {        if (!row_sel_store_mysql_rec(mysql_rec, prebuilt, rec, nullptr, FALSE,                                     prebuilt->index, prebuilt->index, offsets,                                     false, nullptr, prebuilt->blob_heap)) {          ut_ad(prebuilt->index->is_clustered());          return (ICP_NO_MATCH);        }      }      MONITOR_INC(MONITOR_ICP_MATCH);      return (result);    case ICP_NO_MATCH:      MONITOR_INC(MONITOR_ICP_NO_MATCH);      return (result);    case ICP_OUT_OF_RANGE:      MONITOR_INC(MONITOR_ICP_OUT_OF_RANGE);      const auto record_buffer = row_sel_get_record_buffer(prebuilt);      if (record_buffer) {        record_buffer->set_out_of_range(true);      }      return (result);  }
  ut_error;  return (result);}

返回server层该条记录

在server层read_range_next函数中，如果判断刚刚从innodb读上来的记录不在end_range之内，会调用unlock_row()接口放掉刚刚在innodb层加上的锁。

if (compare_key(end_range) > 0) {
      /*
        The last read row does not fall in the range. So request
        storage engine to release row lock if possible.
      */
      unlock_row(); // 这里最终会调用row_unlock_for_mysql函数放掉刚刚在 sel_set_rec_lock 加上的锁。
      result = HA_ERR_END_OF_FILE;
}

因此，session 2需要从innodb层读取两条记录去server层做判断--5和10。10恰巧又被session 1锁住，因此在innodb层读取记录的时候就判断需要锁等待，此时还没有返回到server层做end_range的范围过滤。

如果5和10之间有一条其他的记录，session 2不会被session 1持有的10上面的锁阻塞住。

总结

这个问题的本质原因，是end_range条件没有push down，如果end_range 下推到innodb层，会在row_search_mvcc函数中sel_set_rec_lock之后通过row_search_idx_cond_check函数检查是否满足end_range，这样就不会多加锁了。

追问：如果是主键索引，会是同样的表现吗？

先说结论，这里分两种情况：

如果是select for update主键索引，表现与二级索引一致，session 2是会发生阻塞的。
如果是update主键索引，session2 不会发生阻塞。

以下是对应的case：

select for update

# 表结构和表数据CREATE TABLE `tab1` (`id` bigint unsigned NOT NULL,`value` int NOT NULL DEFAULT 0,`status` tinyint unsigned NOT NULL DEFAULT '1',PRIMARY KEY (`id`));insert into tab1 (id) values (5);insert into tab1 (id) values (10);

#seesion 1:begin;select * from `tab1` where (`id` = 10) for update;

#session 2:select * from `tab1` where (`id` >= 4) and (`id` < 6) for update; #阻塞

update

# 表结构和表数据CREATE TABLE `tab1` (`id` bigint unsigned NOT NULL,`value` int NOT NULL DEFAULT 0,`status` tinyint unsigned NOT NULL DEFAULT '1',PRIMARY KEY (`id`));insert into tab1 (id) values (5);insert into tab1 (id) values (10);

#seesion 1:begin;update `tab1` set `status` = 3 where (`id` = 10);

#session 2:update `tab1` set `status` = 3 where (`id` >= 4) and (`id` < 6); #不会阻塞

代码分析

如果是select for update主键索引， prebuilt->row_read_type=ROW_READ_WITH_LOCKS，在innodb层的row_search_mvcc函数中，发生锁等待的时候，由于prebuilt→row_read_type != ROW_READ_TRY_SEMI_CONSISTENT，会和secondary index一样走lock_wait_or_error进行等待（下图第一个红框内的代码）。
如果是update主键索引，prebuilt→row_read_type=ROW_READ_TRY_SEMI_CONSISTENT，如果在innodb层发生锁等待，会先放掉锁（下图第二个红框），并将prebuilt->row_read_type设置为ROW_READ_DID_SEMI_CONSISTENT。后续在server层判断不满足end_range直接结束，但是如果后续在server层判断满足end_range，则会重新发起一次读操作，此时会读取行的最新版本，再次走到下图的代码时会走lock_wait_or_error进行锁等待（下图第一个红框）。