我是如何把一个接口的响应时间从 2s 优化到 50ms 的
背景
上周线上监控报警，有一个用户列表查询接口的平均响应时间达到了 2.3 秒，高峰期甚至超过 5 秒，严重影响了用户体验。
这个接口是我一年前写的，当时数据量小，没觉得有什么问题。现在用户表已经有 500 多万条数据了，性能问题就暴露出来了。
今天我把整个优化过程记录下来，从问题定位到最终优化完成，一步步带大家看如何把一个慢接口优化到 50ms 以内。
第一步：定位问题
首先用 Postman 测试了一下接口，确实很慢。然后我打开了 MySQL 的慢查询日志，找到了对应的 SQL 语句：
sql
SELECT u.id, u.username, u.email, u.phone, r.role_name, d.dept_name FROM user u LEFT JOIN role r ON u.role_id = r.id LEFT JOIN dept d ON u.dept_id = d.id WHERE u.status = 1 ORDER BY u.create_time DESC LIMIT 10 OFFSET 100000;执行时间：2.1 秒。
问题 1：深度分页导致的性能问题
LIMIT 10 OFFSET 100000这种写法会让 MySQL 扫描 100010 行数据，然后丢弃前 100000 行，只返回最后 10 行。当偏移量很大时，性能会急剧下降。
优化方案：使用游标分页
sql
-- 优化前 SELECT * FROM user WHERE status = 1 ORDER BY id DESC LIMIT 10 OFFSET 100000; -- 优化后 SELECT * FROM user WHERE status = 1 AND id < 100000 ORDER BY id DESC LIMIT 10;这样 MySQL 只需要扫描 10 行数据，执行时间从 2.1 秒降到了 0.01 秒。
问题 2：没有合适的索引
查看了一下表结构，发现status、create_time和关联字段role_id、dept_id都没有建索引。
优化方案：添加合适的索引
sql
-- 给查询条件和排序字段建联合索引 CREATE INDEX idx_user_status_create_time ON user(status, create_time DESC); -- 给关联字段建索引 CREATE INDEX idx_user_role_id ON user(role_id); CREATE INDEX idx_user_dept_id ON user(dept_id);添加索引后，查询时间降到了 0.3 秒。
问题 3：不必要的关联查询
查看代码发现，这个接口返回的角色名称和部门名称其实很少变化，而且大部分用户都属于同一个部门和角色。
优化方案：使用缓存
java
运行
// 原来的代码 List<UserVO> userList = userMapper.selectUserList(query); for (UserVO user : userList) { Role role = roleMapper.selectById(user.getRoleId()); user.setRoleName(role.getName()); Dept dept = deptMapper.selectById(user.getDeptId()); user.setDeptName(dept.getName()); } // 优化后的代码 // 先把所有角色和部门加载到缓存中 Map<Long, String> roleMap = roleMapper.selectAll().stream() .collect(Collectors.toMap(Role::getId, Role::getName)); Map<Long, String> deptMap = deptMapper.selectAll().stream() .collect(Collectors.toMap(Dept::getId, Dept::getName)); // 然后在循环中直接从缓存中获取 for (UserVO user : userList) { user.setRoleName(roleMap.get(user.getRoleId())); user.setDeptName(deptMap.get(user.getDeptId())); }这样就把原来的 N+1 次查询变成了 3 次查询，接口响应时间降到了 0.1 秒。
问题 4：返回了不必要的字段
查看接口返回结果，发现返回了很多不需要的字段，比如password、salt、update_time等。
优化方案：只返回需要的字段
java
运行
// 原来的代码 List<User> userList = userMapper.selectList(queryWrapper); // 优化后的代码 List<UserVO> userList = userMapper.selectUserList(query);在 Mapper 中只查询需要的字段，减少数据传输量。
最终优化结果
经过以上几步优化，接口的平均响应时间从 2.3 秒降到了 45ms，高峰期也不超过 100ms，完美解决了性能问题。
总结
接口优化是一个系统性的工作，需要从多个方面入手：
- 先定位慢查询，优化 SQL 语句
- 添加合适的索引
- 避免 N+1 查询，使用缓存
- 只返回需要的字段
- 考虑使用 Redis 缓存热点数据
记住：过早优化是万恶之源，但不优化也是万恶之源。在开发初期就要考虑到性能问题，避免后期踩大坑。