› MySQL 5.5 Community Server
› MySQL 5.6 Community Server
› Percona Configuration Wizard
› XtraBackup 搭建主从复制
Great Sites on MySQL
› Percona
› MySQL Performance Blog
› Severalnines
推荐管理工具
› Sequel Pro
› phpMyAdmin
推荐书目
› MySQL Cookbook
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
这是一个创建于 115 天前的主题，其中的信息可能已经有所发展或是发生改变。
面试的时候被问到这个.
面试官的问题是要设计一个交易所, 支持亿级别的 CRUD.
我被问住了, 我的有限经验 Postgres 接近过了亿级别, 就很有点慢了.
当时一直找不到好的解决办法.
我就说要 sharding 一下, 分库分表实际上也是 sharding 的思维.
55 条回复 • 2024-09-11 11:54:55 +08:00
 |
1
awalkingman 115 天前  31
上来就要设计一个交易所，亿你麻痹亿亿亿。
|
 |
2
prodcd 115 天前 2
我这有个 MySQL 表，结构比较简单，类似 key/value 结构，再加个 datetime 用来分区，7 亿数据量，查询带着 datetime ，速度没任何问题。感觉只要能将查询落到分区里，速度不会有什么明显变化。
|
 |
3
luoyou1014 115 天前 1
表结构尽量简单，确保查询要走到索引，复杂查询拆开，便于优化，上 SSD ，读写分离，可以支撑到 10 亿级别数据
再往上可以用分区功能，我的经验只到 20 亿级别，没有开分区，也扛住了。 |
 |
4
echoless OP @awalkingman #1 这个没办法, 面试官问,我没接触过, 给问懵了.
|
 |
6
GeekGao 115 天前 4
就这些主要的
 |
 |
8
esile 115 天前 via Android
MongoDB 高过 10 亿的，MySQL 百万级别优化不好都会卡吧。
|
 |
9
june4 115 天前 1
性能和查询有没有优化到位有关，和表数据多少关系不大，百亿表优化了照样正常用
|
 |
10
Mrun 115 天前
只要索引设置合理，mysql 单表存储几十亿并不是什么很难的事情。
|
|
11
Mrun 115 天前
|
 |
12
esee 115 天前
索引设置合理,没有太多联表操作的话,上亿并没有什么问题,我的数据表已经 4 亿了,也没有性能问题,本来设想的是出现性能瓶颈再分库分表,现在看来完全是想多了。不过我用的阿里的 RDS ，可能硬件性能硬盘的 IO 也是一个很重要的指标。
|
 |
13
xiuming 115 天前
用中间件 vitess 之类
|
 |
14
sagaxu 115 天前
以前在传统行业的时候，Oracle 单表超过 10 亿的多了去了，那年代没有 SSD ，读写也不慢啊，基本只按 ID 读写，且索引字段不更新
|
|
15
sagaxu 115 天前
不按冷热数据分，只按 ID 取模分，单机分库分表意义何在，B+树从 3 层变 4 层，性能下降一个数量级吗？
|
|
16
echoless OP |
 |
17
xuanbg 115 天前
分表啊，还能怎么办。mysql 处理不了亿级规模的表，虽然开源，但你也没这个能力去优化不是么。
|
 |
18
zhouhuab 115 天前
上 TiDB
|
 |
19
BBCCBB 115 天前
用的 aws aurora mysql 版本, 单表几亿没任何问题.
|
 |
20
UWH0TdA14ta0s6n9 115 天前 via Android
加硬件可及
|
 |
22
wupher 115 天前
面试造火箭，上班拧螺丝
直接买云服务！ |
 |
23
cslive 115 天前
先大力出奇迹再说，上 nvme 固态，1tb 内存
|
 |
24
opengps 115 天前 1
回归简单用法，单表过亿并不见得有问题，我还真用过，也有过相关的优化。没想到好几年了这篇文章还能拿来吹一下： https://www.opengps.cn/Blog/View.aspx?id=284
|
|
25
opengps 115 天前
但现在这个时间点，已经有很多更好的方案了，没必要继续去吃透这套思想而继续使用 mysql 干这个业务
|
 |
26
wqhui 115 天前
亿级使用有区分度索引的情况下没什么问题，除非做复杂查询，对于大数据的复杂查询就不走 mysql 了，数据同步到合适的地方玩
|
|
27
sagaxu 115 天前
几十 G 的索引拆成 100 个几百 M 的索引，索引文件的大小并没有下降啊，读写 100 个不同的文件还是读 1 个文件不同的区域，对磁盘来说并无区别。单磁盘分表，相当于把索引的第一页，改成人工计算了。
|
 |
28
Felldeadbird 115 天前
八股文方式回答。硬件先改成 SSD 。设置好索引，把表复杂度降低，空间换时间。来来去去也就这么多。
另外，楼主可以透露一下面试公司是行业什么水平吗。上来就要做交易所。他们是缺人吗？ |
 |
29
jonsmith 114 天前 via Android
有索引，内存够大就没问题。
|
 |
