记接口 优化

最近公司业务趋于稳定，专注于系统优化，我就配合做起了接口速率优化。 

 

1、识别慢接口

　　识别满接口主要是依据日志。 前期我们采用的是skyworking，追踪耗时较长的链路，确认耗时主要分布，比如是多次rpc通信耗时较长，比如是某个单接口耗时过长等

 

2、慢接口业务处理

　　针对业务中同一接口多次rpc通信，考虑的是通过缓存策略，代码优化，考虑实际使用中多次rpc结果一致的情况下，业务进行中的后续调用都走缓存处理。

　　针对业务中不同接口的多个rpc通信，业务无串性要求的情况下，开多个线程，以实现耗时~~ 最慢接口耗时。 我这是用来多线程做数据准备，最终数据收集处理

　　针对慢接口中的不同业务，做业务拆分，仅保留主业务，边缘业务异步处理。比如我们授信中的发短信，通知下游系统等操作，涉及到一些数据查询与组装，单独发出一个mq即可，在mq消费中取做这些伴生业务。

 

3、慢sql优化

　　先通过日志锁定慢sql，确定sql的执行条件，得到具体的语句。 

　　将具体语句在执行器中explain，查看执行计划，观察命中行数、索引情况、关联方式、排序等

　　执行计划中表的执行顺序可能与sql表象有些不同，mysql会做一些自动优化策略。 可通过explain 之后使用 show warnings命令可以得到优化后的查询语句

　　可通过mysql 的profile 查看执行sql的耗时分布，忙住推断慢原因

 

　　sql优化具体操作尽量减少回表操作，减少无用排序，减少交叉的结果集，减少准备的数据大小。利用索引。 一般情况下一个表操作聚集索引效果最佳，单个索引囊括最佳，(索引-数据的存储结构原因），当然mysql有时候会进行索引合并，因此设计索引多考虑联合索引。

　　关联都是小表驱动大表，根据sql的执行顺序，可以考虑将where的一些条件提前到ON

　　一般表关联不要太多，sql复杂的情况下考虑拆分

　　使用索引，如何避免索引失效不做赘余

　　子查询、in、exists 的转换

 

　　一次性查询大批量数据导致的慢sql问题，在业务上考虑分批获取，减少锁定时间。

　　针对分页问题，考虑改写分页方式，minId

　　考虑子查询+查询分页后主键优化

 

　　sql的优化要与数据量与具体的环境相结合。   最好是能在相似环境上做模拟复测等。