MySQL 查询数据太慢了，该怎么优化？

[182247236]

sql 执行语句 SELECT timestrap, bps FROM cdn_bandwidth WHERE (company_id = 1 AND domain_id IN (242,292,194,264,217,195,203,200,198,221,227,335,167,243,261,218,196,176,174,162,161,160,170,173,325,169,324,171,236,241,220,256,276,186,263,254,286,287,285,288,283,278,291,215,334,260,321,316,318,319,323,322,163,159,213,207,238,274,164,333,280,249,247,246,252,273,255,181,180,248,226,178,179,293,265,301,237,175,240,262,166,305,326,304,165,177,259,225,183,214,193,197,206,290,257,258,219,189,172,209,267,210,271,272,229,302,300,303,275,320,239,284,205,208,182,191,190,277,250,298,295,297,269,216,187,232,230,231,251,185,294,244,245,281,168,268,188,184,223,202,222,192,224,332,282,199,270,266,289,296,234,253,201,233,235,279,211,315,228,204,212) AND time BETWEEN '2021-12-01 00:00:00' AND '2021-12-26 23:59:59')

查询出 1038259 条数据，共花费时间 125 秒。太长时间了。有没有办法能优化下。

[chengyunbo]

表结构贴一下呢，看这个 explain ，time 没走到索引，另外千万级别的数据量，是要考虑中间表了，或者 es 这种，单从时间上看是 time 字段没走索引导致耗时很高

[clf]

如果只写不删不更新，只用于统计。我觉得你可以考虑一下 clickhouse 用于存储此类数据。

另外，数据计算，python 不一定比数据库快……建议直接在数据库 SQL 里完成统计，因为数据库和 python 间还有数据传输开销。

[182247236]

@long2ice 我查下联合索引怎么用

[182247236]

实在是头大，数据库知识不太懂，也是边做边学。有懂的请指教下！

[zengguibo]

这种最好优化了，就是按时间分表，一个月一张表，里面再加索引，到时候删除也方便

[182247236]

另外如果我查询 1 天的数据是飞快的，我还以为 30 天的数据也就是递增查询就完了

[RangerWolf]

查询 1M 条数据，感觉无论如何也快不到哪里~ 如果可以使用 Clickhouse 之类的计算，可以直接计算汇总数据。速度要快的多~
MySQL 本身确实不是很适合做这个事情。

不知道这个表还有没有其他的字段，实在不行可以尝试给第一个索引增加新的字段，把 timestrap 跟 bps 都加到联合索引之中，这样就不需要回表查询，理论上会快很多。

[lscho]

数据库在哪？你在哪查的？

[182247236]

@lscho 数据库和我的服务器都在机房，很近的

[xhcarlin]

如果有办法强制指定用那个联合索引，应该会快一些才对

[xinJang]

我第一反应是子查询，果然数据库不行，泪奔

[xhcarlin]

我现在的业务也有很多这类日志，不过用的是 mongodb ，单表也有 1500w+了。一般我们是做一个每日的中间表，然后数量就一下子下来了，python 这边压力也小一点

[182247236]

我现在检查到第一个问题，首先我查一天的所有数据需要的时间是 1s 左右，但是没走索引，所以我的索引是不是做的有问题？

[jenlors]

看看这个，https://dev.mysql.com/doc/refman/8.0/en/index-hints.html ，使用 force index

[jenlors]

如果可以加下 limit 之类的，返回数据太多了

[freelancher]

请个 DBA 。例如我。收费帮优化。

[neptuno]

每天、或者每半天统计一次。然后再去计算一个月的

[w0017]

时间字段加索引，把 BETWEEN AND 换成大于小于

[zhoudaiyu]

开个 SSH ，让我上去看看🐶

[rrfeng]

根本解决方案：上时序数据库。
SQL 优化：加索引，预聚合，联合索引。