【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
使用tiflash查询的速度更慢了，查看执行计划，查询的数据是扫全表；SQL执行计划对比
是的啊，谁告诉你用 TiFlash 一定快了，如果一定快，那就都走 TiFlash 了 
同样是tiflash，扫描的数据量也不一致。就是怎么区分，难道一个个SQL去找吗？
不是聚合类sql的话，走tiflash不见得快啊，一般保持表的统计信息较新的情况下， 让sql自动选择走tiflash还是tikv就行了。不用特意调整，发现问题再单独处理问题就行。
请问是要区分什么？
基于cbo自己选择，非必要就不要hit了吧 
走tiflash 就不要select* ，是坏习惯。tiflash 本来就是列存了，要啥拿啥，这样扫描的数据就少了。其次你这个表reportTime 应该是字符串，substr 必定从第一个位置开始截取，完全可以考虑用前缀的like匹配。没必要使用substr函数
日期判断，我们一般改写成 大于等于 指定日期，小于 指定日期+1。规范中要求，不能对索引列使用函数。
看执行计划，tiflash慢好像也说的过去啊
我试试
TiFlash使用场景了解一下
就是一个有not exists的子查询
TiFlash 一定是全表扫描，如果你的 sql 筛选条件还可以的话，是更适合走 tikv 引擎的， TiFlash 适用于大范围聚合查询这种场景。
没有十足的把握不要hit吧，就算现在不出问题，后面也可能有问题的。我感觉这个就是一个小小补充，越到后面优化后，就使用的越少了。
需要看下当前tiflash这个组建所承担的并发量，自测发现并发超过30后性能会有陡降的情况
赞同，不到万不得已不要使用Hints，这个还是很难维护，一旦后面数据量、数据分布啥的有变化，之前使用Hints指定的执行计划有可能就变成更差的执行计划了，可能还不如优化器选择的执行计划，除非说你使用的场景比较稳定，Hints指定的执行计划能够保证一直就是你最佳的执行计划。
如果过滤字段区分度大，可以考虑看下能不能走下索引，对于这种区分度大的，走索引效率还是更高的；像这种reportTime是不是带YYYY-MM-DD hh:mm:ss 这种带时分秒的字段值？如果是这种，建议可以考虑下建个联合索引（reportType,reportTime），然后过滤条件写法也改下，改成类似between and 或者大于小于这种范围过滤的写法，总之不建议在过滤和关联字段上使用函数，这样即使字段上有索引也无法走索引。
where reportType in (1,2)
and reportTime between '2024-08-28 00:00:00' and '2024-08-28 23:59:59'