MySQL数据库优化方案二

• 建立初步的监控、分析体系(为后续优化提供数据支撑)
• 业务性能优化(部分业务可能会考虑更换存储的数据库)
• 数据库读写分离
• 转移或清理部分无用的数据，保证数据库存储的都是必要的数据(具体是直接删除还是转移到其他数据库，需要与产品运营协商)
• 异步写数据库(实时性要求不高的数据)

(需要利用具体的数据来提现本方案实施之后性能提升的幅度，具体需要哪些数据指标在后续更详细的方案中确定好)

原理

方案设计

• 从之前的数据来看，目前大部分服务的访问量还是可以支撑当前的业务。 例如9月1号，活跃玩家22w，平台和游戏并没有出现访问很慢的情况。之前几次出现问题的都是集中在部分业务逻辑上(例如：获奖、抽奖、助力部分操作)

• 底层数据库性能的提升，并不一定能够很好的解决部分业务逻辑慢的问题。 例如抽奖服务，如果依赖MySQL数据库锁，即使数据库性能翻倍，抽奖服务也不一定可以翻倍，但是如果利用其他数据库或者其他方式，就可以把性能提升很多

• MySQL近一周慢日志里有70%以上是select查询语句(列举出这些sql语句慢的原因)

结构图

• MySQL读写分离
• 异步写数据库： 对于部分不是很重要的数据，通过异步(利用消息队列或者缓存)来回写至mysql

主要解决问题

• 短时间内快速提高性能
• 提高数据库读取(读写分离)、写入(异步回写)性能
• 减少数据库存储的数据量(之前也有做过一部分，但是还不够细致和彻底)

实施

• 数据库无用信息清理
• 兼容性测试
• 数据库升级(5.5升级至5.6)
• 启用读写分离
• 排查比较消耗数据库资源的业务，并进行优化

需要考虑的问题

• 数据库升级时间(15:00 - 15:16)，服务可能会中断时间
• 监测和梳理对数据库压力较大的业务
• 异步回写操作需要考虑延迟/重试

优势

• 实现难度适中
• 每个点都可以单独部署
• 本方案与分布式数据库方案不冲突，两者可以并存
• 数据库变更之后，定制平台、游戏的业务逻辑几乎无需修改也可以正常运行

风险

• 数据库升级操作可能会造成业务中断

成本

当前数据库成本

总计：389元/月

• RDS(8核2400M，连接数:600 IOPS:1200) : 389元/月

本方案实施后

389元/月 + 273.6元/月 = 662.6元/月

• 只读实例1核2G(连接数:600 IOPS:1000)： 0.38元/时 x 24 x 30 = 273.6