【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】tiflash 副本2个 有创建索引
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
demo sql.sql (30.1 KB)
按照union 拆分分段分析吧 看看是哪一段慢
单取一段出来,都挺快的. 因为我们会员基数比较大. 从tiflash 取到数据给db计算,这个过程就给db很大压力. db的计算好像是单节点的.
不想看这SQL 
那试试MPP模式呢
1 个赞
我们自己都懒得看… 太要命了
你要是运维就给开发看吧 ，你要是研发就重新开发吧
1 个赞
这玩意儿是程序拼接出来的脚本! 只能给后端同学了
谁写的谁优化啊
1 个赞
要不直接explain analyze一下看看？不过属实建议重写这个sql
1 个赞
执行计划也没有
explain输出执行计划看看。
建议重写sql吧。。。
确实要重写。 太臃肿
执行计划 大部分计算在db端处理。 数据量本身就大 就会比较慢，甚至超时
把涉及的表都加进tiflash里面去，然后强制mpp试一下看看。
最好是能提供你现在的执行计划。
强制mpp 也只能作用在每个子查询read数据的时候才用到tiflash 外层的去重还是要在tidb上运行
不会的，这种情况有几个可能：
1，你有些表没有tiflash副本。
2，sql中有些算子不支持下推，或者有人设置的下推的黑名单，这个算子在黑名单里。
3，有些小表，通常是维度表，被设置了缓存表。
除上述情况以外可以做到tiflash直接算出来，tidb直接拿结算结果。
我看了你的sql，好多都是同一个表不同条件，反复union。外加一些关联。正常情况应该是可以从tiflash直接算出来的。
