MySQL 处理亿级别的数据怎么做?

[echoless]

面试的时候被问到这个.

面试官的问题是要设计一个交易所, 支持亿级别的 CRUD.

我被问住了, 我的有限经验 Postgres 接近过了亿级别, 就很有点慢了.

当时一直找不到好的解决办法.

我就说要 sharding 一下, 分库分表实际上也是 sharding 的思维.

[awalkingman]

上来就要设计一个交易所，亿你麻痹亿亿亿。

[prodcd]

我这有个 MySQL 表，结构比较简单，类似 key/value 结构，再加个 datetime 用来分区，7 亿数据量，查询带着 datetime ，速度没任何问题。感觉只要能将查询落到分区里，速度不会有什么明显变化。

[luoyou1014]

表结构尽量简单，确保查询要走到索引，复杂查询拆开，便于优化，上 SSD ，读写分离，可以支撑到 10 亿级别数据
再往上可以用分区功能，我的经验只到 20 亿级别，没有开分区，也扛住了。

[echoless]

@awalkingman #1 这个没办法, 面试官问,我没接触过, 给问懵了.

[echoless]

@prodcd #2 insert or update 怎么办?

[GeekGao]

就这些主要的

[echoless]

@GeekGao #6 多谢, 我顺着这个思路看看.

[esile]

MongoDB 高过 10 亿的，MySQL 百万级别优化不好都会卡吧。

[june4]

性能和查询有没有优化到位有关，和表数据多少关系不大，百亿表优化了照样正常用

[Mrun]

只要索引设置合理，mysql 单表存储几十亿并不是什么很难的事情。

[Mrun]

@Mrun #10

https://mp.weixin.qq.com/s/-6MlsOqZfoPzrHZ3jwL4og

可以看一下这篇文章

[esee]

索引设置合理,没有太多联表操作的话,上亿并没有什么问题,我的数据表已经 4 亿了,也没有性能问题,本来设想的是出现性能瓶颈再分库分表,现在看来完全是想多了。不过我用的阿里的 RDS ，可能硬件性能硬盘的 IO 也是一个很重要的指标。

[xiuming]

用中间件 vitess 之类

[sagaxu]

以前在传统行业的时候，Oracle 单表超过 10 亿的多了去了，那年代没有 SSD ，读写也不慢啊，基本只按 ID 读写，且索引字段不更新

[sagaxu]

不按冷热数据分，只按 ID 取模分，单机分库分表意义何在，B+树从 3 层变 4 层，性能下降一个数量级吗？

[echoless]

@Mrun #11 接近 1 亿的表, 索引就有几十 GB. 这个肯定是要从磁盘读写. 速度不会快的. 交易所要经受频繁读写.

偏读, 和 CRUD 全照顾到, 不是简单 db 优化就可以的. 我感觉 @GeekGao 那个表比较全面. 说几十亿没问题的, 要么偏向读, 要么写和更新速度肯定慢.

[xuanbg]

分表啊，还能怎么办。mysql 处理不了亿级规模的表，虽然开源，但你也没这个能力去优化不是么。

[zhouhuab]

上 TiDB

[BBCCBB]

用的 aws aurora mysql 版本, 单表几亿没任何问题.

[UWH0TdA14ta0s6n9]

加硬件可及

[june4]

@echoless 才几十 GB ？个人 pc 都有几十 GB 内存。至于数据写入，交易所订单量远不能超过 nvme 的写入瓶颈。

[wupher]

面试造火箭，上班拧螺丝

直接买云服务！

[cslive]

先大力出奇迹再说，上 nvme 固态，1tb 内存

[opengps]

回归简单用法，单表过亿并不见得有问题，我还真用过，也有过相关的优化。没想到好几年了这篇文章还能拿来吹一下： https://www.opengps.cn/Blog/View.aspx?id=284

[opengps]

但现在这个时间点，已经有很多更好的方案了，没必要继续去吃透这套思想而继续使用 mysql 干这个业务

[wqhui]

亿级使用有区分度索引的情况下没什么问题，除非做复杂查询，对于大数据的复杂查询就不走 mysql 了，数据同步到合适的地方玩

[sagaxu]

几十 G 的索引拆成 100 个几百 M 的索引，索引文件的大小并没有下降啊，读写 100 个不同的文件还是读 1 个文件不同的区域，对磁盘来说并无区别。单磁盘分表，相当于把索引的第一页，改成人工计算了。

[Felldeadbird]

八股文方式回答。硬件先改成 SSD 。设置好索引，把表复杂度降低，空间换时间。来来去去也就这么多。

另外，楼主可以透露一下面试公司是行业什么水平吗。上来就要做交易所。他们是缺人吗？

[jonsmith]

有索引，内存够大就没问题。

[Mrun]

@echoless #14

并不会，我手上就有几十亿的表，QPS 4000+没啥大压力，更高的没测过

[8355]

能问出这种问题的人一定没有实践过。。。问题本身过于开放，聊 2 个小时可以不重样。
他根本预设不出来一个具体的性能问题，只是感觉会有问题实际并不会有。
以现在硬件来说并不难达到，成本也不高，上云就更简单了。
解决方案根据不同的业务场景有很多，单纯 crud 不写垃圾 sql 没什么跑不动。

