like加双百分号用不到索引的，mysql也一样，这种就是全表扫描，但是过滤条件是下推了，每个tikv节点只会返回符合条件的数据，而不会返回所有的数据，让tidb-server再去过滤。
在你数据量越大，tikv节点越多的情况下，相当于很多个tikv节点并行过滤，肯定效果比mysql要好的。
有个说法是， 分布式的速度并一定比集中式快，但是扩展性要好很多。 所以是不是调整下思路， 分布式不一定快呀。
结合这个场景我在验证下
看执行计划里有cop[tikv]就是下推，尽量like时前边不加%
这两天晕了，是下推了但是走了全表扫描，怪我怪我
就算是全表扫描，其实理论上也比MYSQL快
对，因为压力分摊了
cop[tikv]意思就是在tikv上执行的。operator info里面写着like。所以这就是在tikv上执行的like算子。
1 个赞
执行计划中，是不是正常的SQL都会cop[tikv]，除非用到了TIFLASH 
毕竟tidb节点是无状态的没数据在上面，要么去tikv取，要么去tiflash取。
这两个都用不上的情况，我想了想可能只有缓存表了。
嗯嗯，有道理
还有Point_Get这种场景吧？
1 个赞
是支持的