接口性能优化(减少接口的响应时间)

优化标准:少于1s

可用apifox跑接口,看耗时多少ms

1.代码执行慢:代码优化

2.查询数据慢:慢sql优化

如果已优化过,依然很慢,得分析是否是表数据量过大,譬如以前我们dba推荐mysql库单表行数量不要超过3kw,实践中也发现,当单表数据量过大时,单纯从sql优化的角度着手是无法解决性能问题的。此时可能得考虑分库分表,或采取其他的存储方式

3.缓存优化(总之,能查询缓存的话(redis),尽量不要直接查询数据库)

慢sql优化

1.单业务单sql  复杂逻辑用代码处理,不放在sql里处理

简单干净的sql有利于降低数据库开发的出错率,集中业务逻辑于java代码中,有利于与持久层的解耦,有利于开发与维护。

2.考虑redis缓存

3.加索引(二分法):

4.条件太单一,建议加上过滤性高的搜索条件

5.列越少越好,大字段(varchar>100)列去掉

索引的介绍:

索引(Index)是帮助MySQL高效获取数据的数据结构。提取句子主干,就可以得到索引的本质:索引是数据结构。

一般来说,索引本身也很大,不可能全部存储在内存中,因此索引往往以索引文件的形式存储在磁盘上。这样的话,索引查找过程中就要产生磁盘I/O消耗,相对于内存存取,I/O存取的消耗要高几个数量级,所以评价一个数据结构作为索引的优劣最重要的指标就是在查找过程中磁盘I/O操作次数的渐进复杂度。换句话说,索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数。下面先介绍内存和磁盘存取原理,然后再结合这些原理分析B-/+Tree作为索引的效率。

聚集索引:表中各行的物理顺序与键值的逻辑顺序相同,每个表只能有一个。

非聚集索引:非聚集索引指定表的逻辑顺序,数据存储在一个位置,索引存储在另一个位置,索引中包含指向数据存储位置的指针。

索引的优缺点: 

优点:加快访问速度;

缺点:带索引的表在数据库中的存储需要更多的空间;

下列情况下可以使用索引:

该列频繁用于搜索;

该列用于对数据进行排序;

下列情况下避免使用索引:

列中仅仅包含几个不同的值;

表中仅包含几行。为小型表创建索引可能不太划算,因为SQLServer在索引中搜索数据所花的时间比在表中逐行搜索所花的时间更长。

原文地址:https://www.cnblogs.com/yzwdcjs/p/14940345.html