看tidb和mysql的执行计划一样，tidb主要慢在indexJoin去p3表获取记录，但是这里和mysql行为一样，tidb却很慢，这块应该主要是c.persionid太不连续导致，在lsmtree和btree的等值查询硬碰硬情况下lsmtree差的还是挺多的，尽管tidb已经在内部做了很多优化（比如尽量将key作为有序请求，get请求数据转为next）但是c.persionid过于离散会导致大量的逻辑block读。另外也没想到mysql对400多万数据主键关联索引查找仅需5秒就能搞定，我估计索引都在内存中吧。 tidb索引IndexJoin的一些行为在这个贴子里有较为详细的探讨，希望有所帮助：tidb index join 强行指定连接顺序后执行时间变化的问题
@小龙虾爱大龙虾 ，虾总在一开始就指出了你这并非最优执行计划，并且给出了最佳的连接顺序leading(c,p3,atdtimeordercalender)，虽然走了tiflash，即使不走tiflash也不会慢，这个优化是可取的。
另外如果 atdtimeordercalendar的 KEY ix_TIMEORDERID (TIMEORDERID ) 需改为 KEY ix_TIMEORDERID (TIMEORDERID ,calendardate)，那MySQL可能会更快很多，但TiDB无法加速。这是因为MySQL的a join b on a.col1=b.col1 and a.col2 < b.col2 index on b(col1,col2) 可以左表一条一条查询记录，不管等值条件还是范围条件都可以下压到右表进行过滤。但TiDB需要一批一批查询左表记录，只能下压等值条件到右表过滤，对于范围条件的只能拿到计算层过滤。