有and col_18 in (‘US’) 这个条件和没有这个条件，执行计划中命中索引一样的么？
是一样的 都是走的index_col_6_col_2
就算给col_18加上索引 tidb也不会走这个索引 强制指定索引走index_col_18的会比走index_col_6_col_2更慢
应该是只有col_6 以及col_2参与查询，会用到覆盖索引不需要回表，所以查询效率很高，而加了 col_18 这些其他字段，走不了覆盖索引，需要回表，所以查询效率变慢了。
你 count(1) 看下总共命中的有多少行？
顺便问下，TiKV 存储的 IO 效率怎么样？以及查询时候 TiDB 和 TiKV 的负载怎么样？ 瓶颈是在 TiKV 还是 TiDB ?
应该和覆盖索引没关系 我每次查询都是select * 肯定都要回表操作 我更倾向于是由于没加上col_18条件时 经过联合索引index_col_6_col_2过滤后的数据(39989259条)很多都满足条件(982631条满足) 只需要取到前100条满足的即可 不需要将过滤后的数据全部扫描 但是加上col_18条件后满足的只有207条 此时需要扫描几乎所有4千万过滤完成的数据才能找到满足条件的100条数据
是的，这个可能性最大，因为看你发的执行计划，是已经走到索引了的，所以只能是扫描数据量的问题导致的
你这个场景可以试试Doris加同步物化视图，tidb不太适合耦合度较高的业务场景
1 个赞
我们是实时高频AP系统 物化视图好像不太行 数据有一直在变化更新的
问题1：tiflash适合的是聚合查询，也就是带group by的。你上面这个语句是不带group by的这种语句在tiflash不会很快，甚至并发高了会不如走tikv的速度快。
问题2，count（*）是典型的聚合计算，tiflash+mpp会比tikv+索引的速度快2-10倍。
所以总体我感觉，不是不能做，要做的话你可能需要对tidb比较熟悉。
不带group by的走tikv+索引，带group by的走tiflash+mpp。这是个大的优化方向。
我的建议是，实际工作要选择熟悉的方式来做才稳妥，tiflash的方面你还是需要慢慢了解的，就现在这个需求，既然ES是你熟悉的，那就应该用ES。
等真的发现熟悉了，有信心替换了，再换到tiflash是很容易的。
1 个赞
原来是通过col_6,col_2查询返回，不需要排序只需要回表取到limit数量后就停止，增加col_18需要回表很多次才能满足limit数量所以时间长，单独解决这个可以建col_18,col_6,col_2的复合索引
麻烦看一下执行计划
加上col_18只是稍微复杂的而已呢 实际上用户可以对其中15个字段任意组合进行查询 联合索引在这种情况比较鸡肋
大概率是回表慢，可以考虑将这种字段加在索引最后面
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。