柴司的办公室，就设在北京五环外一座漠然处之的写字楼里。在归并楼层里开云官网切尔西赞助商，还有其他十几家不异迷你的团队，包括几家电商公司。咱们天天齐能看到他们打包、点货。

电商的每一笔订单，齐触及到客户的个东说念主信息，家具信息，订单信息，库存情况，物流信息等等，最终汇总成一个弘大的数据库。从客户下单，到发货、进货，分析营销扩充计策等 ..... 齐备要围绕着这个数据库来。

尤其在双 11、黑五这样的营销季，订单暴涨，数据库的一个故障，亏损的便是实实在在的贫穷钱。

但当多年积聚的数据摆在眼前的时候，到底应该如何料理、查询？难说念用 Excel 吗？

为了演示这个问题，咱们真是生成了100 万条数据，并趁着华为云数据库双 11 的举止，看救济理 100 万条数据是如何一种体验？

   视频版

↓↓ 看完这个视频就知说念了 ↓↓

↑↑ 信我，真是超等好意思瞻念   ↑↑

   图文版

最初，天然不可用 Excel.....

不年少企业在订单数小，历史数据未几的时候，会用土产货数据库。毛糙来说，便是我方买做事器硬件，使用 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 剧本成立好了数据，是以进入数据料理做事界面之后，能平直启动查询。

咱们先望望往时一个月内注册的用户，热热身：

服从耗时1ms......

那么擢升一下难度：咱们思望望每个用户的购物总破费，并按照从高到低的规定给他们排序，以便于后续给土豪推浪掷，那不错使用团员函数来查询：

你猜猜此次要多久？

谜底是 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 搭建。

从这个意旨上来说，每家小公司，齐高度依赖一个健全、完善的生意基础要领体系。高速的互联网、浅薄的物流、平素笼罩的通信、合营器用，以及咱们今天先容的，踏实、易用、可靠的云做事等等加在沿途，才共同组成了这一基础要领。

它们就像水和电一样，略显无聊，容易被薄情，但却的确地支抓了无数企业和职工的发展与成长。但愿中国畴昔的生意基础要领能越筑越牢。

下期见！