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

MySQL 单表上亿条数据有必要考虑分表吗?目前已经 8400 万条了,感觉查询耗时也没有明显提升,就是 CPU 不查询占用也在 20%以上,不知道在干什么。如果有必要的话求推荐下 EF Core 上安全、好用的分表方法。

  •  
  •   edis0n0 · 2022-09-25 12:53:35 +08:00 · 6105 次点击
    这是一个创建于 550 天前的主题,其中的信息可能已经有所发展或是发生改变。
    38 条回复    2022-10-17 13:08:39 +08:00
    lyhiving
        1
    lyhiving  
       2022-09-25 13:06:04 +08:00
    主要看是什么数据,读写频率是怎么样的。如果没事就没必要动
    documentzhangx66
        2
    documentzhangx66  
       2022-09-25 13:09:24 +08:00
    请先思考一个问题,为什么要分表。
    wxf666
        3
    wxf666  
       2022-09-25 13:11:58 +08:00
    前排问一下,一直说的『单表超过 x 千万后,效率瞬间下降』,是因为 B+ 树层数变高(这个量级应该是 3 层变为 4 层吧),但缓存没变(比如,只缓存了前两层),导致看起来原本实际进行一次 IO ,现在需要两次,即多一倍耗时?

    如果是这样,那楼主看看现在是不是已经 4 层 B+ 树了,若是就不必要分表了?( 4 层可以容纳上百亿行了吧)
    ychost
        4
    ychost  
       2022-09-25 14:32:05 +08:00
    没必要,分表查询就很蛋疼了一般都需要分表键做路由,只要查询命中索引率高就没必要去折腾了
    thinkershare
        5
    thinkershare  
       2022-09-25 15:59:17 +08:00
    如果你觉得性能没问题, 就先不要管它, 等到性能出问题再去处理, 每多加一个中间层次, 都会引入很多其它的问题需要处理, 性能问题就是这样, 出了问题再去考虑优化。
    changdy
        6
    changdy  
       2022-09-25 16:10:44 +08:00
    过早的优化是万恶之源 ..

    简单场景还是别分表了 后期 维护麻烦
    Maxwe11
        7
    Maxwe11  
       2022-09-25 18:13:42 +08:00
    1 、现在跑的好好的服务,不要随便调整;
    2 、但是可以自己预先做模拟,先分析业务问题,再做潜在设计,然后在测试服务器上做模拟,以防万一某一天突然出问题,可以迅速找到解决方案,毕竟业务等不得;
    3 、分区分表建索引,搭缓存,各种技术方案还是由业务需求来的,如果对业务不熟悉,且对业务发展预期不清楚,确实可能会发生比如某种业务变动,导致这个提前的优化操作阻碍业务进行的情况发生,确保至少在未来新一年整体规划里,业务的变动都在考虑范围内,别到时候今天优化完了明天一调整还得回滚,好心办坏事儿还得背锅,别问我是怎么知道的。
    az467
        8
    az467  
       2022-09-25 18:38:04 +08:00
    网络八股文说单表上亿会有性能问题,所以才要分表。

    你这都没性能问题,瞎折腾好玩吗?
    agmtopy
        9
    agmtopy  
       2022-09-25 22:02:45 +08:00
    预估一下啥时候出问题?在你任职时间之外管它干嘛~
    zibber
        10
    zibber  
       2022-09-25 22:06:09 +08:00
    同步到 tidb
    victorc
        11
    victorc  
       2022-09-25 22:23:41 +08:00
    单表不能上亿那扯淡的,现在硬件很强劲,特别是用了 nvme 的 ssd ,比起 hd 来有几十倍的性能提升,我的业务 mysql 跑在虚拟机上,而且磁盘还是云盘! 单表上亿也能用

    分表是个大动作,要修改的地方非常多,你可以盘点一下表里面的数据,不需要得数据及时归档
    misaka19000
        12
    misaka19000  
       2022-09-25 22:30:59 +08:00
    没遇到瓶颈不需要折腾,有瓶颈了再去考虑
    ruiyinjinqu
        13
    ruiyinjinqu  
       2022-09-25 23:04:57 +08:00
    也看你写入删除的频率,分表分得不均匀也会造成问题,还有对于逻辑的优化
    LuckyLight
        14
    LuckyLight  
       2022-09-26 00:07:05 +08:00
    如果表的字段比较多或者一行数据占用的空间比较大,按照现在的数据量,还是要考虑分表的吧
    T0m008
        15
    T0m008  
       2022-09-26 02:34:14 +08:00
    不能光看数量,还要看数据结构,整个表占用空间,和未来的增长速度等等
    pavelpiero
        16
    pavelpiero  
       2022-09-26 08:41:38 +08:00
    看看硬盘的配置 ssd 的话 上亿也很就还好
    bthulu
        17
    bthulu  
       2022-09-26 09:15:42 +08:00
    别优化表了, 优化硬件最简单, SATA 机械换 NVME 的固态, 性能瞬间提升 100 倍. 你再想想你怎么优化单表能达到 100 倍以上的性能?
    zt5b79527
        18
    zt5b79527  
       2022-09-26 09:21:06 +08:00
    我们订单表里 1.3e 数据,跑的飞快,一点问题没有(国内某公有云)
    jaylengao
        19
    jaylengao  
       2022-09-26 09:32:40 +08:00   ❤️ 1
    单表 1.6E 跑的飞起。引入 cache ,数据库压力很小的
    itechnology
        20
    itechnology  
       2022-09-26 09:41:08 +08:00
    我的观点是,不是单表数据量达到了上亿就要分表,得看你的实际情况,大家说的要分表是因为性能已经不行了,不得不分表了,你这性能没有不行,所以我觉得暂时不用分表。
    INCerry
        21
    INCerry  
       2022-09-26 09:45:06 +08:00
    如上面所说,硬件 OK 的情况下单表上亿问题不大,后面如果数据量更大,可以考虑下面的分库分表中间件。
    https://github.com/dotnetcore/sharding-core
    ipwx
        22
    ipwx  
       2022-09-26 10:02:01 +08:00
    可以不动生产环境,但是可以开个模拟环境测试性能嘛。
    encro
        23
    encro  
       2022-09-26 10:24:47 +08:00
    看你记录类型和查询方式,可以考虑冷热分离方式。
    leafre
        24
    leafre  
       2022-09-26 11:08:11 +08:00
    会导致业务逻辑复杂度增加,不轻易使用分库分表

    不是达到多少数量量就一定要分库分表,主要看性能,性能不行了,没办法从其他方面优化了,万不得已可以考虑分库分表。
    leafre
        25
    leafre  
       2022-09-26 11:10:22 +08:00
    比如十亿数据表,单字段维度的过滤查询结果,查询时间 100ms 左右,根本不用考虑分表
    wdwwtzy
        26
    wdwwtzy  
       2022-09-26 13:03:12 +08:00
    听说 sqlserver 的优化更好,单表几亿几十亿都没问题?
    有人确认过吗?
    dcsuibian
        27
    dcsuibian  
       2022-09-26 13:15:20 +08:00
    没有性能问题就先别管它

    我之前有一个历史数据表,里面就是时间戳+关联 id+值,主要就是查询某个时间点的状态,建了索引(没建肯定慢的要死)

    测试时放了 8 亿条(或者是 4 亿条,记不清了),然后查了 1000 次,总共就花了 1 秒多,感觉够用了就没改
    sadfQED2
        28
    sadfQED2  
       2022-09-26 13:49:38 +08:00 via Android
    我前司,一张评论表 20 亿+数量,依然正常使用,uid 查询 10ms 以内
    roundgis
        29
    roundgis  
       2022-09-26 13:57:02 +08:00 via Android
    @az467 那可能是 20 年前的文章了 mysql 現在單表過億並無問題 我都試過
    cubecube
        30
    cubecube  
       2022-09-26 13:59:19 +08:00
    分表没啥用,除非你单机 cpu 扛不住的时候,分库顺便分表。
    leegradyllljjjj
        31
    leegradyllljjjj  
       2022-09-26 14:02:58 +08:00
    现在的人都喜欢瞎坤巴折腾,我们组就有个人就喜欢看见别入弄点啥都想拿来折腾一下,完全是闲着没事儿为了折腾而折腾,到时候出点线上问题你还得为他擦屁股背锅
    dog82
        32
    dog82  
       2022-09-26 14:35:23 +08:00
    要看表里的数据怎么用,如果只是按 id 查询就不要分
    nekoneko
        33
    nekoneko  
       2022-09-26 17:45:34 +08:00
    分表会搞得很麻烦, 系统不大的话不如分区, 跟分表是一样的效果.
    另外如果没有必要, 就不要分了
    ytmsdy
        34
    ytmsdy  
       2022-09-26 19:33:04 +08:00
    只要能跑,用户能接受,服务不奔溃就好了。
    有这闲工夫打打游戏不好么。
    tramm
        35
    tramm  
       2022-09-27 10:50:08 +08:00
    2 亿了, 加上索引, 没影响
    monetto
        36
    monetto  
       2022-09-27 11:38:15 +08:00
    我们线上库大概 10 亿级,是直接物理机部署的。2T SSD ,CPU 是啥忘记了 ... 运行一切良好。读写分离 + 单表。
    xshell
        37
    xshell  
       2022-09-30 13:16:46 +08:00
    @wdwwtzy
    大表(70 多个字段)五千多万查起来就卡了,SQL 特别要注意~
    还是物理机。
    用过的最多不到 3 亿,单表十几亿几十亿的没遇到过,。
    daoqiongsi1101
        38
    daoqiongsi1101  
       2022-10-17 13:08:39 +08:00
    分库分表场景可以用腾讯云 TDSQL
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2601 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 15:53 · PVG 23:53 · LAX 08:53 · JFK 11:53
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.