柴司的办公室，就设在北京五环外一座普普通通的写字楼里。在同一楼层里，还有其他十几家同样迷你的团队，包括几家电商公司。我们天天都能看到他们打包、点货。
电商的每一笔订单，都涉及到客户的个人信息，产品信息，订单信息，库存情况，物流信息等等，最终汇总成一个庞大的数据库。从客户下单，到发货、进货，分析营销推广策略等.....全都要围绕着这个数据库来。
尤其在双11、黑五这样的营销季，订单暴涨，数据库的一个故障，损失的就是实实在在的辛苦钱。
但当多年积累的数据摆在面前的时候，到底应该怎么管理、查询？难道用Excel吗？
为了演示这个问题，我们真的生成了100万条数据，并趁着华为云数据库双11的活动，看看管理100万条数据是怎样一种体验？
视频版
↓↓ 看完这个视频就知道了 ↓↓
↑↑ 信我，真的超级好看 ↑↑
不少小企业在订单数小，历史数据不多的时候，会用本地数据库。简单来说，就是自己买服务器硬件，使用MySQL等数据库软件，花钱请专门的运维人员，从头开始搭建一个数据库系统，并焚香洗手沐浴更衣，祈祷它能7×24小时稳定运行。
数据量小的时候，本地数据库确实可以应付。但一旦遇到双11和跨境电商的“黑五”这样的营销季，业务量暴涨，只要一次故障，就可能让客户刚下的订单，和原本能赚到的钱，直接消失。但如果花钱买更强的硬件，又要看着它们在非高峰期落灰闲置。所以也有一些企业会买虚拟的云服务器，用来建立数据库，也就是大家说的用ECS自建数据库：这相当于把硬件外包了出去，但搭建数据库的成本，包括运维人员的成本，还是得自己负担。哪天运维大哥想喝酒撸串，其他人面对着复杂的数据库页面，只能一脸懵逼。
我们这次用的华为云提供的基于 MySQL 的关系型数据库服务，也就是 RDS for MySQL，来做个测试，看看它的性能有多强。首先，我们要搭一个电商数据库，并生成 100 万条数据。数据库中要有客户表，产品表，订单表，以及付款，物流等等表格。总之，要尽可能模拟一个电商公司的真实运作。
之后，我们创建了一个 Python 脚本，用 Faker 库随机创建了 2 万个虚拟用户，以及15 万条订单，付款和物流数据。在运行之后，数据库中就出现了云南省哈尔滨市的王秀珍，和广西西安市的丁海燕......这不重要，反正这 2 万名随机生成的虚拟用户，只是我们测试道具罢了。产品表里，我们也模拟了售价823.62元的小说，和仅售121块钱的空调等爆款商品。
而且请注意，这些表之间有着复杂的关系：比如订单表里面有customer_id关联到用户表里面的用户id，付款表里有order_id关联到订单表。所以这类数据库才叫“关系型数据库”。在创建完这八张表，一共近100万条数据之后，我们就可以开始试试 RDS for MySQL 到底有几把刷子了。我们使用了华为云现在提供免费试用的单机版8核16G配置，只需要点两下鼠标，选择自己需要的配置就能直创建数据库，既开即用，相比于本地自建服务器的繁流程来说实在太简单了～
因为我们已经用Python脚本设置好了数据，所以进入数据管理服务界面之后，能直接开始查询。
那么提高一下难度：我们想看看每个用户的购物总花费，并按照从高到低的顺序给他们排序，以便于后续给土豪推奢侈品，那可以使用聚合函数来查询：答案是 177ms，对于 RDS for MySQL 来说，依然是没有流一滴汗。
那么我们继续上难度：这次我们想要查询所有客户的最近一次订单以及支付状态，并按照订单的时间顺序，排序返回最近的50名下单客户。这会涉及到多张表的JOIN操作，包括客户表，订单表和付款表：结果我们看整个查询时间也仅仅只有 68ms，依然相当轻松。
那我们再试一些更复杂的业务逻辑：比如我们想查询最近一个月内，每个商品类别的销售总额，以便后续进货。那这次的查询时间是 256ms。
接着我们查询了平均订单金额高于所有订单平均值的客户，还是筛选土豪。这要先计算出所有用户的平均订单金额，然后再从所有用户中筛选出订单金额大于这个数的人。整个查询时间也仅仅只有 37ms。
看起来这些任务实在难不倒 RDS for MySQL，我们让测试同学施展毕生所学，来点狠的考验。我们想根据消费总额，先找出最有钱的前 10 名客户，并定位他们最常购买的产品类别，方便后续针对性地服务好大客户。那这个查询会涉及多张表大量的JOIN操作。结果呢，也只花了 209ms 就完成了查询。
除了照顾大客户，我们还想看看那些已经很久没来下单的非活跃用户。我们可以把最近下单时间超过六个月的客户定义为非活跃客户，然后看看他们和活跃用户相比，对业务的贡献有多大区别。这次的查询时间是 235ms。
在这个拥有接近100万条数据的数据库里，我们用光了关于数据库查询的毕生所学。但所有复杂的查询操作，用时也从来没有超过0.5秒，不服不行。最后我们的测试同学疯狂了：他把之前用的一个查询封装成一个函数，然后连续调用它 100 次，可以看到即便这么复杂的查询连续执行100次，用时也仅有 18 秒， CPU 利用率只有 2% 出头，也就跟我们笔记本电脑待机时的状态差不多。
除了这些查询测试以外，我们也用性能压测工具sysbench对数据库做了测试，这是在设置为64线程的测试结果。这里的TPS代表每秒执行的事务量，QPS代表每秒的查询数量。可以看到平均TPS为677，QPS更是达到1.3万左右，足以看出数据库对于高并发场景的性能优势。
而且，我们这里用的只是试用配置，在华为的数据库性能白皮书里，还列出了不同CPU和内存搭配的性能测试结果，在其测试场景下，TPS和QPS分别能够实现最高6400和12.9万的恐怖成绩。
当然，性能只是云数据库服务的一方面而已。对于数据库服务来说，稳定、安全也至关重要。我们可以在 RDS 的云服务监控详情这里，看到数据库各项的指标监控，并及时收到异常告警。而且还可以根据业务需求，自定义告警规则。而且很多时候，这些告警都用不着你自己来处理：比如担心磁盘空间不足，那可以在实例的页面选择磁盘自动扩容，自动化运维，不用劳烦正在喝酒撸串的运维大哥。
这也是RDS for MySQL 相对于本地数据库的另一种优势：不管是性能，还是存储等不够用，那都可以随时随地根据实际需求变更扩容，成本低，弹性强。此外，华为云RDS for MySQL还采取了多部署架构和容灾方案，确保数据库随时可用、且可恢复到任意时间节点。你可以通过自动备份功能，方便地备份和恢复数据，不用担心数据丢失带来意外损失。所以相比于自建数据库来说，RDS for MySQL 提供的不光是更强的性能，还有更弹性、稳定、省心的体验。
当然，一些小团队可能觉得 RDS for MySQL 这么强的性能目前还用不上。那可以考虑更轻量级的 Flexus 云数据库RDS：它同样提供了开箱即用的体验，也支持数据扩容，备份等功能。性价比很高，很适合中小企业与个人开发者。我们也帮你体验过了，它在性能也很够用。而且可以无缝升级到标准版RDS for MySQL，不用担心未来业务增长之后出现瓶颈——这一点很重要，虽然我们是小团队，但出来混，谁还不怀着一个做大做强的梦想呢？如果你有需要的话，可以看看华为双11期间的云数据库专场，赶一波新客专享优惠。
最后，同样作为一家小团队，我们深知大家都面对着类似的问题：我们财力和人手有限，只能把资源集中在主业上。其他的事情，最好能交给简单、高效、稳定、性价比高的外部服务来解决。而不是投入大量成本，慢慢摸索，从0搭建。从这个意义上来说，每家小公司，都高度依赖一个健全、完善的商业基础设施体系。高速的互联网、便捷的物流、广泛覆盖的通讯、协作工具，以及我们今天介绍的，稳定、易用、可靠的云服务等等加在一起，才共同构成了这一基础设施。它们就像水和电一样，略显枯燥，容易被忽视，但却真实地支持了无数企业和员工的发展与成长。希望中国未来的商业基础设施能越筑越牢。