同一个查询，条件不一样执行计划有差异
res表数据量40W，p表数据量17W，
res表表结构：
PRIMARY KEY (`id`),
UNIQUE KEY `idx_telnum` (`telNum`) USING BTREE,
KEY `idx_updatetime` (`updateTime`) USING BTREE,
KEY `idx_appid` (`appId`) USING BTREE,
KEY `idx_cm_group_id` (`cm_group_id`) USING BTREE,
KEY `channel_accid` (`channel_accid`),
KEY `idx_area_code` (`area_code`) USING BTREE
p表表结构
PRIMARY KEY (`id`),
UNIQUE KEY `idx_number` (`number`) USING BTREE,
KEY `idx_create_time` (`create_time`),
KEY `idx_area_code` (`area_code`) USING BTREE,
KEY `idx_status` (`status`) USING BTREE
添加isVideo=0之后执行很慢，几乎查不出来，执行计划如图：
不添加isVideo这个条件执行很快几秒左右，执行计划如图
原因： 因为你添加isVideo=0之后，走的执行计划都变了。 两张表的关联顺序变了，走的索引也变了。
分析：
两张表的关联方法是嵌套循环链接。嵌套循环链接的原理：驱动表返回多少行，被驱动表就需要被扫描多少次。
不加isVideo=0，p表是驱动表，走的idx_status索引，虽然该索引选择性差，但是就扫描一次。res是被驱动表，走了唯一性较好的telNum字段的索引。
加isVideo=0之后，res表扫描一次，返回8930行，p表此时作为被驱动表，就要被扫描8930次，因为走的还是idx_status索引，这个唯一性不好的索引造成的性能瓶颈就被放大了。
优化建议：
1. 添加hint force index (idx_number) 强制p表走idx_number字段的索引。 --如果还走不上，我怀疑你两张表的数据类型不一致，建议修改下数据类型，或者通过函数转一下。
2. 使用straight_join强制让p表先走，res表做被驱动表。
--不知道有没有说清楚，有任何问题可以再提问我。。
评论
有用 1
MySQL总是会选小表当驱动表 不加isVideo 条件 p表当然是小表。加了isVideo条件，MySQL认为过滤性很好，从执行计划的filtered = 0.05 可以推算出 MySQL评估认为 最终只有 8930 *0.05 = 446.50行参与最终的JOin 题主可以用condition_fanout_filter参数验证，这里贴了我的一篇文章 可以看看https://www.modb.pro/db/1752165858076086272
评论 有用 2
