MySQL优化器 limit影响的case

测试的用例中，因为limit的大小不同，而产生了完全不同的执行计划：

1. 测试case：　　

create table t1 (
  f1 int() not null,
  f2 int() not null,
  f3 int() not null,
  f4 tinyint() not null,
  primary key (f1),
  unique key (f2, f3),
  key (f4)
) engine=innodb;

insert into t1 values
(,,,), (,,,), (,,,), (,,,), (,,,),
(,,,), (,,,), (,,,), (,,,), (,,,),
(,,,), (,,,), (,,,), (,,,), (,,,),
(,,,), (,,,), (,,,), (,,,), (,,,),
(,,,), (,,,);

2. 两个不同limit的sql生成的执行计划：

　　

　　

3. 分析过程：

　　

step 1.  获取可用的key，并计算rows

　　　　update_ref_and_keys

　　　　　　get_quick_record_count

　　结果： f2， f4可用， 其分配的quick_rows=[22, 22]

　　

　　从上面的cardinality来看，f2，f4的过滤性都是2， 这样扫描f2，需要11行，然后根据primary回聚簇表扫描，有需要11行，所有，使用f2， f4索引的扫描需要22行。

　　

step2：穷举下执行计划，找到cost最低的

　　　　best_access_path

　　　　　　best_extension_by_limited_search

　　　结果： 全表扫描的代价比较低，records=17， cost=2， 所以最后join->best_position[0]记录的就是全表扫描的执行计划。

　　

step3：limit的影响

　　　　　　在make_join_select的过程，对于limit进行处理，理由是：如果有limit，并且比当前best_position的记录数小，我们尝试是否有可用的index，减少扫描代价

　　　　　　所以，在limit=10的时候，进行test_quick_select查找，并使用f2的索引。而limit=20的查询，不满足条件，所以继续使用全表扫描。

　　　　

相关注释和代码如下：　　　　　　

/*
        We plan to scan all rows.
        Check again if we should use an index.
        We could have used an column from a previous table in
        the index if we are using limit and this is the first table
      */
      if ((cond &&
              !tab->keys.is_subset(tab->const_keys) && i > ) ||
          (!tab->const_keys.is_clear_all() && i == join->const_tables &&
           join->unit->select_limit_cnt <
           join->best_positions[i].records_read &&
           !(join->select_options & OPTION_FOUND_ROWS)))

　　

step4： order by的影响

　　　　　　函数：test_if_skip_sort_order

　　　　　　limit=10：ref_key=f2:   判断有一个primary key的index可以覆盖order by查询， 但走pk的代价高于ref_key=f2。

　　　　　　 limit=20：ref_key=0:     判断有一个primary key的index可以覆盖order by查询，而且当前使用的是全表扫描，代价小于全表，所以选择pk。

所以，两个limit值不同的查询，导致了不同的执行计划。