31
8355 114 天前
能问出这种问题的人一定没有实践过。。。问题本身过于开放，聊 2 个小时可以不重样。
他根本预设不出来一个具体的性能问题，只是感觉会有问题实际并不会有。 以现在硬件来说并不难达到，成本也不高，上云就更简单了。 解决方案根据不同的业务场景有很多，单纯 crud 不写垃圾 sql 没什么跑不动。 |
 |
32
ElmerZhang 114 天前
先回问，这个上亿的表存的到底是什么东西，CRUD 分别都是什么样的场景，再根据情况具体设计优化方案。
|
 |
33
Caratpine 114 天前
不说业务场景，单说 MySQL 处理亿级别的数据，你该更新更新你的知识库了，现在的硬件处理亿级别数据真是绰绰有余
|
 |
34
winglight2016 114 天前
@BBCCBB #19 我们也用了 aurora ，实测下来性能比阿里的 polardb 要差一点，目前只有几千万数据，很担心上亿之后性能更慢。你们的数据库上到几核了？
|
 |
35
ala2008 114 天前
数据量这么大的表，备份和同步是不是可以考考
|
|
36
echoless OP 1
@Felldeadbird #28 面的是虚拟币交易所 想弄个 team 做 LLM, 提出这个问题的是最后一个交叉面的面试官(个人感觉还是有水平的,应该是做交易所业务的一个 leader, 问的问题有些比较刁钻, 但也不让人不舒服) 薪水 35kx14 还算可以, 这家做交易所确实还比较知名.
|
|
37
echoless OP @8355 #31 以我的感觉这个面试官真的做过.他们就是做交易所的, 而且看起来是面试我的人中水平最高的.
我接触过股票交易, 感觉要做出那种支持高频的交易所软件 并不容易(大部分都是定制的系统). 潜意识觉得搞不定, 就懵掉了. 我觉得 GeekGao 那张图比较好. 面试官可能也就是考系统思维能力. 只要每一层说上一两句 应该就合格了. |
 |
38
salmon5 114 天前
数据库八股文，属于最简单的，因为它比较标准化的东西，有 3-5 年经验就完全掌握。
|
|
39
salmon5 114 天前
一般的公司里。
|
|
42
prodcd 114 天前 1
@echoless 可能我这表有点特殊吧，都是传感器采集回来的数据，insert 就是正常插入，没什么特别的。基本也没 update 操作，所以连 id 字段都没用。根据传感器 id 创建的索引，查询速度基本都是 10ms 以内。
|
 |
43
aino 114 天前
上亿数据，业务场景很重要，不同场景不同因对方式，我现在单表上亿数据，我就只做分页查询展示出来，表引擎用的 MyISAM 就好了，查询的字段建立索引就行了，服务器 2 核 8G 的
|
 |
44
wogogoing 114 天前
@awalkingman 哈哈 暴躁老哥，在线怼人
|
|
45
BBCCBB 114 天前
@winglight2016 忘了是 core 8 还是 core 16
|
|
47
wogogoing 114 天前
@echoless 之前公司业务数据分析这块，有涉及到上亿数据，当时我记得有张表是日 GB 级别的增加。因为是属于日志分析类，所以后面在分区的基础上按日拆分表作为基础数据表，然后生成二级、三级表为最终报表的数据作支撑。
|
 |
48
scyuns 114 天前
厉害 我可以用 mongodb 不
|
|
50
Mrun 114 天前 1
@echoless #37
你可以看看我 11 楼发的，再大的数据，mysql B-Tree 的层高也不会超过 5 层，如果几十亿的数据只是简单查询的话，并不会有什么很大的问题。回归你的面试问题，他的场景如果是交易所，就要问清楚业务场景了，复杂查询和简单查询快递不一样。比如交易订单，如果只有 订单号的 where 查询，十几亿都不会有什么大问题，如果有各种筛选条件，那肯定不行 |
 |
51
UFc8704I4Bv63gy2 114 天前
交易所看着吓人，业务简单，也没多少数据
有人报价时触发撮合下，报价记录队列去存储，撮合记录也队列去存储，就算队列存储延时五分钟也没关系 撮合过程在内存中，上海证券那么牛逼一分钟也没有 100 万笔报价吧，这个数据量对大家来说还不是小儿科 正规交易所就连很有限的会员单位（券商）连接数也很少 |
 |
52
julyclyde 113 天前
交易所其实和关系型数据库差异很大
撮合系统其实是按价格排序然后再按时间排序的二维链表吧 |
 |
53
wenxueywx 112 天前 1
B-tree 高度的问题，无非就是会增加读磁盘的 io 次数。在十年前磁盘还普遍是机械盘的时候是个大问题，现在都上 SSD 了，B-Tree 高度已经不是什么问题了。十年前一般建议 MySQL 单表不要超过 2 千万行，就是因为想要把 B-Tree 高度控制在 3 以下，为此有了很多 sharding 方案；现在索引设计的好，MySQL 处理大几千万到亿级都很快。
|
 |
54
steelshadow39 107 天前
@sagaxu #15 想请教一下，一般 B+树三层存 2000W 左右。多一层多一次 IO ，性能下降会特别明显吗？
|
|
55
sagaxu 107 天前 1
|
Select Language