释放数据价值，助力数智转型，本次腾讯全球数字生态大会数据库专场中，各路大咖为我们带来腾讯云数据库的最新动态：全域解决方案、TDSQL新品发布、合作伙伴计划……以下是搜狐畅游数据库团队的负责人李凌在大会分享的图文和视频回顾，请查收~
关注“腾讯云数据库”公众号，回复“畅游”，即可下载直播分享PPT。
各位嘉宾大家好，我是来自畅游的数据库团队负责人——李凌，很高兴在这里与大家分享畅游腾讯云数据库的使用经验。
畅游是一家全球化的游戏公司，5年前，畅游选择了腾讯云作为畅游全球云产品供应商之一，而这5年来，腾讯云一直为畅游提供优质高效的公有云和混合云服务，目前畅游绝大多数业务已经从自建IDC迁移到了云上。
在此，我从三个方面分享畅游在腾讯云数据库方面的使用经验，这三个方面分别是：高效的数据库快速恢复，智能化、可视化的数据库优化管理和稳定可靠的全球网络加速。
对于任何一家公司来讲，核心数据的安全是重中之重，在畅游数据库云化的过程中，对于数据库，我们除了兼容性和性能之外会优先去了解的功能就是数据恢复，而腾讯云的数据恢复我们进行了完整的测试，测试的结果也相当让我们满意。畅游之前的备份系统是使用官方原生的mysqldump binlog 进行逻辑备份和恢复，出现故障需要恢复数据的情况是：平均数据的恢复时间在两到三个小时左右。
而在我们改用腾讯云定制过的数据库恢复系统的时候，经过我们的测试可以发现，全量数据恢复的平均时间会较之前缩短2/3，另外，让我们比较惊喜的是腾讯云控制台界面提供了三个等级的恢复服务，其中就包含了基于表级别的数据库极速恢复功能。畅游有部分业务在上云之前，为了提高恢复速度进行了核心表的独立备份，而现在这个功能腾讯云数据库备份系统替我们实现了，这个系统进一步节省了我们的维护成本，在整个系统使用的过程中我们其实也踩了不少坑，也攒了不少经验，在这里与大家分享：
第一点非常重要，我们目前的恢复系统的版本只支持原库回档，所以在回档的期间它对原库是有IO消耗的，但是它没有对原表加锁，所以大家千万要注意在不停机回档的时候一定是要先去看原库的压力有多大，在压力较大的时候极有可能造成数据库的访问异常。通常作为游戏数据库的使用方，我们都会先挂维护页，之后再进行数据库回档的操作，这样会更安全。
第二点，经常会有同学问我：为什么我现在回档失败了？我之前想要回档的表不见了？其实很简单，如果原表被drop掉了，那么恢复的时候就需要创建原表结构才可以继续恢复。
第三点，其实在云时代很多公司依托于云并没有专业的DBA，而我作为一个资深的DBA想要提醒大家一句，作为数据的管理者，在数据恢复之前请保留现场，这是一个研发同学非常容易忽略的问题。如果现场恢复坏了，你没有保留现场，那你就没有选择。相比之下，腾讯云备份系统提供了三种回档模式，第一是普通模式，它是一个全库的冷备，全实例的冷备加上binlog恢复这个是使用范围最广而没有任何限制的模式；第二种是快速模式，它可以提供库级别的数据恢复，这边有一个要求就是在恢复过程中有关联库操作的话就要选择关联库一同恢复；第三个是极速模式，也是我们用的最多的模式，它限制会更小，如果核心表之外的表在同一个事务中被更新，那你在恢复的时候就需要把这张核心表之外的表同样勾选。
最后一点，腾讯云数据库虽然提供的功能比较完善，恢复的功能也相对完善了，但大家在操作之前，尤其是在第一次操作之前一定要仔细看完相关的帮助文档，帮助文档上会很明确的说明各种恢复模式的限制。而这张PPT上的第三部分就是文档当中的截取。
现在我们来讲第二个部分——智能化的数据库管家DBbrain，我上面写了5倍的工作效率提升，提升在哪里？
第一来自于日常排障，它能很快地把你的排障效率提升上来；第二它可以指导初级同学排障；第三就是我们有大量的时间，在上线前都会与研发进行沟通数据库优化的问题。而我们将DBbrain这个产品下放给研发使用，它能大幅的降低我们与研发的沟通成本，研发也可以自助进行数据库优化。
畅游是第一批使用DBbrain的公司之一，在邀测和公测期间我们也和DBbrain的产品同学进行了深入的交流与探讨，DBbrain这个产品是可以增强数据库稳定性的。
我举个例子来说，首先它是一个7×24小时的实时采集系统和实时分析系统；第二点，它是可以提高管理效率的，每次管理大家都不需要再去登陆本机，而是通过DBbrain可以做集中管理，特别是集中的数据库优化的分析；第三点，有部分功能在DBbrain中变成了一键式的操作，大量节省了运维成本；第四点，所有在DBbrain中的操作都是可审计的，也就是说安全性是有保证的。
我们畅游的应用场景有五大类：第一类是可视化的慢查询线程，包括删除和清理，第二类是快速定位性能问题，第三类就是刚才说到的研发自主优化，第四类就是日常巡检，包括我们的日检、月检、进度巡检和年检，最后就是它提供的完善的性能分析报告，每一个研发同学，都有可能在迭代代码之后去看性能分析报告来确认代码中的SQL是否有问题。
下面这张图是数据库智能管家DBbrain的一张官方架构图，我们从架构图上去分析，它是一个流式数据处理、实时数据监控和实时数据分析的产品，这是我们所看重和愿意去尝试的关键点之一。它不光会采集异常时段的数据，还会采集正常时段的数据，并在危险发生之前给予提示——这比发生了危险再处理更有效。
我们看一下常用功能，第一个是KILL会话，其实在这里面，大家可以很明确的看到只需要勾选你觉得异常的会话，然后点击KILL会话，就可以清理掉你觉得有异常的问题，让数据库暂时恢复正常。并且在更新的版本中，如CDB5.7中它提供了SQL限流功能，还有热点的更新保护功能。这些畅游还没有开始尝试，但是是未来发展的方向。
我们看一下我们传统定位数据库问题，如果发现了服务异常，我们怎么能判定是数据库的问题呢？传统的做法是罗列所有的指标然后解析我们现在数据库出现的慢SQL，然后综合准备优化方案，最后处理。DBbrain是怎么处理的？
第一，它不需要罗列指标去做人为的分析，它已经有过了分析模板，有持续的分析和处理建议的提供整体的流程,较比人工分析更快;第二,它提供了优化建议,这个建议可以供大家参考,特别是供初级的同学参考;第三 它也提供了快速处理的预案:有建议也有有解决方案。
我们另外一个常用功能是慢查询分析，大家用过传统的标准MySQL数据库都知道，在开源版的标准MySQL数据库是不提供图形化界面的，而DBbrain提供了一个可视化的、一目了然的问题分析界面和平台并提供了建议，那么我们在使用这个的过程中，其实发现了一些小的需要大家注意的点：
第一个点是慢查询的默认阈值，在腾讯云数据库实例中定义为10秒，这个是在数据库参数设定中设置的，大家可以根据自己任务情况去调整。通常我们畅游来说都会设置在1秒以内。第二点：优化建议的准确率在80%左右，因此综合实际情况来判断是非常重要的一件事情。第三点：加索引要慎重，虽然DBbrain会为你提供合理的优化建议，但这个建议涉及到删添索引的时候一定要慎重，每一个索引的处理都可能对线上造成锁死并影响线上的查询和写入的性能，这个需要有一定的专业知识。
下面这张图是DBbrain的一个单机巡检报告，它从六个纬度去看了数据库六个纬度的性能，并出了一个评分值，接着把它认为有问题的地方写下来。我们这个报告通常会提供给研发同学来参考每次上线和每次测试的时候数据库的问题。
同样这样一份报告给DBA拿到手，DBA也可以通过它来优化现有的服务。看报告的好处就是说至少我们能更近和更早一步地发现故障和解决它。
最后一个功能是数据库巡检，我为什么会把这一页单独拿出来说？大多数公司的同学
都会有这个经历，每到年底了、季度末了都会对现有的数据库做一次完整的巡检。那么现在不需要大家自己写程序做了，DBbrain会帮你做，而且它提供了导出功能：导成excel大家可以做数据分析，这也是一个非常实用的功能。
下面我们来说一下Anycast在数据库领域的应用，通常Anycast这个产品畅游是用来做全球同服的，随着畅游海外业务的大发展，全球同服业务也在畅游开始上马。
以某个海外业务为例，主要对香港、日、韩和北美洲发行，其实我们知道，海外用户根据你的游戏类型不同会聚集在北美和日韩，我们多次分析和论证玩家的分布和各地网络的情况，最终将该项目的游戏服部署在了美国西部（以下简称美西），日、韩和香港的玩家通过anycast加速连到美西，玩家实际的登录速度延时在200毫秒左右完全能满足玩家的游戏体验需求。对我们来说节省了大量在日韩部署的硬件资源成本。
数据汇聚在了美西，这是一个最常用的应用，数据会通过Anycast的加速通道从美西压缩之后回传到国内的畅游数据中心进行分析，这看起来可能跟数据库关系不大，但我们说一下这个应用的延伸：我们从北美数据中心到畅游北京数据中心之前是通过压缩包传输数据，最开始是通过公网来传输数据的，畅游的北美数据中心走公网传输到畅游北京数据中心通常的延时会在300毫秒以上，而且稳定性基本上没有保证。当我们在应用了Anycast加速之后，畅游的数据传输时延从300毫秒降低到150到200毫秒之间，而且由于Anycast是多通道的加速，当某一个通道出现问题的时候会有备用通道顶上，在真实业务的使用当中目前还未遇到过长时间断网的情况。
我们在这上面发现，其实Anycast的通道就是对TCP通道的连接做了一次腾讯云内网的加速而走腾讯云内网的国际专线来提高我们访问的稳定性。在畅游数据库团队看到了这一点，北美数据中心到北京数据中心的所有的数据库的数据同步也同样使用了Anycast进行加速，我们也取得了比较好的效果。
以上三个功能是畅游数据库团队在使用中比较在意的三个功能，能在基础的数据库稳定性之外还为数据库服务附加了更多在安全性和易用性上的价值，希望本次分享能让大家有所收获，谢谢！
特惠体验云数据库
↓↓更多惊喜优惠请点这儿~
