peter置顶2022-10-25 来自北京请教老师几个问题： Q1：MySQL一个表最大记录是2000万吗？ 多个地方看到一种说法：MySQL的表，记录数不要超过两千万，根据是什么？经验值吗？还是和MySQL的底层结构有关？ Q2：亿级用户是分表吗？ 比如微信，十亿用户，要分成多个表吗？分的话，一般根据什么分？作者回复: 你好，peter，感谢你的留言～由于问题比较多，我只能简略回答一下，后续我们的课程内容也会有相关的内容 Q1：MySQL innoDB的2000w性能下降的说法，不一定准确，这个数字和单条数据大小以及数据量有直接关系，我们的数据是行存储并且和聚簇索引在一起，并且查询索引是B+Tree，如果这个服务用途不是马上要求返回结果，也是能用的，只不过响应变得缓慢了，但是大部分我们对外服务对响应速度和并发是有要求的。缓慢原因是我们的MySQL的索引是整棵树完整结构，并且我们的实际数据都在最深处保存，如果树深度过深（比如超过3层），查询时和回表时相应的我们查询对比的次数和io会变多，这会直接导致了性能会有下降，能够承担的服务请求量也相应下降，我们用MySQL不推荐这么多的原因核心在于，我们还是想让接口请求能够快速回复查询请求 Q2:我想这个重点在于，业务怎么用这些数据，这决定了我们怎么分表，我们分表的目的主要是为了提高响应速度，我的建议是，如果是存储可以按取值范围拆分，这样可以简单做二分法查找确定数据服务在哪里，如果是用来对用户查询，那么在他的上层加上多层的缓存分片，类似LevelDB的层级，被查询的时候可以回源，当然这个是适合读多写少的场景，如果是其他场景，需要另外设计对应的方式，这些方式在后面都有介绍，敬请期待 你的问题很有趣，期待你的下次留言！
共 6 条评论10
移横为固2022-11-03 来自北京思考题：一开始觉得注册邀请表应该作为历史表. 思考了下作为关系表也是可以的 在满足下面的注册邀请前提下： 1.邀请人用类似二维码分享方式，注册人主动扫码注册。（不使用点对点邀请，被邀请人可能不接受） 2.只能注册成功一次 这样每一条邀请记录都是一个用户的注册记录：可以定义如下字段 （邀请者，注册人，注册时间，邀请方式） 表的字段结构都非常简单，记录的总量最多就是账号量，并不会随时间不断膨胀。因此可以胜任关系表的查询需求。作者回复: 你好，移横为固，很高兴收到你的思考，你的回答和我当时想法很一致，我们做项目会碰到很多类似的情况，需要我们去预防超出预期的操作。 简单的说就是：我们怎么约束用的人，以及我们怎么用这个数据。
共 7 条评论6
业余草2022-10-25 来自北京https://static001.geekbang.org/horde/8c/8c13453d81da3149b58334b4625d2788.jpeg 这里放一张我在部落里发的图。用户邀请其他用户注册的记录，属于历史记录还是关系记录，主要取决于业务结构。我推荐使用历史记录作者回复: 你好，业余草，感谢你的分享，当我们需要查询这个用户的邀请人时，还需要查询这个表，那么和我们对表的职能拆分有一定冲突，那么如何改进这个实现呢
4
人无远虑，必有近忧2022-10-25 来自北京感谢老师，获益匪浅值得学习！作者回复: 你好，感谢你的支持！学习过程中有任何问题，欢迎提出，多多交流
3
rts2023-02-11 来自广西可以分一个关系表和一个历史记录表，关系表存放邀请成功的关系，历史记录表存放邀请动作的一些详情。作者回复: 你好，确实这么做更好
2
拾掇拾掇2022-10-24 来自北京邀请很像转介绍业务，所以应该是历史记录作者回复: 你好，拾掇拾掇，感谢你的留言，在使用中，如果我们想查询这个人的邀请人，这个表还是会被业务查询，那么如何设计改进呢？
2
Daniel2022-10-24 来自北京我认为是“历史记录”， 因为在统计一个用户一共邀请了多少个人的时候，是需要在总体的邀请人数中去筛选这部分人，而总共邀请的人数会是一个动态不断增长的数字。 老师，我想请问一下，在什么业务场景下(是不是历史记录的表信息就可以用非关系型数据库来处理），可以考虑把关系型数据库的数据转移到类似于mongoDB这类Nosql类型的数据库，而不是用缓存来处理呢，二者选取的关键因素有哪些?作者回复: mongoDB是一个很有趣的数据库，很多设计开创了行业先河，但有几个老版本因为全局锁问题导致使用的时候，需要慎重，因为这个锁在并发高的时候加服务器也不能提升性能，后续的版本我没有太关注。 建议在选择的时候能够压测验证下现状来确认是否给不确定用户流量的系统使用，即使使用也建议对他加一层缓存。 至于历史记录是否选择mongodb，主要看我们的业务场景，如果是给大量用户使用不推荐，如果是我们存起来用来做数据分析，并且不会有大量流量的话可以使用。核心在于是否能够高可用，它的性能是否符合我们场景需要，是否满足我们的业务需要。
2- zmlmagic2023-02-14 来自内蒙古历史记录表，关系查询再建专门关系表
作者回复: 没毛病
1 - 刘章2022-11-30 来自北京老师你好： 我们现在用的是一主多从的数据库，设置了读写分离，写是 主库， 读是从库。 有时间会出现一些莫名问题，就是同步延迟问题，明明是修改完成了，但是读取不到就会是程序出现问题，这个有什么好的办法吗
作者回复: 你好，刘章，可以用MySQL proxy一类的中间件自动确认数据情况切换主从，如果是云服务，像阿里云的polardb可以在代理设置强一致。如果都没有可以业务上优先更新缓存，优先读缓存数据
共 2 条评论1 
一步2022-10-30 来自北京邀请注册记录：如果 历史表个关系表（关系表中保存 邀请人ID, 邀请历史记录 ID)同时保存呢？ 一般邀请统计的业务，会要求看到邀请的具体统计信息，比如：每天的邀请人数，邀请总人数等，这里邀请关系可以放到缓存中; 邀请历史表保存 具体的邀请历史记录，这样就可以通过邀请关系缓存拿到记录id 进而获取到邀请历史记录详情信息作者回复: 你好，一步，很高兴收到你的心得，邀请关系放缓存是个好办法，建议表也拆一下，然后查找历史详情这样感觉会更方便一些～
1