项目背景微服务架构、主数据源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的消耗 数据块的指标 需要统一团队所有开发都需要清楚认识并落实