一、目前数据库背景问题

（一）、数据库CPU总是在50%以上

（二）、磁盘存储空间严重不足，需要经常清理磁盘数据腾出空间

（三）、系统扩容能力不足，如果需要提升处理能力只能更换硬件资源

（四）、系统存储的20TB数据，磁盘使用率达到80%以上，经常报警

（伍）、热数据膨胀（业务变化热数据膨胀较快）、冷数据增长（由于周期拉长）

二、存储架构的演进

在选择一个新的数据库架构应该  基于目前的问题，综合成本、风险、首先等多方面选出最合适的方案。

存在的问题：

1、所有的订单业务都集中在一个数据库上

2、SQL语句复杂，混杂着存储过程

3、很多慢SQL问题

常见的优化方式：

1、索引优化

2、读写分离

3、降高频

（二）、解决方案

1、垂直拆分

　　　　　　　　　　　　订单库根据业务垂直拆分成多个数据库　　

 基于业务对数据库垂直拆分提高数据库的可靠性和可维护性。

大团队对于单表进行维护会容易出现锁表或者过多占用系统资源的情况。

导致锁表的几种情况：

只有通过索引条件来进行检索数据库，[INNODB]才使用行级锁，否则使用标记锁。

（1）、对没有索引的列加锁，导致表锁。 给id加入排它锁（for update），由于id没有索引，实际上是表级锁。这个时候对下一个id上排他锁，就会申请表锁，出现锁等待。

（2）、对有索引的键值加锁，会对所有涉及到的数据行加锁。

2、水平拆分（冷热数据分离）

（1）、将过了起飞时间的机票数据，迁移到一个具有相同结构的冷数据。该数据库仅提供查询功能，不提供修改功能。

如果确实需要修改，还原到热数据库中。

三、目标和实施方案

（一）、订单的存储和处理周期存5年级以上

（二）、提升订单系统的处理能力，支持订单QPS的10倍规模的增长。

（三）、提升系统性能的前提，降低总成本

（四）、提高系统的水平扩展能力，通过渐变的操作，快速扩容以应变对应的长期业务增长。