【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
在数据库执行计划中发现like ‘ABC%’ % 无法走索引，只能全表检索，请帮忙分析下原因，
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
贴一下表结构，执行计划
发下表结构看下
还有数据量也贴下，数据行数太少也不走索引
统计信息不准确，表的大小和数据分布，索引的选择性，查询的复杂性等因素都有影响，导致不走索引，看一下执行计划来进行分析。
看一下统计信息是否准确，或者是不是select 字段过多，查询索引在回表，不如直接全表快
explain 、 explain analyze 分析下
看下索引是否有效，查看下表的元信息、健康度 show status_meta、show status_healthy，看是否需要更新下统计信息
执行explain analyze看看呢
统计信息准确率 100%
hint 绑定下试试强制走某个索引 看看效果
explain analyze SELECT /*+ use_index(‘别名’, ‘索引名称’) */ * FROM t2 as 别名 WHERE a > 1 AND b = 1;
–创建绑定
– Hint 能生效的用法
CREATE GLOBAL BINDING for SELECT * FROM t2 as 别名HERE a > 1 AND b = 1
USING SELECT /*+ use_index(‘别名’, ‘索引名称’) */ * FROM t2 as 别名 WHERE a > 1 AND b = 1;
–查询绑定
SHOW GLOBAL BINDINGS
–删除绑定
DROP GLOBAL BINDING FOR
SELECT * FROM t2 WHERE a > 1 AND b = 1
这个是回表慢，建议用联合索引过滤大部分数据
能把语句也贴一下么？看上去是选择了另外一个索引吧，好像一个sql只能用一个索引。
走like会比走start_time过滤更多数据吗，如果不会，那现在走start_time没问题的。
start_time是一个范围值，就算跟like的字段是联合索引，也不能走这个索引啊。
如果走like会更优，那就用hint绑定like字段的那个索引，强行走like
而且从整个sql来看，表l和表d走index join应该更好吧
看着 走索引（range）了。是不是分区表，跨分区，然后回表了。
具体SQL是什么 ，表数据量 ，结果集数据量是多少
最好是能尝试一下tiflash+mpp。
根算子是hashagg的情况下，提升会很明显。
先用HINT强制走试试，能走的话，重新统计一下表信息