【 TiDB 使用环境】生产环境
【 TiDB 版本】
tidb v5.4.3
【遇到的问题：问题现象及影响】
最近新上线一个业务，查询频率很高导致查询tidb节点 CPU 100%，所以想让他走tiflash，把相关的表数据加到tiflash后，desc始终不走tiflash。
尝试过：
1，命令行session级别变量设置没用
set @@session.tidb_isolation_read_engines = “tiflash,tikv,tidb”;
2，手工hint SQL语句也没用。始终不走tiflash
所以很苦恼，想请教下怎么让他走tiflash？
确认已经TiFlash副本创建成功了么？
https://docs.pingcap.com/zh/tidb/stable/information-schema-tiflash-replica#tiflash_replica
tidb_isolation_read_engines = tidb,tiflash 再试下呢？
tidb_isolation_read_engines = tidb,tiflash
设置成这样管用。
走tiflash了。但查询速度 还没kv 快呢，啥情况啊大佬
截图里没有hint写法吧。
是desc不走，还是explain analyze也不走？
是的hint没截图上去，
这俩方法效果不一样吗？ 我一般只用desc来测试这个的
高并发简单查询，tiflash效率是没kv高的
数据库判断走tiflash差
是不是用了 SQL BINDING,这个优先级会高于hint，或者是客户端版本低没加–comments
这sql有什么好走tiflash的？
试试hint吧，感觉不管应不应该走TiFlash，只要hint，就应该按hint走才对。
tiflash是列式存储，适用聚合类的运算，比如group by 的求和。这条SQL是行查询，tidb选择走tikv行存储肯定更合适些。
查询频率很高不适合有tiflash tiflash并发比较差
适合走tiflush的sql会走，有的时候行式的tikv更好一些
7.X之前的tiflash都是先扫描所有的数据，然后再计算。所以如果你的表非常大，而SQL只需要一部分的数据，用TiFlash是没办法起到加速作用的，很可能执行起来还不如TiKV快。所以这就是为什么优化器会优先使用TiKV了。
建议升级到7.1再试下，应该能发现性能提升比较明显。
你这sql 三表left join 关联，没聚合等计算量，不用走Tiflash的，而且优化器也判断了，tiflash 要比tikv慢，就走kv了呗
简单行查询，没有聚合计算任务需求，原理上tikv更合适
那两个查询条件是点查 point get, 走tikv 就好了
https://docs.pingcap.com/zh/tidb/stable/explain-indexes#point_get-和-batch_point_get
