个人看法：
shuffle 一定是宽依赖，源码中对宽窄依赖，是根据算子的名称来定的（我记得源码里面是这样的，宽窄依赖也是这样定的）。
他的意思是即使是宽依赖，但不一定会有数据的网络传输吧

1. 知识储备够吗
2. 人脉资源够吗
3. 资金够吗
不满足就老老实实打工吧

前期不要谈工资！大雁打下来才有肉吃

说实话，近视还真的是可逆的，前几年生病住院，然后差不多 20 天没带眼睛，天天是休息，看天花板，感觉从 300 降到了 100

有和我一样，听得最多的是渡口吗？

我和楼主一样，主要原因是我们不够韬晦，给公司做了很多提升效率的工具，在别人看来，就是太能了。

人情是要送的，鉴于你这种，建议请吃个饭，送点家乡特产（淘宝）啥的

强烈推荐暖手饼，彩虹牌的，时间就，够热，陪伴了我高中三年和大学 4 年，毕业 3 年了没用，昨天用了一下还没坏！

SB 公司，更重要的是，SB 领导

兄嘚，改成算法工程师吧，好招人点

没有特别喜欢的就 1、数据与智能工程吧

加个微信吧，"a2Fpc2h1bmthaXNodW4=" base64 加密

@revival83 同 T1DM，可以一起做，不过最近比较忙

或者，在业务上另外想一个办法，再加一张表，专门用来维护

个人觉得，分表分库可能没有用，首先，这个是做了索引的，查询是会比较快的，慢是因为对索引过滤的这一部分数据进行 group by 汇聚的时候慢，楼主可以看看慢的时候，不进行 group by，看看有多少条数据。
如果过滤出的数据比较大，2-5 秒，也是比较正常。

对于这种解决办法，一般都是想着硬件上的优化了，分库，采用分布式的可能有用，在多台服务器上，各自 group by 一部分，然后再对各个服务器上 group by 后的再进行汇聚。 不过这个也不一定快，万一各自 group by 后，各自的电脑的数据量还是很大，这样会有大量的网络 IO。
具体的情况，还得根据具体的数据情况来看

兄弟，你这个语句在 mysql 的 sql 层次优化不了，我估计这个查出来的数目比较多，即使用了索引，查询是很快，但是对查出的数据进行 sum 等聚合操作，就是慢，也没得办法。

没事，下班到点走就 OK

北京到深圳，用的德邦物流

读了 10 来本纸质的吧（超过 40%），电子的超过 30%也有个 10 来本。