到此，我们对订单系统的核心接口业务流程有了一定的了解。这时候，我们可以满足一些简单的需求。同时，这时候会有相应的产品经理来满足我们的需求。一般3个月左右，我们就会熟悉单个系统的日常需求。可能我刚进公司的时候，这家初创互联网公司累计只有10万用户，每天2万活跃用户，每天2万单，如下图：按订单数据量计算，只有七到一年八百万单，还是可以轻松拿下的。行业趋势，用户数量骤增带来的问题，但也许我们运气好，刚好遇到移动互联网高速发展的几年。此时，外卖APP的用户规模迅速增长到100万，日活跃用户20万，日订单量20万，订单量也从300万迅速增长到2000万，如图下图：在这三个月里，我们除了做日常需求，还要支持和解决线上问题，所以我们经常查看订单。在查询订单表数据的时候，我们会发现随着订单数据的增加，订单查询sql也会相应的变慢。需要20ms，但是现在，单表增长到2000万，但是查询一般稳定在200ms以下。有一天，我们正沉浸在写代码的时候，领导突然来找我们说：“小萌昨晚发了一个请求，然后今天突然发现我们的订单sql查询超过了3s，肯定是上线的sql“昨天晚上的问题，现在我们单表只有2000万数据，MySQL可以轻松hold住，小萌今天不在公司，你帮忙排查问题，然后优化sql。”想象这样一个场景，当我们打开一个外卖app我想订一份外卖，记得我上周吃的某家外卖还不错，所以我想看看我订的是哪个商家的外卖，然后我想点击在我充满喜悦的历史订单清单上。结果等了3秒订单列表还没有加载。可能我们做厨师的毅力很强，终于等到点单加载完毕，才心满意足的选菜下单。但是这个时候，我们的脑海里会不会出现bgm：“完了，芭比Q完了”，那么这样的查询速度是绝对不能接受的，因为体验极差。回过神来后，我们听了leader的话就接下了任务，立马开始优化sql，但是下一秒我们又遇到了新的问题，就是我们根本就没有优化sql，甚至你都不知道一个MySQL查询到底会经过什么过程，更不用说从哪里开始优化了。对于sql优化的第一步，首先要了解MySQL的一个完整的查询会经过哪些过程，然后有针对性地进行优化。下一篇文章会详细分析MySQL的一次完整查询的过程，大家不要着急，下面我们继续分析现状。偶尔出现流量爆棚，问题进一步放大。根据刚才的分析，百万规模的用户群体下，数据库中一年的订单数据量可能有上亿。一旦订单表中的数据达到这个数量级后，后续订单SQL的性能就开始明显下降。但是，一个容易被我们忽略的场景是，偶尔会出现流量爆表，那么SQL查询慢的问题会被进一步放大，那么哪些场景会导致流量在短时间内爆表呢？其实这样的场景还有很多。比如某天，我们的外卖app做了一些促销活动，或者某天竞品app不幸挂掉了（作为良性竞争的倡导者，我们不应该有这样的想法，Butif，对不对？），在这些场景下，一个大量的流量将在短时间内引爆我们的外卖应用程序。好的，我们假设竞争对手的外卖应用程序出了问题。比如竞争对手的评价系统宕机，导致店铺的评价无法显示。那么这个就严重了，因为有些用户的点餐习惯，就是在点外卖之前先看店家的评价。结果竞品外卖APP的评价系统挂了，导致店铺的评价显示不出来，这些用户可能都会去我们的外卖APP下单。这时候我们外卖APP的流量会瞬间增加好几倍。次。本来这个时候我们的订单表单次查询差不多要3s，现在流量突然变大，会导致存在的问题进一步放大。比如一个订单查询会直接变成5s。有可能的。所以，如果我们不优化这个场景，我们会流失一些用户，因为我们自己的外卖app这个时候也很卡，我们可能会错过一个“bestsentopportunity”。结语不过，对于这几千万数据的优化，大家大可不必费心，因为接下来，我们将带大家一步步分析这些问题背后的原因，并实施相应的解决方案，大家一定要慎重学习，毕竟机会总是留给有准备的人。
