由于b表的数据量大于其他的两表，同时b表上基本没有查询过滤条件，所以驱动表选择B的可能排除；
优化器实际选择了a表作为驱动表，而为什么不是c表作为驱动表？我们来分析一下：
第一阶段：a表作为驱动表
a–>b–>c–>d:
(1):a.jg_id=b.jg_id—>(b索引:PRIMARY KEY (`JG_ID`,`YH_ID`) )
(2):b.yh_id=c.yh_id—>(c索引:PRIMARY KEY (`YH_ID`))
(3):c.yh_id=d.yh_id—>(d索引:PRIMARY KEY (`JS_DM`,`YH_ID`))
由于d表上没有yh_id的索引，索引在d表上添加索引：
| alter table d add index ind_yh_id(yh_id); |
执行计划：
| +—-+————-+——-+——–+——————+———–+———+————–+——-+————-+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +—-+————-+——-+——–+——————+———–+———+————–+——-+————-+ | 1 | SIMPLE | a | ALL | PRIMARY,INDEX_JG | NULL | NULL | NULL | 52616 | Using where | | 1 | SIMPLE | b | ref | PRIMARY | PRIMARY | 98 | test.a.JG_ID | 1 | Using index | | 1 | SIMPLE | c | eq_ref | PRIMARY | PRIMARY | 98 | test.b.YH_ID | 1 | Using where | | 1 | SIMPLE | d | ref | ind_yh_id | ind_yh_id | 98 | test.b.YH_ID | 272 | Using index | +—-+————-+——-+——–+——————+———–+———+————–+——-+————-+ |
执行时间：
| 1 row in set (0.77 sec) |
在d表上添加索引后，d表的扫描行数下降到272行（最开始为：54584 ）
| | 1 | SIMPLE | d | ref | ind_yh_id | ind_yh_id | 98 | test.b.YH_ID | 272 | Using index | |
第二阶段：c表作为驱动表
d
^
|
c–>b–>a
由于在c表上有yh_dm过滤性很高的筛选条件，所以我们在yh_dm上创建一个索引：
| mysql> select count(*) from c where yh_dm = '006939748XX'; +———-+ | count(*) | +———-+ | 2 | +———-+ |
添加索引：
| alter table c add index ind_yh_dm(yh_dm) |
查看执行计划：
