这是3表关联，tiflash+mpp的结果。2.8亿join 2.8亿,再join1000w.结果才会和你这个sql执行时间差不多。
我所有的tidb，tikv，tiflash都是4c8g的配置。
同样的sql我根本不敢用tidb+tikv的方式跑，因为必炸。
人生啊，就跟这个sql一样，你本以为顺顺利利，可总是有人不断诱惑你，劝你，所以这个sql也没有那么一帆风顺 
1 个赞
换个思路，能否吧数据预处理一下，用flink之类的实时计算吧数据插入到统计表然后再查询，是否会变快呢？
多事之秋，也不知道说什么能让你感觉好点。
只能说，想开点，起码快下班了。
社区这么多人，也许睡一觉就有你看的上的方法出现了呢。
1 个赞
我原本想优化一下看看，当我阅读了一会执行计划，我放弃了，这个不好弄，给你一个建议你可以测试下，你把你的mem_quota_query调大点，因为你快的那个sort没有落盘，这样试下
PS：TiDB这个内存控制，总感觉干个啥都特耗内存 
1 个赞
已经睡一觉了，起来看看有啥方案没有
把子查询放在with as看下能不能提升性能
能提升一些，但是也没有去掉这个if这么明显
不嫌麻烦就建个临时表，把中间结果放到临时表
昨天就已经试了，情况能稍微好点，但是有这个if还是影响性能蛮大的
加这一行if 170多s，不加30s，差别还是很明显的
看语句，这个if语句不应该影响像你说的那么大呀，case when看看？
你这不是tidb的问题吗你这个是框架的问题
感觉是finebi这种托转世的bi工具
你上个tiflash就好了
这个SQL真的是手写出来的吗？
我不知道你说bi是啥，我们没用bi工具，用tifalsh没走
是手写出来的
一个项目400行500行sql不是很正常的吗？
正常吗？这么长的SQL改起来很吃力的。
不是有视图，临时表么？结合使用逻辑上很清楚的。
我不知道您是做什么项目的，我干了这么多年了编程，遇上的还是挺多的。第二点您说的视图的问题，视图不一定能提高效率有时候还会减慢效率