【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
有2个sql SELECT xxxx FROM t_batt_summary WHERE (vin = ‘779422133353341’ AND del_flag = 0) ORDER BY create_time DESC LIMIT 50;
和SELECT xxx FROM t_batt_summary WHERE (vin = ‘779422110337173’ AND del_flag = 0) ORDER BY create_time DESC LIMIT 50;
这个表有2个单独索引 vin 和create_time ，这2个sql的执行计划不一样
，这2个查询的区别是数据量不一样，第一个40多万，第二个4000多，请问，这个执行器是怎么判断走什么索引的，多少数据量判断走什么索引？
你explain analyze看下实际返回的数据和执行计划看看
这个表大，explain analyze 不出来，要跑7分多钟
会不会有缓存~
其实主要还是统计信息的事，优化器如果觉得你走vin字段索引，获取的行太多，再去按create_time排序取前50行的效率还不如直接按create_time全索引排序查出来数据再去过滤更快，就会走create_time索引，并不存在固定的多少行，就会走create_time索引，多少行就会走vin索引
我这个表20多亿行记录，走vin是40多万行，走create_time肯定扫描的多的多
我删除了40万行记录 执行计划就对了
1 个赞
tidb优化器这个走排序字段的索引其实我也觉得做的有点问题，如果过滤字段有索引，一般都是走过滤字段索引更好。除非很极端的情况。。。。
1 个赞
之前只有一个过滤字段有索引，最近有需求又加了个时间字段做其他用处的，如果再加个组合索引是不是会好？
如果加了组合索引，像你上面的sql肯定走组合索引了，也可以考虑下绑定执行计划或者hint指定下索引。
1 个赞
vin+create_time建组合索引吧，先根据vin过滤数据后，再根据create time排序limit数据，看看效果
TiDB的优化器会根据数据量、索引的选择性、排序需求等因素动态选择最优的执行计划。对于大数据量场景，它倾向于选择能够避免排序的索引；而对于小数据量场景，它倾向于选择能够快速定位数据的索引。通过合理设计索引和定期维护统计信息，可以有效提升查询性能。
看看索引，或者固定一下执行计划
两个查询的结果相差这么多，基于代价优化器看哪个代价小就选哪个了
这种情况情况可以分别查询下对应结果集数量占比，优化器一般会选择代价更小的索引。