查询sql带有like和orderby不走索引

[像风一样的男子]

我这有个sql
SELECT * FROM a WHERE ( 字段1 LIKE ‘abc%’ ) ORDER BY 字段2 DESC
其中字段1和字段2都是有索引的
但是查询的时候只走了字段2的索引，没走字段1的索引，走了全表扫描
不加order by查询SELECT * FROM a WHERE ( 字段1 LIKE ‘abc%’ )
就会走字段1的索引
这个有什么办法优化吗？

[Miracle]

试试hint或者复合索引

[像风一样的男子]

联合索引也加了，不走

[乡在人间 (Ti D Ber Ki Nyc B Fs)]

联合索引是字段1、字段2这样的顺序吧？

[像风一样的男子]

索引顺序对的
把like改成等号就走了

[db_user]

联合索引的话前面也要是等值，试下强制hint字段1的索引，能正常走么

[tidb菜鸟一只 (小菜一颗)]

强制走联合索引，效率高吗？

[像风一样的男子]

强制走联合索引肯定是可以的，但是不是要改代码发版，麻烦啊
我就想知道为什么这个优化器不会自己去找联合索引

[tidb菜鸟一只 (小菜一颗)]

我的意思是，是不是强制走联合效率还不如走单列，所以走了单列，可以把两个执行计划发出来看下

[像风一样的男子]

看执行计划走字段2的单索引在全表扫描啊

[diwing (Ti D Ber R Qstj35v)]

删掉单列vin index，只保留vin_update_time index试试

[像风一样的男子]

把这2个字段单独索引都删除了就走联合索引了
为什么明明有更优的查询选择，优化器要走全表扫描？

[tidb菜鸟一只 (小菜一颗)]

你这表的统计信息是不是有问题啊，怎么estrows和actrows差这么多。。。看actrows，用下面两个sql好，看estrows，就是第一个sql效率高了。。。。

[Jellybean (李文杰)]

@像风一样的男子

SELECT * FROM a WHERE ( 字段1 LIKE ‘abc%’ ) ORDER BY 字段2 DESC

根据描述，可以确认的是TiDB的执优化器对于这个SQL的执行计划的理解，和我们预期的不一致。

这里有两个思路可以评估下：
1、 统计信息是否过期？如果过期请使用analyze尝试更新下。
2、根据SQL的语义，是需要将满足条件的数据全部逆序排序再返回，过滤、排序是会尽量依靠索引来实现的，所以重点评估索引的创建是否合理。