接口响应慢？先从数据库入手
很多服务端接口卡顿，问题出在数据库查询上。比如一个商品列表页，每次请求都查几十个字段，还连带用户信息、分类数据，一次请求拖出三张表。这时候加个索引可能都不管用，得重新设计查询逻辑。
可以先把非核心字段拆出去，用缓存预加载热门数据。比如首页展示的商品，提前把销量、评分这些算好，存在 Redis 里，请求直接读缓存，不碰数据库。
SELECT id, name, price FROM products WHERE status = 1 LIMIT 20;<br>-- 不要 SELECT *，只拿需要的字段减少网络往返，批量处理更高效
有个后台任务每天要同步上千条订单状态，原来是一条一条发 HTTP 请求给第三方，每条等 200 毫秒，跑完要十几分钟。改成批量提交后，一次传 100 条，总耗时降到两分钟内。
不只是外部调用，内部服务之间也一样。微服务拆得越细，来回通信越多，适当合并接口能省不少时间。别为了“高内聚”牺牲基本体验。
别让日志拖垮系统
调试阶段开着 DEBUG 日志没问题，上线后还狂写日志，磁盘容易撑爆。特别是高频接口，每调用一次就写几行，日积月累 I/O 压力猛增。
建议按环境控制日志级别，生产环境默认 INFO，异常才打 DEBUG。敏感数据也别往日志里扔，既不安全又占空间。
logger.info("User login success, uid: {}", userId);<br>// 避免打印完整请求体或用户密码善用连接池，别频繁开销资源
每次请求都新建数据库连接，等于每次吃饭都重新烧锅做饭。用连接池就像锅一直热着，随用随取。配置合理的话，响应速度能提升一大截。
常见框架都有内置支持，比如 HikariCP、Druid，记得调好最大连接数，别设太大把数据库压垮，也别太小造成排队。
静态资源交给专门的人干
图片、JS、CSS 这些全由应用服务器吐出来，等于让程序员去扫地。明明有 Nginx、CDN 能干这事，还占着应用线程不放。
把静态文件剥离出去，Nginx 直接返回，后端专注处理业务逻辑。哪怕只是加个 gzip 压缩，也能让传输体积缩小 70% 以上。