接口开发完后，个人对于接下来接口优化的一些思考

优化点

入参的合法性和长度范围，必填项的检查验证

因为没有入参，所以不需要考虑。

批量思想解决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 协议中的一个头部字段，用于指示服务器对响应内容进行了何种类型的编码压缩。它的作用是告知客户端如何解码和还原服务器返回的压缩内容。

解耦思想：使用消息队列解除强耦合性