V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
rainbowismagic
V2EX  ›  数据库

大哥们看看这个场景怎么做查询优化

  •  
  •   rainbowismagic · 2023-12-02 20:28:59 +08:00 · 823 次点击
    这是一个创建于 390 天前的主题,其中的信息可能已经有所发展或是发生改变。

    场景的数据规模 260w 月*12 月,统计所有的数据的平均、最大、最小统计值。 分库分表用 shardingsphere-proxy 。试过单 mysql 进程保管 12 个月的数据,计算全部数据的平均值用了 8.04s ,如果两个 mysql 进程分别管理一半数据,计算全部的平均花了 5.44s 。

    1. 这个性能是正常的吗?数据很简单,每行除了 value 以外,没有 longtext 什么比较耗空间的地方。( navicat 显示每个分区表数据长度 250mb 到 500mb ,用的 M2 固态,不知道这个速度正不正常。)

    2. 单从数据库角度还有哪些能做优化的点。当前不太清楚是数据库哪一块耗时比较久。可能是 IO ,但是不知道怎么准确的测试。

    如果放到云服务器上,开两个 mysqld 做这个慢查询能把两个核跑满,感觉可能会出事。。

    GooMS
        1
    GooMS  
       2023-12-02 21:12:47 +08:00
    有优化空间,但背景信息太少
    rainbowismagic
        2
    rainbowismagic  
    OP
       2023-12-02 22:51:38 +08:00
    @GooMS 目前机器用的是 i5 8700 的 cpu ,内存 64g 够用,用的固态忘记什么牌子了。
    两个 mysql 8.0 都是在容器里,shardingsphere-proxy 在另一个容器,它们都在同一台物理机,测试也是 ssh 连到物理机上测的,应该不是网络的问题。

    表的结构 每行就一个时间戳,参数类型,参数值,和一些说明 balabala 。表结构比较简单,而且暂时不考虑 join (就算 join 也就是和其他两个数据量不到 1000 的表 join )。

    现在比较慢的地方就是统计一年数据的统计值,这个场景做索引感觉用处不大,基本上就是要扫全表。
    现在测试机这个配置应该还可以,云服务器配置比这还垃圾一些。所以需要提高点效率

    个人没有做过这方面的优化,所以不知道还要关注哪些信息?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5718 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 01:47 · PVG 09:47 · LAX 17:47 · JFK 20:47
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.