单表一亿数据查询order by 需要32分钟，这个怎么优化？已经加了TiFlash
【 TiDB 使用环境】生产环境
【 TiDB 版本】5.4.0
【问题现象及影响】单表查询很慢
【复现路径】
【资源配置】8台8c16g服务器，2个tiflash，3个TIKV
你这个是select *了，有tiflash也没多大作用，tiflash适合select 一列或者几列的情况。
如果优化tikv，那就是提高扫描速度。
从以下几个方面：
- 增加tidb的coprocessor cache，扫描第一次就缓存下来了，如果数据变化不大的话，第二次就命中了。
https://docs.pingcap.com/zh/tidb/v5.4/tidb-configuration-file#capacity-mb - 增加tidb和tikv的grpc连接数，相当于更大的并发扫描。
https://docs.pingcap.com/zh/tidb/v5.4/tidb-configuration-file#grpc-connection-count - 增加tikv的unified read pool和grpc pool的线程数。
https://docs.pingcap.com/zh/tidb/v5.4/tikv-configuration-file#readpoolunified - 增大blockcache的大小，相当于增大rocksdb的缓存，更多的缓存数据。
https://docs.pingcap.com/zh/tidb/v5.4/tikv-configuration-file#storageblock-cache
基本上这些吧，如果你的集群总是读多，那就这些调大比较合适，如果你的集群偶尔读一次，那内存相关的参数慎重调整，因为还要留着内存给其他的查询。
当然，最有效的还是优化sql，尽量不要扫描或者扫描的少一些。
另外你这个查询没走tiflash，我不确定是因为select *还是因为你tiflash没增加副本。如果确认增加了tiflash副本还没走的话，那就是确实走tiflash代价比tikv大。
执行这个sql去掉order by 需要8秒，有order by 就检索不出来了，请教各位大神，是要数据库配置什么吗？
where后面的两个条件有没有索引，选择性如何，看执行计划时先走了order by的时间索引。
去掉后的看下执行计划，应该是有索引的，看下索引名， 在写order by 的时候加个hint强制走索引应该就可以了。
你要回表啊，上面那个朋友说了，你是select * ，看下你不加order by 的执行计划
重新收集下表的统计信息。create_time的索引就这1列吧？ 什么情况下会用到这个索引考虑是否可以干掉这个索引
这个索引就是当时因为排序加上去的，如果是这个索引影响的话，我可以试着先把他干掉试试
看下你这版本可以设置索引invisible不，就不用直接干掉测试了
可以试试给tiflash CPU扩容
https://docs.pingcap.com/zh/tidb/v5.4/use-tiflash#使用-tidb-读取-tiflash 手动指定走tiflash。如果还想更快，估计要看where条件后的选择性，走tikv，加联合索引，强制走联合索引，减少回表
看了看tiflash也有提高并发相关的参数
## 从 v5.0 引入，表示 TiFlash Coprocessor 最多同时执行的 cop 请求数量。如果请求数量超过了该配置指定的值，多出的请求会排队等待。如果设为 0 或不设置，则使用默认值，即物理核数的两倍。
cop_pool_size = 0
https://docs.pingcap.com/zh/tidb/stable/tiflash-configuration
你翻腾翻腾
