对的，看楼主上面的描述，并不是不能走TiFlash，而是没有选择走TiFlash，可能是优化器评估走TiKV代价更低，所以没有选择走TiFlash。这个可以通过EXPLAIN FORMAT = “verbose” ，对比下走TiFlash和走TiKV的代价哪个更低。
EXPLAIN FORMAT = "verbose" 你的SQL
EXPLAIN 语句将以 row 格式输出结果，并在结果中额外包含一个 estCost 列，表示查询的代价估算。
参考：
https://docs.pingcap.com/zh/tidb/stable/sql-statement-explain#expla…
12 天前
不支持，我们从DB2数据库迁移到TiDB，DB2那边原本有一些merge into语句，但是后面都是只能改造，比如改成replace into、insert into … on duplicate key update等等 。
13 天前
主要还是得看你的场景，比如处理数据量大不大，并发高不高，如果是处理数据量很少，并发很小，还是可以的；但是这种数据量一大或者并发一高，冲突几率可能会比较大，处理效率也一般；我们采用的都是先查询再流式并发写入，这种效率还不错，特别是对大数据加工的时候，采用TiFlash查询+流式并发写入，相比INSERT … ON DUPLICATE KEY UPDATE，效果会明显更佳；目前官方推荐的也是先查询再流式并发写入。
可以看下官方的批处理一些测评：
13 天前
最大的收益有两点：
1、搭建和运维更加简单，自带的Dashboard和Grafana监控还是比较丰富，各种监控指标使得查问题时可参考的依据多；
2、真正的HTAP数据库，TP和AP不是割裂的，以前AP只能用AP，TP只能用TP，两者不能同时用，而TiDB的AP和TP是可以交互的，而且交互速度也不错。
16 天前
是的，大部分切换并不是一句话就能解决的，也并不是说数据库换了就可以，还是有诸多的问题，比如应用端代码改造、上下游切换这些问题就可以够折腾了。不过这些问题也能解决，但是最终还是聚焦到要花多少成本，毕竟是真金白银的投入，而不是纸上谈兵。
18 天前
说的很对，不是不想换，只是目前换的人力成本太大，这个是一个循序渐进的过程，可以关注下现在重构应用或者新建应用是使用分布式数据还是分库分表的多，而不是关注存量的，存量很多是历史遗留和成本的问题。
18 天前
没有更多内容了