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

[echoless]

面试的时候被问到这个.

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

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

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

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

[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