MySQL在关联复杂情况下所能做出的一些优化

2019-01-05 09:55:32刘景俊

执行时间:

1 row in set (0.74 sec)

在c表上添加索引后,索引还是没有走上,执行计划还是以a表作为驱动表,所以我们这里来分析一下为什么还是以a表作为驱动表?

1):c.yh_id=b.yh_id—>( PRIMARY KEY (`JG_ID`,`YH_ID`) )

a.如果以c表为驱动表,则c表与b表在关联的时候,由于在b表没有yh_id字段的索引,由于b表的数据量很大,所以优化器认为这里如果以c表作为驱动表,则会与b表产生较大的关联(这里可以使用straight_join强制使用c表作为驱动表);
b.如果以a表为驱动表,则a表与b表在关联的时候,由于在b表上有jg_id字段的索引,所以优化器认为以a作为驱动表的代价是小于以c作为驱动板的代价;
所以我们如果要以C表为驱动表,只需要在b上添加yh_id的索引:

alter table b add index ind_yh_id(yh_id);

2):b.jg_id=a.jg_id—>( PRIMARY KEY (`JG_ID`) )

3):c.yh_id=d.yh_id—>( KEY `ind_yh_id` (`YH_ID`) )
执行计划:

+—-+————-+——-+——–+——————-+———–+———+————–+——+————-+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +—-+————-+——-+——–+——————-+———–+———+————–+——+————-+ | 1 | SIMPLE | c | ref | PRIMARY,ind_yh_dm | ind_yh_dm | 57 | const | 2 | Using where | | 1 | SIMPLE | d | ref | ind_yh_id | ind_yh_id | 98 | test.c.YH_ID | 272 | Using index | | 1 | SIMPLE | b | ref | PRIMARY,ind_yh_id | ind_yh_id | 98 | test.c.YH_ID | 531 | Using index | | 1 | SIMPLE | a | eq_ref | PRIMARY,INDEX_JG | PRIMARY | 98 | test.b.JG_ID | 1 | Using where | +—-+————-+——-+——–+——————-+———–+———+————–+——+————-+

执行时间:

1 row in set (0.00 sec)

可以看到执行计划中的rows已经大大降低,执行时间也由原来的750ms降低到0 ms级别;

您可能感兴趣的文章:

Mysql一些复杂的sql语句(查询与删除重复的行)深入mysql "ON DUPLICATE KEY UPDATE" 语法的分析MySQL 最基本的SQL语法/语句MySQL与Oracle的语法区别详细对比浅析Mysql Join语法以及性能优化MySQL ALTER语法的运用方法MySQL prepare语句的SQL语法MySQL进阶SELECT语法篇MySQL SQL 语法参考mysql中的一些稍微复杂用法实例代码