我们知道，MySQL有一个老问题，当表上无主键时，那么对于在该表上做的DML，如果是以ROW模式复制，则每一个行记录前镜像在备库都可能产生一次全表扫描（或者二级索引扫描），大多数情况下，这种开销都是非常不可接受的，并且产生大量的延迟。

在MySQL5.6中提供了一个新的参数：slave_rows_search_algorithms, 可以部分解决无主键表导致的复制延迟问题，其基本思路是对于在一个ROWS EVENT中的所有前镜像收集起来，然后在一次扫描全表时，判断HASH中的每一条记录进行更新。

测试：

首先来看看性能怎么样，我们使用sbtest表，并将其上面的主键及二级索引全部删除，表中有200万行数据

主库执行随机更新操作：

     update table sbtest2 set k = k +15 order by rand() limit  [$RECOR_NUM]; 

备库的最大延迟时间（基本等同执行时间）如下：

可以看出来，该特性对于无主键表的复制延迟问题，还是有很大的帮助的。

如何使用：

slave_rows_search_algorithms的文档描述的非常清晰，该变量由三个值的组合组成：TABLE_SCAN，INDEX_SCAN， HASH_SCAN，使用组合包括：

TABLE_SCAN,INDEX_SCAN  (默认配置，表示如果有索引就用索引，否则使用全表扫描)

INDEX_SCAN,HASH_SCAN

TABLE_SCAN,HASH_SCAN

TABLE_SCAN,INDEX_SCAN,HASH_SCAN(等价于INDEX_SCAN, HASH_SCAN)

参数组合（摘自log_event.cc: 9633~9648)

  /*
    Decision table:
    - I  --> Index scan / search
    - T  --> Table scan
    - Hi --> Hash over index
    - Ht --> Hash over the entire table

    |--------------+-----------+------+------+------|
    | Index\Option | I , T , H | I, T | I, H | T, H |
    |--------------+-----------+------+------+------|
    | PK / UK      | I         | I    | I    | Hi   |
    | K            | Hi        | I    | Hi   | Hi   |
    | No Index     | Ht        | T    | Ht   | Ht   |
    |--------------+-----------+------+------+------|

  */

实现：

a.决定使用哪种scan方式：

函数：Rows_log_event::decide_row_lookup_algorithm_and_key

调用backtrace：

Rows_log_event::do_apply_event

     ->do_before_row_operations

          ->Rows_log_event::row_operations_scan_and_key_setup

                    ->Rows_log_event::decide_row_lookup_algorithm_and_key 

没啥好说的，根据上述的参数组合矩阵，来确定使用哪种scan策略，存储在rows log event对象的m_rows_lookup_algorithm中

另外这里也会去看看是否能够使用索引，以及使用哪个索引(this->m_key_index= search_key_in_table)，

b.执行过程

在函数Rows_log_event::do_apply_event中，当确定了使用哪种scan策略后，就可以选择对应的接口函数：

11084     switch (m_rows_lookup_algorithm)
11085     {
11086       case ROW_LOOKUP_HASH_SCAN:
11087         do_apply_row_ptr= &Rows_log_event::do_hash_scan_and_update;
11088         break;
11089
11090       case ROW_LOOKUP_INDEX_SCAN:
11091         do_apply_row_ptr= &Rows_log_event::do_index_scan_and_update;
11092         break;
11093
11094       case ROW_LOOKUP_TABLE_SCAN:
11095         do_apply_row_ptr= &Rows_log_event::do_table_scan_and_update;
11096         break;
11097
11098       case ROW_LOOKUP_NOT_NEEDED:
11099         DBUG_ASSERT(get_general_type_code() == WRITE_ROWS_EVENT);
11100
11101         /* No need to scan for rows, just apply it */
11102         do_apply_row_ptr= &Rows_log_event::do_apply_row;
11103         break;
11104
11105       default:
11106         DBUG_ASSERT(0);
11107         error= 1;
11108         goto AFTER_MAIN_EXEC_ROW_LOOP;
11109         break;
11110     }

这里我们只关心Rows_log_event::do_hash_scan_and_update，主要做几件事

1.将当前行事件的记录前镜像和后镜像存储到一个hash中（Rows_log_event::do_hash_row）；

hash表的结构定义在Hash_slave_rows类中

>>hash key的生成基于record[0]，也就是前镜像；

>>前镜像记录的起始位置

>>前镜像记录的结束位置

对于hash scan，当有索引时(m_key_index<MAX_KEY)，处理方式略微有些不一样：

在将记录加入到hash时，键值列被单独存储下来，存储在m_distinct_key_list中(Rows_log_event::add_key_to_distinct_keyset)

2.如果该EVENT中所有的行记录都解析完毕，开始执行SCAN && UPDATE （Rows_log_event::do_scan_and_update）

>>初始化表或者索引扫描(open_record_scan())

     对于索引，需要根据m_distinct_key_list初始化需要查询的键值iterator（m_itr）

>>在一个while循环中：

     |–>error= next_record_scan(i == 0);  //读取表或索引上的下一条记录

          |–>对于全表扫描，直接调用table->file->ha_rnd_next(table->record[0])扫描表记录

          |–>对于索引，第一次读是根据key搜索记录，下一次再调用next_record_scan时，先看下一条记录是否和当前m_key是否匹配，如果不匹配，将 m_key指向下一个m_itr，并根据m_key重读index，否则使用这个记录；

          这里看起来似乎有优化的余地，因为m_itr并不是有序的，它的成员取自m_distinct_key_list，并且也不会保证存储的Key完全不重复，从函数 add_key_to_distinct_keyset的逻辑可以看出来，每次加入一个新的key，仅仅和上一次的key做对比来判断是否重复，但实际上二级索引key在一个rows log event中可能是无序的，做一次排序 会不会有利于性能呢？（TODO）

     |–>根据读取到的记录构建key，查找hash，查看是否存在对应的entry（entry= m_hash.get(table, &m_cols)）

     |–>如果存在entry，还需要把读取到的记录跟该entry对应的binlog中的行记录进行比较（防止hash collision），符合的话，则从hash中将其删除，并应用该更新（Rows_log_event::do_apply_row）

当发生错误，或者hash中记录删光后，结束扫描，从while退出

可见，对于没有索引的表而言，最多需要一次表扫描。