一、目前数据库背景问题
（一）、数据库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倍规模的增长。
（三）、提升系统性能的前提，降低总成本
（四）、提高系统的水平扩展能力，通过渐变的操作，快速扩容以应变对应的长期业务增长。
标签：加锁,携程,数据,数据库,订单,索引,优化,id 来源： https://www.cnblogs.com/Alei777/p/16685686.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。