tiflash适合使用聚合统计之类的sql，直接查询还是默认走tikv
不是有update的时候会默认走tikv吗？普通查询走的tiflash
强制走试试？
set @@session.tidb_allow_mpp=1;
set @@session.tidb_enforce_mpp=1;
强制就失去意义了
那可以tikv 和 tiflash都走一次，用explain analyze打出实际执行计划，看看时间上tikv是否花费更少？
没这说法 
tiflash只是用来处理olap类的查询，oltp类的查询还是走tikv合适啊，tiflash数据是从tikv同步过来的，update肯定是先修改了tikv的数据，才会同步到tiflash里面
怎么区分olap和oltp呢？实际效果是在tikv下4分钟，tiflash下2秒
tiflash耗时2秒，tikv耗时4分钟
看来tidb cbo还不够聪明？
P.S：tidb配置里 isolation-read.engines是默认值吧？
什么版本的数据呢？
select * 应该是默认走tikv吧
OLAP就是统计汇总类的sql，例如统计表某个字段的总行数，或者sum之类的，一般是报表类应用OLTP，一般就是多行或者很少的行进行操作，一般是实际的并发类应用场景，例如商城浏览下单什么的。
业务场景很好区分OLAP或者OLTP，但是到sql语句上就不那么好区分了，我现在是没有搞明白cbo优化器怎么判断什么时候走tikv什么时候走tiflash的
是的默认多个引擎
6.5
分别执行如下语句，观察cost计算成本的差异，可贴下结果。
explain analyze format=true_card_cost select /*+ read_from_storage(tikv[net_ticket]) */ * from net_ticket where tick_dxidd=‘19712907354’ order by tick_onlinestime limit 100;
explain analyze format=true_card_cost select /*+ read_from_storage(tiflash[net_ticket]) */ * from net_ticket where tick_dxidd=‘19712907354’ order by tick_onlinestime limit 100;
show variables like ‘tidb_cost_model_version’;
试下把select *改成具体列试下？即便是能命中TiKV索引的查询还是可能会走到TiFlash的，更别说你这里没有用到索引。
我这里使用时为了避免OLTP流量跑到TiFlash上，还专门把OLTP查询节点上强制不走TiFlash。
单独搞了一个tidbserver节点做tiflash查询了