首页 > 代码库 > MySQL优化器join顺序

MySQL优化器join顺序

前一篇介绍了cost的计算方法,下面测试一下两表关联的查询:

测试用例

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CREATE TABLE `xpchild` (
  `id` int(11) NOT NULL,
  `name` varchar(100) DEFAULT NULL,
  `c1` int(11) DEFAULT NULL,
  `c2` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `xpchild_name` (`name`),
  KEY `xpchild_id_c1` (`id`,`c1`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
 
 CREATE TABLE `xpchild_1` (
  `xxid` bigint(20) DEFAULT NULL,
  `name` varchar(100) DEFAULT NULL,
  KEY `xpchild_1_id` (`xxid`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

测试sql

select * from xpchild, xpchild_1 where xpchild.id=100 and xpchild.id=xpchild_1.xxid;

函数调用栈:
JOIN::optimize
   make_join_statistics
       update_ref_and_keys
       get_quick_record_count
       choose_plan

以上省略了JOIN::prepare的过程,prepare主要进行一些等级变化,上面的sql是一个比较简单的两表关联,并不会进行过多的变换。

step1: 初始化

make_join_statistics:
    根据select_lex->leaf_tables初始化每个JOIN_TAB对象,至此,一个sql对于一个join,对应两个join_tab.
    初始化quick_condition_rows为innodb中的stat统计信息中的record记录数。

step 2: 查询可用索引

update_ref_and_keys:根据where条件,选择可以使用的索引,加入到possible keys中,本例子加入的keys包括:
    xpchild: primary,xpchild_id_c1
    xpchild_1: xxid

?
1
2
3
4
5
6
7
(gdb) p *keyuse_array
$67 = {
  buffer = 0x8ca1fb58 "@24214",
  elements = 3,
  max_element = 20,
  alloc_increment = 64,
  size_of_element = 48

step 3: 计算cost

   get_quick_record_count:根据可选择的possible_keys计算cost。

   1. xpchild表

      因为有可以使用的primary,xpchild表s->type == JT_CONST,所以cost的计算为:

    s->found_records=s->records=s->read_time=1。
所以,mysql对于使用primary,unique key的使用上比较有倾向性,而且可以节省大量的计算cost的时间。

 

2. xpchild_1表:

全表扫描的records && read_time是:
  s->found_records= 1215
  s->read_time= 5

计算xxid索引的cost:
  get_quick_record_count
    test_quick_select:
      最终计算的cost:
        estimated_records=1
        best_read_time=2.21
  具体的计算方式,可以参考前面一篇博客

 

到此:xpchild的JOIN_TAB结构中,比较简单,const table类型,cost=1;
xpchild_1的JOIN_TAB结构中,found_records=1, read_time=2.21;
对于单表的的查询access path已经是最优的。

 

step 4:join的顺序: 

 choose_join:

    

1. 如果是const table;不再进行join顺序的计算,直接选择使用当前positions。
   memcpy((uchar*) join->best_positions,(uchar*) join->positions,sizeof(POSITION)*join->const_tables);
   join->best_read=1.0;

2. 为非const table,选择最优的访问顺序
    optimizer_search_depth:优化访问表join顺序的递归计算深度。
        straight_join:按照sql的顺序,或者添加sql hint确定的顺序,默认不使用
        greedy_search:贪婪算法,对于当前的查询,在候选的表中,选择一个最小cost添加到当前的plan中,递归完成。
            best_extension_by_limited_search:根据current_record_count,与调用best_access_path得到的best_record_count进行比较,选择最优的路径。
                best_access_path:table->quick_rows根据前面计算的records,得出cost,得到join->positions[idx]的最优路径。

   join顺序选择的步骤:

     1. 根据best_extension_by_limited_search在remaining table中选择cost最小的那个,本例中,xpchild的cost为:records=1 , read_time=0。所以选择为第一张表。

     2. 然后从候选表中选择一个(只剩下xpchild_1表)加入到join的顺序中,并根据best_access_path选择一个cost最低的执行计划加入到plan中,这里选择xpchild_1_id的索引。

 


      最后得到best plan,并赋值给last_query_cost;
    join->thd->status_var.last_query_cost= join->best_read;

最后得到的best plan:
(gdb) p tab->join->best_read
$73 = 1.1990000000000001

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
(gdb) p tab->join->best_positions
$72 = {{
    records_read = 1,
    read_time = 0,
    table = 0x8ca06078, ‘xpchild‘
    key = 0x8ca1fb58,   ‘primary‘
    ref_depend_map = 0
  }, {
    records_read = 1,
    read_time = 1,
    table = 0x8ca0620c, ‘xpchild_1‘
    key = 0x8ca1fbb8,    ‘xpchild_1_id‘
    ref_depend_map = 0
  }

 

未完待续: