mysql 统计问题

[xinzhognyi]

正在做一些运营支撑，统计一些数据。
这些统计如果用 sql 写的话，会很复杂，并且有可能会影响到 sql 的性能。
现在有些统计就不直接用 sql 统计了，而是把数据统一查询出来，然后再使用代码来分析统计
哪种方式会比较好？

举个栗子吧，比如我有 100 账户，要统计 100 个账户下各自的数据。每个账户需要 4 条不同的 sql。
最简单的就是查询出 100 个账户，然后每次循环发送 4 条 sql。但是账户多了，就会导致 sql 太多而接口超时。
现在我的解决办法是只发四条 sql group by 账户。然后代码中，把数据循环塞到每个账户下。
还有，在这里只是来讨论下各自的思路，每个人思路不同，你有不同的思路可以说出来，大家可以讨论一下。就不要那么高深莫测了。

[p2pCoder]

这种需求 应该交给 数仓

[yidinghe]

看对统计效率是否有要求。如果要求很高，那么还是要花大量精力做针对性的设计调优。

1、自己在代码里面分析，效率反而低，因为 SQL 的复杂度实际上就是业务的复杂度，后者代替前者得不偿失。
2、用大数据框架统计也可以，但花费的时间可能要多上十倍几十倍。

[F281M6Dh8DXpD1g2]

你觉得你能比 mysql code 写的好你就自己写呗
大概率不能，mysql 再烂，毕竟优化快二十年了

[zr8657]

有种方法是把要查的多表数据存成一张表，然后直接查

[humansjl]

这没有一定说哪个好哪个不好的，看 sql 影响到的性能 vs 额外建数据仓库 两者取舍了，或者一步一步来，每条 sql 先试着调优看看，毕竟调优有时候也挺花时间的

[awah]

可以用存储过程试试. 在存储过程里面将任务分割, 最后汇总到一张表里面.

[Immortal]

视图 或者 从库
目前我是用的后者

[wqzjk393]

你的意思是表内容太大，直接用聚合分析函数写复杂的查询逻辑会很慢，所以就直接 select*然后导出来，用别的方法处理？首先那么大的数据量不是应该用 hive 平台么？另外如果真的想导来处理，可以用 pandas，基本的 groupby 透视什么的都有

[wqzjk393]

我很多时候都是用的视图，分开一层层的写逻辑。要不然一堆子查询和关联套来套去很容易晕而且后期不好修改时候不容易理解当时的逻辑。

[szq8014]

觉得驴累了就把驴抗起来走么？

[he583899772]

卧槽，平时我都是为了减少复杂用 sql 去避免复杂的业务逻辑代码。。。

[alcarl]

不说具体泛泛而谈等于没说，SQL 这种东西就是为了统计数据而生的语言，能站巨人肩膀上谁还站地上。

[realpg]

做个 slave 然后随便在 slave 上统计

[xmh51]

做个从库啊 在从库查询

[hayman]

你也可以把数据库流入到 kafka，起一个 ksql server 进行实时的统计， 需要的时候直接从 topic 取结果。

[szq8014]

挖个坟，这不是 SQL 的锅，是思路的事，看你的更新后思路应该是没问题了。其实新思路也可以用 SQL 完全写出来。

关键字搜 行转列