为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
【概述】场景+问题概述
两个表做关联查询，但是看执行计划，t_auth_person表貌似没有走索引，关联查询走的是indexhashjoin，这个SQL执行了1个多小时，没有出结果。
执行计划.txt (7.7 KB)
【背景】做过哪些操作
【现象】业务和数据库现象
【业务影响】
【TiDB 版本】
【附件】
TiUP Cluster Display 信息
TiUP Cluster Edit Config 信息
TiDB- Overview 监控
看执行计划是走索引了，从这个数据量来看这个时间是正常的，tidb目前不支持倒排索引，所以这个时间我觉得耗费在这里，把倒序改成time=max(time)试一下呢
这个时间太长了吧，放在传统的数据库上也不至于这么慢吧？1个多小时都没有出结果，后来取消了。
| ├─TableReader_53(Build) | 303385688.00 | root | | data:TableFullScan_
| │ └─TableFullScan_52 | 303385688.00 | cop[tikv] | table:p | keep order:false
这个p表看计划，是全表扫描呀
看你这个应该是ORDER BY 引起的，没有order by 应该是非常快的 ，对ORDER BY 后面 加到联合索引里 ，应该可以解决问题
目前也遇到因为order by导致SQL 执行慢，大概在250W数据 排序 limit 25条
去掉ORDER BY快了，涉及到业务的SQL，有order by 的场景怎么弄呢？
tiflash
如果只取一条的话按照我说的time=max(time)试一下呢，因为tidb目前不支持倒叙索引，所以desc这个排序走不到索引，另外我理解两个表关联本来就分驱动表和非驱动表，仅仅关联不可能两表都走索引
这个我们反馈一下，这个…
( 不过下次麻烦带上 集群版本号，优化器这块，每个版本都在优化，你不带版本，不好确定是否高版本已经ok了）
这个符合预期啊，我以为 insert time 上有索引呢，看了一下你是2个id 上有索引，time 上没有索引，全表扫描符合预期啊（传统数据库也会很慢的）
按照目前情况 可以和on字段组合联合索引验证下，tiflash 未必行的，线上测试5.2版本+4个TIFLASH ，没达到实际效果，还有你那左右表不能在加点WHERE限制么？尽量下推，让返回的数据尽量少，这样排序应该影响不大，或者让业务自己拿着数据自己做排序，目前我这是多个方案并行改造业验证
用tiflash不知道有什么优化参数的建议，目前验证调整的参数：
SET SESSION tidb_allow_mpp=1;
SET SESSION tidb_enforce_mpp=1;
SET SESSION tidb_opt_insubq_to_join_and_agg=off;
SET SESSION tidb_broadcast_join_threshold_count=100000;
SET SESSION tidb_broadcast_join_threshold_size=10485760;
SET SESSION tidb_opt_broadcast_join=ON;
SET SESSION tidb_distsql_scan_concurrency = 80;
SET SESSION tidb_opt_agg_push_down = 1;
SET SESSION tidb_opt_limit_push_down_threshold=100;
效果不咋地，一坨SQL 有6个left join 3个子查询
看执行计划 是否都下推到tiflash
tidb有什么命令，能够查看优化建议吗？
你的意思是，需要在order by的字段上创建索引，就OK了。
倒序索引不支持吗？我创建索引的时候，可以指定desc呀
例如：create index idx_name on a (name desc);
都全部走tiflash的
这个sql是取所有列，tiflash的性能不一定比tikv的性能高
那只能从业务侧去优化了