接口优化方案

循环修改数据库场景，可以改成批量更新数据库，避免多次IO

循环查询其他团队接口，可以改成批量查询

批量处理

当前流程不关心某个业务处理流程，可以同步改为异步处理，比如，数据变更发消息通知其他团队

异步的实现方式，可以用线程池，也可以用消息队列，还可以用一些调度任务框架

异步处理

针对一些频繁使用且不频繁变更的数据，可以提前缓存起来，需要时直接查缓存，避免频繁地查询数据库或者重复计算

需要考虑缓存带来的数据不一致问题

缓存数据

针对实时性要求不是很高，可以提前要把查询的数据，提前计算好，放入缓存或者表中的某个字段

计算可以是定时任务，也可以是bi团队通过大数据计算结果集

数据预处理

逻辑没有互相依赖的场景，比如需要同时查询多个业务数据，然后聚合处理

串行改并行

RPC调用不放到事务里面

查询操作尽量不放到事务里面

事务中避免处理太多数据

避免大事物

不涉及共享资源的，不必要加锁

锁粒度避免过粗

子主题

深分页问题，改为固定页大小，id变化，比如id > 100000 limit 200

隐式转换

select *

索引列有计算

不满足最左匹配原则

使用or

like以通配符开头，%xx

not in 和not exists

order by 和搜索列不匹配

索引问题

主要场景

sql优化

多次需求迭代后，代码会形成一些重复查询、多次创建对象等耗时问题，接口聚合的功能也会越来越多

接口交互重构，把逻辑不相干功能拆分成多个接口

针对接口内部逻辑整体做重构，评估每个代码块的作用和用途，调整执行顺序

使用上述异步、并行、缩小锁范围等手段

方案

代码交互及逻辑重构

避免重复创建对象或创建连接，这个业务用的场景比较少，基本上用在框架里面

池化思想

接口优化方案总结