从‘深分页’到‘游标分页’：一次订单导出性能提升500%的优化实录（附EasyExcel配置）

百万级订单导出性能跃迁从深分页陷阱到游标分页实战当系统需要导出百万级订单数据时很多开发者会遭遇一个典型困境明明已经采用分批查询策略导出速度却依然缓慢如蜗牛。这背后往往隐藏着数据库深分页Deep Pagination的性能陷阱。本文将揭示传统分页的性能瓶颈并展示如何通过游标分页技术实现500%的性能提升。1. 深分页的性能噩梦与本质剖析在订单导出场景中最常见的错误就是使用LIMIT offset, size进行分批查询。例如-- 典型深分页查询 SELECT * FROM orders WHERE create_time BETWEEN 2023-01-01 AND 2023-12-31 ORDER BY id DESC LIMIT 1000000, 1000这种查询方式存在三个致命缺陷全表扫描成本MySQL必须读取前1,000,100条记录然后丢弃前1,000,000条内存压力临时存储大量中间结果集可能触发OOM不可预测延迟随着offset增大查询时间呈指数级增长通过EXPLAIN分析可以看到典型的问题指标指标深分页查询游标分页typeALLrangerows全表扫描实际需要ExtraUsing filesortUsing index2. 游标分页的技术突围游标分页Cursor-based Pagination通过记录上一批数据的边界值来避免offset计算。核心原理是where 过滤条件 and id 上一批最小ID order by id desc limit 批次大小具体实现时需要处理以下关键点2.1 ID游标处理策略// Java实现示例 public ListOrder queryByCursor(Long lastId, int batchSize) { QueryWrapperOrder wrapper new QueryWrapper(); wrapper.lt(id, lastId) .orderByDesc(id) .last(LIMIT batchSize); return orderMapper.selectList(wrapper); }2.2 复合排序场景处理当需要按非ID字段排序时可采用二级索引方案-- 先通过二级索引获取主键 SELECT id FROM orders WHERE create_time 2023-01-01 ORDER BY create_time DESC, id DESC LIMIT 1000; -- 再通过主键精确查询 SELECT * FROM orders WHERE id IN (...) ORDER BY create_time DESC;3. 与EasyExcel的高效集成游标分页解决了数据查询瓶颈接下来需要优化Excel写入效率。关键配置要点3.1 分Sheet写入策略// 每100万数据分一个Sheet ExcelWriter writer EasyExcel.write(outputStream) .registerWriteHandler(new SheetWriteHandler() { Override public void sheet(int sheetNo, Sheet sheet) { if (sheetNo 0 totalRows % 1_000_000 0) { sheet.setSheetName(订单_ (sheetNo 1)); } } }).build();3.2 内存控制三要素批处理大小建议500-2000条/批临时文件缓存使用FileCache模式线程池隔离查询与写入使用不同线程池// 最佳线程池配置 ThreadPoolExecutor queryExecutor new ThreadPoolExecutor( Runtime.getRuntime().availableProcessors() * 2, Runtime.getRuntime().availableProcessors() * 4, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue(1000), new ThreadPoolExecutor.CallerRunsPolicy());4. 全链路性能优化方案完整的百万级订单导出应该包含以下优化层次优化层级技术手段预期收益存储层添加create_time索引查询提速300%查询层游标分页替代LIMIT查询提速500%应用层多线程并行查询吞吐提升200%导出层EasyExcel分Sheet内存降低80%系统层异步导出进度查询用户体验提升典型的问题排查路径通过SHOW PROCESSLIST确认慢查询使用Arthas分析JVM内存压力点用JProfiler定位线程阻塞瓶颈监控网络IO和磁盘吞吐量5. 实战中的经验之谈在实际项目中我们遇到过几个值得分享的案例ID不连续问题当使用游标分页时发现某些批次数据缺失。原因是物理删除导致ID不连续最终采用逻辑删除定时任务补偿方案热点数据问题某次大促期间导出超时发现是订单状态索引过热通过添加复合索引(create_time, status)解决内存泄漏陷阱临时文件未及时删除导致磁盘写满现在都会在finally块中添加清理逻辑对于特别大的历史数据导出我们现在会采用专用只读副本数据分片策略。一个有趣的发现是当单个导出超过500万行时CSGZ压缩格式比ZIP能减少30%的文件体积。