接口开发完后，个人对于接下来接口优化的一些思考
优化点
入参的合法性和长度范围，必填项的检查验证
因为没有入参，所以不需要考虑。
批量思想解决N+1问题
// 假设要查询100个订单及其对应的用户信息
List<Order> orders = orderMapper.selectList(new QueryWrapper<>().last("limit 100"));
// N+1问题: 循环查询每个订单的用户信息
for (Order order : orders) {
// 每个订单都要单独发起一次SQL查询用户信息
User user = userMapper.selectById(order.getUserId());
order.setUserName(user.getName());
}
- 1次查询订单列表
- N次查询用户信息(N=订单数量)
总计: N+1次查询
-- 第1次查询
SELECT * FROM orders LIMIT 100;
-- 然后是N次单独的用户查询
SELECT * FROM users WHERE id = 1;
SELECT * FROM users WHERE id = 2;
SELECT * FROM users WHERE id = 3;
...
// 1. 先查询订单列表
List<Order> orders = orderMapper.selectList(new QueryWrapper<>().last("limit 100"));
// 2. 收集所有用户ID
List<Long> userIds = orders.stream()
.map(Order::getUserId)
.collect(Collectors.toList());
// 3. 一次性批量查询所有用户信息
List<User> users = userMapper.selectBatchIds(userIds);
// 4. 构建用户ID到用户信息的映射
Map<Long, User> userMap = users.stream()
.collect(Collectors.toMap(User::getId, u -> u));
// 5. 填充订单的用户信息
for (Order order : orders) {
User user = userMap.get(order.getUserId());
order.setUserName(user.getName());
}
-- 第1次查询
SELECT * FROM orders LIMIT 100;
-- 第2次批量查询
SELECT * FROM users WHERE id IN (1,2,3,...);
批量查询只产生2条SQL，不限于读取（批量读取），写入（批量写入）也是一样的。
异步思想：解决长耗时问题
因为没有入参，所以不需要考虑
并行思想：把大任务拆分多个子任务，让多个子任务同时执行（人多力量大）
空间换时间思想：使用缓存降低耗时
使用缓存虽然可以提升用户体验，但是也会带来其他问题，如数据一致性问题。还有缓存穿透、缓存击穿、缓存雪崩、缓存淘汰等问题。
复用思想：线程连接池、数据库连接池
连接池的原理是通过预先创建一定数量的连接对象，并将其保存在池中。当需要使用连接时，从池中获取一个可用的连接对象，使用完毕后归还给池，而不是每次都创建和销毁连接对象。这样可以避免频繁地创建和销毁连接对象，提高系统性能和资源利用率。
数据量大的时候，使用压缩算法减少传输数据的时间
Content-Encoding 是 HTTP 协议中的一个头部字段，用于指示服务器对响应内容进行了何种类型的编码压缩。它的作用是告知客户端如何解码和还原服务器返回的压缩内容。
解耦思想：使用消息队列解除强耦合性
