你不会是一次select出几十万条数据然后用NPOI写吧。
我测试时,是一次写5w,花销大概是3.5分钟。客户要求,导出到一张表中,尝试过分页,不过还是慢。
@幻天芒: 我有空试试看看我这里速度怎么样。稍后回复你
@幻天芒: 刚测试了一下,5w条数据,49个字段,查询耗时1.5秒,导出8秒。查询是直接查的,没加查询条件,这个就不用管了。导出后的数据64M,你的3.5分钟是本地测试的时间吗?
@Rainier-Soft.Com: 感谢您的测试,我是连接的远程库,用DataReader读取的。表数据量在260w。能否贴写NPOI导出的代码?
@幻天芒: 我的代码是查询到实体然后再将实体列表导出到Excel,中间加了一层DataReader->实体的操作,按你的DataReader直接到Excel效率应该更高才对,我是直接在本地测试导出的,建议你可以在本地测试一下。因为数据量大的话,网络传输也会占用不少时间,而且我5w条数据导出的Excel都已经64M了,以200k/s的下载速度来算都要5分钟了。
@Rainier-Soft.Com: 的确,经过测试,单纯的本地导出,非常快的。导出65536行,直接写文件的话,花销在30多s。
请问,NPOI 2.0.1能否导出比65536行更多的数据吗?我测试1.2.5的时候,用xls格式,不能超过65536,测试2.0.1的时候,用xlsx格式,还是导不出比65536更多的数据。
在NPOI2.0.1中,采用XSSFWorkbook这个类,可以导出超过65536行的数据,但是这个类开始快,超过2w条时,就非常慢了~
其他的帮不了你 Sql语句贴出来
SELECT t1.* FROM dbo.table1 t1 join dbo.table2 t2 on t2.DeptCode=t1.DeptCode and t2.DU in ('这里是参数') WHERE AccountName IN ('这里是参数') and left(t1.YearMonth,4)='2013'
SQL语句,有点耗时,最耗时的却是文件操作。
这个估计没有什么好办法了。
写个5W条记录到excel中的sheet中需要 3.5分钟??? 这也太慢了吧
一行有接近50个列,是比较慢。用拼字符串导出为csv也试过,速度差不多。好纠结的导出问题。
@幻天芒:
csv都是纯文本了,一列数据就算1k的话也才50m,50m的文本写入一般是秒级的时间消耗,3-5分钟离谱了点吧。到底是导出慢还是写入慢?
@天方: csv的文件大小是30M,采用StringBuilder拼接字符串,然后用StreamWriter一次性写入的。不知道是不是这种方式的问题。
估计是网络传输慢。
有可能,网速在200k左右,不过这个慢得有点离谱了。感谢指导~
确实,这个对导出速度影响很大~
left(t1.YearMonth,4)='2013' 可以改为 t1.YearMonth like '2013%' 会不会快些
试过了,这个对导出速度的影响不大。
@幻天芒: 试试导出到 xslx格式, 这个格式经过压缩。 文件体积大大下降。 相信传输时间会缩短许多
@gunsmoke: 现在更换了思路,采用前台执行导出计划,后台导出的方式导出,客户一段时间后自己去下载。感谢~