数据库优化【一】

项目背景：

        微服务架构、主数据源（oracle）、边缘业务数据源（PostgreSQL） 

        目前生产几百张表，有的表数据量达到了千万，导致数据库压力非常大，一些查询非常慢

        团队人数较多，目前未对SQL有统一的规范，故开启了这次讨论会，谈谈大家的看法

---

会议纪要：

        1、统计大量数据定时任务，建议改用大数据

        2、对慢查询进行优化，建议使用es或大数据或改造进行单表查询

        3、对核心模块 例如登录  出单  邀新人  佣金结算等模块进行隔离

        4、尽量少使用关联查询  数据在业务内进行组装

        5、前端可以对数据进行缓存，例如：用户信息

        6、数据大表进行梳理，量级大  需要改造

        7、定期检查数据的增量  查询访问量，对数据过大的表进行分区分表或PG库改造

        8、使用PG库存储非核心数据，减少核心库的压力

        9、增加熔断机制   每个后台都需要会定位并熔断接口

        10、对非实时性数据 ，可以先统计T-1后查询

        11、将cpu占用过多的sql进行处理

        12、对慢请求慢sql不走索引的SQL进行追踪 并 处理

        13、目前所有请求使用一个库，可以通过业务区分出来，分成多个库

        14、一个接口查询信息聚合过多，可以分成多个接口查询  

                eg:初始化home接口  里面查询的数据太多导致速度慢  可以拆分成多个接口进行处理

        15、对于一些需要实时查看的数据，可以先缓存，然后通过通知更新数据

        16、开发对于大表的数据要进行认知，少做统计查询

        17、查询数据比较大的时候，可以先做统计使用大数据和es进行查询

        18、对历史表  关注表的数量级增长，性能比较慢的查询

        19、关注数据量的大小，分区是否使用正确

        20、一致性要求不高的数据尽量放入缓存

        21、需求设计，数据库设计表  设计进行评估

        22、数据统计时，对活跃人群定时任务跑  减少全表扫描

        23、表数据过大是否可以进行清理

        24、减少不必要的索引建立， 索引过多会影响到查询的效率

        25、应用划分了模块，建立数据库也划分模块

        26、数据量大的标准，什么时候使用PG库 什么时候使用Oracle 需要进行规范 定义

        27、较少由于需求变复杂  导致请求的链路过长导致过慢   考虑缩短链路甚至直接请求

        28、数据库硬件性能需要监控查看

        29、查询数据统一入口，各个模块的数据由各个模块提供

---

 数据库最大连接数，各应用最大的连接数，cpu和io的消耗  数据块的指标 需要统一，团队所有开发都需要清楚认识并落实