前言

最近在运维一个客户当中碰到的一个问题，当然系统也有点老，由导出引发的系统OOM,问题的根由就是数据量过大直接全量查库然后写excel，然后我简单粗暴的处理了：直接限制了用户的查询和导出范围，但也多做了一点把那个查询优化了下，如果客户的运维费给的及时足够我是非常乐意多花点心思网上找点方案多做些其他优化的。

这里也想到了另外的一个碰到的场景就是和第三方系统对接推送一些数据的时候有些新手埋雷可能没加数据条数限制，当然前提是测试那里只进行功能测试。

对于大业务量的客户不知道销售是否前期报价和运维过程加点报价是否可以看作一个点。

关于大批量数据导出影响问题

为啥要说导出没说查询？因为报表查询肯定自带有分页功能一定程度上屏蔽了风险。但是导出就不一样了，一般分为导出当前页和全部吧，这样这个导出全部就埋雷了。这里的雷我碰到的分为两种一种就是开头说的OOM；还有一种就是把库拖垮了其他业务拿不到连接卡在拿连接上了结果把tomcat的线程数爆了导致系统挂掉（但是这种我现在还没绝对的说服力指出是这里的问题，只能看线程堆栈好多线程卡在数据库拿连接上了）。

碰到导出如何优化数据进行分页递进查询了（查询也是需要优化的mysql中的分页，oracle我这里遇到的是排序索引的问题）。平时导出我这里用的POI了，有个缓存本地临时文件的特性的，临时搜了下。数据很大就需要分sheet页。还有就是限流了。对于数据是否作为历史数据，或者对数据查询进行限制可以跟客户沟通满足需求就可以了。对于第一条数的分页问题mysql可以搜点文章看下。oracle的我碰到个特殊的吧就是分页字段条件中没用索引就没生效这里可以采用强制索引。在SELECT 后面添加/+index(表别名索引名)/ 的方式，让查询强制走索引。

int rowCacheLength=100;//内存中缓存记录行数
/*keep 100 rowsin memory,exceeding rows will be flushed to disk*/
SXSSFWorkbook wb = newSXSSFWorkbook(rowCacheLength);
//压缩临时文件，很重要，否则磁盘很快就会被写满
wb.setCompressTempFiles(true);

Excel2003与Excel2007简要说明版本行数列数说明

2003

65536行

256列

以二进制的方式存储，这种格式不易被其他软件读取使用

2007

1048576行

16384列

基于XML的ooxml开放文档标准，ooxml使用XML和ZIP技术结合进行文件存储，XML是一个基于文本的格式，而且ZIP容器支持内容的压缩，所以其一大优势是可以大大减小文件的尺寸