高并发场景下的数据库治理

为啥要做数据库的专项治理？

在高并发场景下，数据库是整个系统链路的最底层，他能直接影响整个系统的吞吐力和高性能。

     接口的压力是可以通过应用的集群横向扩容来缓解压力，高速缓存现在也能轻松支持几十万qps,唯独数据库在整个应用的运行期是无法做到水平扩容缓解压力的

 所以在高并发高性能的架构治理中，数据库需要单独拧出来做专项治理的。

数据库的治理到底治的是什么？

 数据库的治理主要围绕数据库的算力和存储能力来治理，而算力通常也受其存储能力的影响。

从单库单表来看

影响其算力的部分有

1. 添加索引，优化索引
2. sql 优化：如静止动态sql,sql 要有业务语义；核心库要静止大范围查询和group by 能内存聚合分析的语句，避免BP 里的热点数据被换算挤兑出去了，这样容易导致压垮骆驼的最后一根稻草；update 语句要根据主键更新避免死锁；
3. 如果数据持续扩大再新建备库，读写分离。（读写分离只能适用纯读的业务链路，写读写要避免使用。适合报表 账单之类的导出）

随着数据的增长，当单表的数据达到8千万条 甚至超过上亿条后 上述的优化已经不明显了，这就涉及到了数据库的另一个治理-存储能力的治理。相对情况下，存储越大 算力越低。

1. 这就需要分库分表了。该分多大，多少张表，多少个库，每个库适合多少张表？ 理论上单库存储能力上限是5t,建议在2t，原因是阿里云在5t以内可以做到线上数据库出问题后两分钟内回复备库使用。
2. 定期删除数据，数据OP，是为了增加单库内的热点数据的密度（把业务行为完结的数据就可以删除了，保留着干嘛 成本又贵）。那非热点数据可以通过离线表做离线导出。

最后回溯整个业务产品的功能，根据业务分级，区分核心链路，在技术架构上做出调整 进行数据库的强弱依赖治理。核心链路上核心数据库要重保，剥离对非核心数据库的依赖。