[ElmerZhang]

先回问，这个上亿的表存的到底是什么东西，CRUD 分别都是什么样的场景，再根据情况具体设计优化方案。

[Caratpine]

不说业务场景，单说 MySQL 处理亿级别的数据，你该更新更新你的知识库了，现在的硬件处理亿级别数据真是绰绰有余

[winglight2016]

@BBCCBB #19 我们也用了 aurora ，实测下来性能比阿里的 polardb 要差一点，目前只有几千万数据，很担心上亿之后性能更慢。你们的数据库上到几核了？

[ala2008]

数据量这么大的表，备份和同步是不是可以考考

[echoless]

@Felldeadbird #28 面的是虚拟币交易所 想弄个 team 做 LLM, 提出这个问题的是最后一个交叉面的面试官(个人感觉还是有水平的,应该是做交易所业务的一个 leader, 问的问题有些比较刁钻, 但也不让人不舒服) 薪水 35kx14 还算可以, 这家做交易所确实还比较知名.

[echoless]

@8355 #31 以我的感觉这个面试官真的做过.他们就是做交易所的, 而且看起来是面试我的人中水平最高的.

我接触过股票交易, 感觉要做出那种支持高频的交易所软件 并不容易(大部分都是定制的系统).

潜意识觉得搞不定, 就懵掉了. 我觉得 GeekGao 那张图比较好. 面试官可能也就是考系统思维能力. 只要每一层说上一两句 应该就合格了.

[salmon5]

数据库八股文，属于最简单的，因为它比较标准化的东西，有 3-5 年经验就完全掌握。

[salmon5]

一般的公司里。

[echoless]

@salmon5 惭愧 没有做过的东西 我一般答不好

[echoless]

@opengps #24 你这个厉害, 我看过 redshift 的文档, 有一个模式就是你这样做的.

[prodcd]

@echoless 可能我这表有点特殊吧，都是传感器采集回来的数据，insert 就是正常插入，没什么特别的。基本也没 update 操作，所以连 id 字段都没用。根据传感器 id 创建的索引，查询速度基本都是 10ms 以内。

[aino]

上亿数据，业务场景很重要，不同场景不同因对方式，我现在单表上亿数据，我就只做分页查询展示出来，表引擎用的 MyISAM 就好了，查询的字段建立索引就行了，服务器 2 核 8G 的

[wogogoing]

@awalkingman 哈哈 暴躁老哥，在线怼人

[BBCCBB]

@winglight2016 忘了是 core 8 还是 core 16

[echoless]

@wogogoing #44 大家上网都是吃饱没事做的, 怼怼能缓解一下压力也好

[wogogoing]

@echoless 之前公司业务数据分析这块，有涉及到上亿数据，当时我记得有张表是日 GB 级别的增加。因为是属于日志分析类，所以后面在分区的基础上按日拆分表作为基础数据表，然后生成二级、三级表为最终报表的数据作支撑。

[scyuns]

厉害 我可以用 mongodb 不

[vopsoft]

@sagaxu #14 你说的对 不光 Oracle sqlserver 上亿数据 连索引不用 就能秒查

[Mrun]

@echoless #37

你可以看看我 11 楼发的，再大的数据，mysql B-Tree 的层高也不会超过 5 层，如果几十亿的数据只是简单查询的话，并不会有什么很大的问题。回归你的面试问题，他的场景如果是交易所，就要问清楚业务场景了，复杂查询和简单查询快递不一样。比如交易订单，如果只有 订单号的 where 查询，十几亿都不会有什么大问题，如果有各种筛选条件，那肯定不行

[weiqk]

交易所看着吓人，业务简单，也没多少数据
有人报价时触发撮合下，报价记录队列去存储，撮合记录也队列去存储，就算队列存储延时五分钟也没关系
撮合过程在内存中，上海证券那么牛逼一分钟也没有 100 万笔报价吧，这个数据量对大家来说还不是小儿科
正规交易所就连很有限的会员单位（券商）连接数也很少

[julyclyde]

交易所其实和关系型数据库差异很大
撮合系统其实是按价格排序然后再按时间排序的二维链表吧

[wenxueywx]

B-tree 高度的问题，无非就是会增加读磁盘的 io 次数。在十年前磁盘还普遍是机械盘的时候是个大问题，现在都上 SSD 了，B-Tree 高度已经不是什么问题了。十年前一般建议 MySQL 单表不要超过 2 千万行，就是因为想要把 B-Tree 高度控制在 3 以下，为此有了很多 sharding 方案；现在索引设计的好，MySQL 处理大几千万到亿级都很快。

[steelshadow39]

@sagaxu #15 想请教一下，一般 B+树三层存 2000W 左右。多一层多一次 IO ，性能下降会特别明显吗？

[sagaxu]

@steelshadow39

IO 延迟，
文件系统缓存(内存)，~100ns
SSD ，~100us
万转 HDD, ~5ms