在进行分类汇总前，需保证数据具有下列格式，即数据区域的第一行为标题行，数据区域中没有空行和空列，数据区域四周是空行和空列，如下图是几种商品在一些城市的销售数据。另外，如果数据区域在应用分类汇总前已被设置成Excel 2003列表或Excel 2007表，需将其转换为普通区域。因为对于Excel 2003列表或Excel 2007表无法使用分类汇总。
一、仅对某列进行分类汇总
例如上例中需要对各城市的销售量进行分类汇总，方法如下:
1. 首先对数据按需要分类汇总的列(本例为“城市”列)进行排序。
选择“城市”列中的任意单元格，在Excel 2003中单击工具栏中的排序按钮如“A→Z”。在Excel 2007中，选择功能区中“数据”选项卡，在“排序和筛选”组中单击“A→Z”按钮。
2. 选择数据区域中的某个单元格，在Excel 2003中单击菜单“数据→分类汇总”。如果是Excel 2007，则在“数据”选项卡的“分级显示”组中单击“分类汇总”。
3. 在d出的“分类汇总”对话框中，在“分类字段”下选择“城市”，在“汇总方式”中选择某种汇总方式，可供选择的汇总方式有“求和”、“计数”、“平均值”等，本例中选择默认的“求和”。在“选定汇总项”下仅选择“销售额”。
4.单击确定，Excel将按城市进行分类汇总。
二、对多列进行分类汇总
如上例中需要同时对“城市”列和“商品名称”列进行分类汇总，可以插入嵌套分类汇总。
1.对数据进行多列排序，即进行多关键字排序。
首先选择数据区域中的某个单元格。
在Excel 2003中，单击菜单“数据→排序”。d出“排序”对话框，其中主要关键字选择“城市”，次要关键字选择“商品名称”，其他选择默认。
如果是Excel 2007，在“数据”选项卡的“排序和筛选”组中单击“排序”命令，在d出的“排序”对话框中，单击“添加条件”按钮添加次要关键字排序条件，然后主要关键字选择“城市”，次要关键字选择“商品名称”，其他选择默认。
2.对“城市”列进行分类汇总(外部分类汇总)。
按上述方法打开“分类汇总”对话框，在“分类字段”下选择“城市”，在“汇总方式”中选择默认的“求和”，在“选定汇总项”下仅选择“销售额”。单击“确定”。
3.对“商品名称”列进行分类汇总(嵌套分类汇总)。
再次打开“分类汇总”对话框，在“分类字段”下选择“商品名称”，取消选择“替换当前分类汇总”，单击“确定”。
这时Excel将按“城市”列和“商品名称”列对“销售额”进行分类汇总。
如果不需要显示明细数据，可以单击左侧的分级显示符号，如本例中右上角的数字和左侧的减号来隐藏明细数据。
三、删除分类汇总
在“分类汇总”对话框中，单击“全部删除”即可。
在实际的工作环境下，许多人会遇到海量数据这个复杂而艰巨的问题，它的主要难点有以下几个方面：一、数据量过大，数据中什么情况都可能存在。
如果说有10条数据，那么大不了每条去逐一检查，人为处理，如果有上百条数据，也可以考虑，如果数据上到千万级别，甚至 过亿，那不是手工能解决的了，必须通过工具或者程序进行处理，尤其海量的数据中，什么情况都可能存在，例如，数据中某处格式出了问题，尤其在程序处理时， 前面还能正常处理，突然到了某个地方问题出现了，程序终止了。
二、软硬件要求高，系统资源占用率高。
对海量的数据进行处理，除了好的方法，最重要的就是合理使用工具，合理分配系统资源。一般情况，如果处理的数据过TB级，小型机是要考虑的，普通的机子如果有好的方法可以考虑，不过也必须加大CPU和内存，就象面对着千军万马，光有勇气没有一兵一卒是很难取胜的。
三、要求很高的处理方法和技巧。
这也是本文的写作目的所在，好的处理方法是一位工程师长期工作经验的积累，也是个人的经验的总结。没有通用的处理方法，但有通用的原理和规则。
下面我们来详细介绍一下处理海量数据的经验和技巧：
一、选用优秀的数据库工具
现在的数据库工具厂家比较多，对海量数据的处理对所使用的数据库工具要求比较高，一般使用Oracle或者DB2，微软 公司最近发布的SQL Server 2005性能也不错。另外在BI领域：数据库，数据仓库，多维数据库，数据挖掘等相关工具也要进行选择，象好的ETL工具和好的OLAP工具都十分必要， 例如Informatic，Eassbase等。笔者在实际数据分析项目中，对每天6000万条的日志数据进行处理，使用SQL Server 2000需要花费6小时，而使用SQL Server 2005则只需要花费3小时。
二、编写优良的程序代码
处理数据离不开优秀的程序代码，尤其在进行复杂数据处理时，必须使用程序。好的程序代码对数据的处理至关重要，这不仅仅是数据处理准确度的问题，更是数据处理效率的问题。良好的程序代码应该包含好的算法，包含好的处理流程，包含好的效率，包含好的异常处理机制等。
三、对海量数据进行分区 *** 作
对海量数据进行分区 *** 作十分必要，例如针对按年份存取的数据，我们可以按年进行分区，不同的数据库有不同的分区方式，不 过处理机制大体相同。例如SQL Server的数据库分区是将不同的数据存于不同的文件组下，而不同的文件组存于不同的磁盘分区下，这样将数据分散开，减小磁盘I/O，减小了系统负荷， 而且还可以将日志，索引等放于不同的分区下。
四、建立广泛的索引
对海量的数据处理，对大表建立索引是必行的，建立索引要考虑到具体情况，例如针对大表的分组、排序等字段，都要建立相应 索引，一般还可以建立复合索引，对经常插入的表则建立索引时要小心，笔者在处理数据时，曾经在一个ETL流程中，当插入表时，首先删除索引，然后插入完 毕，建立索引，并实施聚合 *** 作，聚合完成后，再次插入前还是删除索引，所以索引要用到好的时机，索引的填充因子和聚集、非聚集索引都要考虑。
五、建立缓存机制
当数据量增加时，一般的处理工具都要考虑到缓存问题。缓存大小设置的好差也关系到数据处理的成败，例如，笔者在处理2亿条数据聚合 *** 作时，缓存设置为100000条/Buffer，这对于这个级别的数据量是可行的。
六、加大虚拟内存
如果系统资源有限，内存提示不足，则可以靠增加虚拟内存来解决。笔者在实际项目中曾经遇到针对18亿条的数据进行处理， 内存为1GB，1个P42.4G的CPU，对这么大的数据量进行聚合 *** 作是有问题的，提示内存不足，那么采用了加大虚拟内存的方法来解决，在6块磁盘分区 上分别建立了6个4096M的磁盘分区，用于虚拟内存，这样虚拟的内存则增加为 4096*6 + 1024 =25600 M，解决了数据处理中的内存不足问题。
七、分批处理
海量数据处理难因为数据量大，那么解决海量数据处理难的问题其中一个技巧是减少数据量。可以对海量数据分批处理，然后处 理后的数据再进行合并 *** 作，这样逐个击破，有利于小数据量的处理，不至于面对大数据量带来的问题，不过这种方法也要因时因势进行，如果不允许拆分数据，还 需要另想办法。不过一般的数据按天、按月、按年等存储的，都可以采用先分后合的方法，对数据进行分开处理。
八、使用临时表和中间表
数据量增加时，处理中要考虑提前汇总。这样做的目的是化整为零，大表变小表，分块处理完成后，再利用一定的规则进行合 并，处理过程中的临时表的使用和中间结果的保存都非常重要，如果对于超海量的数据，大表处理不了，只能拆分为多个小表。如果处理过程中需要多步汇总 *** 作， 可按汇总步骤一步步来，不要一条语句完成，一口气吃掉一个胖子。
九、优化查询SQL语句
在对海量数据进行查询处理过程中，查询的SQL语句的性能对查询效率的影响是非常大的，编写高效优良的SQL脚本和存储 过程是数据库工作人员的职责，也是检验数据库工作人员水平的一个标准，在对SQL语句的编写过程中，例如减少关联，少用或不用游标，设计好高效的数据库表 结构等都十分必要。笔者在工作中试着对1亿行的数据使用游标，运行3个小时没有出结果，这是一定要改用程序处理了。
十、使用文本格式进行处理
对一般的数据处理可以使用数据库，如果对复杂的数据处理，必须借助程序，那么在程序 *** 作数据库和程序 *** 作文本之间选择， 是一定要选择程序 *** 作文本的，原因为：程序 *** 作文本速度快；对文本进行处理不容易出错；文本的存储不受限制等。例如一般的海量的网络日志都是文本格式或者 csv格式（文本格式），对它进行处理牵扯到数据清洗，是要利用程序进行处理的，而不建议导入数据库再做清洗。
十一、定制强大的清洗规则和出错处理机制
海量数据中存在着不一致性，极有可能出现某处的瑕疵。例如，同样的数据中的时间字段，有的可能为非标准的时间，出现的原因可能为应用程序的错误，系统的错误等，这是在进行数据处理时，必须制定强大的数据清洗规则和出错处理机制。
十二、建立视图或者物化视图
视图中的数据来源于基表，对海量数据的处理，可以将数据按一定的规则分散到各个基表中，查询或处理过程中可以基于视图进行，这样分散了磁盘I/O，正如10根绳子吊着一根柱子和一根吊着一根柱子的区别。
十三、避免使用32位机子（极端情况）
目前的计算机很多都是32位的，那么编写的程序对内存的需要便受限制，而很多的海量数据处理是必须大量消耗内存的，这便要求更好性能的机子，其中对位数的限制也十分重要。
十四、考虑 *** 作系统问题
海量数据处理过程中，除了对数据库，处理程序等要求比较高以外，对 *** 作系统的要求也放到了重要的位置，一般是必须使用服务器的，而且对系统的安全性和稳定性等要求也比较高。尤其对 *** 作系统自身的缓存机制，临时空间的处理等问题都需要综合考虑。
十五、使用数据仓库和多维数据库存储
数据量加大是一定要考虑OLAP的，传统的报表可能5、6个小时出来结果，而基于Cube的查询可能只需要几分钟，因此处理海量数据的利器是OLAP多维分析，即建立数据仓库，建立多维数据集，基于多维数据集进行报表展现和数据挖掘等。
十六、使用采样数据，进行数据挖掘
基于海量数据的数据挖掘正在逐步兴起，面对着超海量的数据，一般的挖掘软件或算法往往采用数据抽样的方式进行处理，这样 的误差不会很高，大大提高了处理效率和处理的成功率。一般采样时要注意数据的完整性和，防止过大的偏差。笔者曾经对1亿2千万行的表数据进行采样，抽取出 400万行，经测试软件测试处理的误差为千分之五，客户可以接受。
还有一些方法，需要在不同的情况和场合下运用，例如使用代理键等 *** 作，这样的好处是加快了聚合时间，因为对数值型的聚合比对字符型的聚合快得多。类似的情况需要针对不同的需求进行处理。
海量数据是发展趋势，对数据分析和挖掘也越来越重要，从海量数据中提取有用信息重要而紧迫，这便要求处理要准确，精度要高，而且处理时间要短，得到有价值信息要快，所以，对海量数据的研究很有前途，也很值得进行广泛深入的研究。
如何优化 *** 作大数据量数据库下面以关系数据库系统Informix为例，介绍改善用户查询计划的方法。
1．合理使用索引
索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。索引的使用要恰到好处，其使用原则如下：
●在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引。
●在频繁进行排序或分组（即进行group by或order by *** 作）的列上建立索引。
●在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。
●如果待排序的列有多个，可以在这些列上建立复合索引（pound index）。
●使用系统工具。如Informix数据库有一个tbcheck工具，可以在可疑的索引上进行检查。在一些数据库服务器上，索引可能失效或者因为频繁 *** 作而使得读取效率降低，如果一个使用索引的查询不明不白地慢下来，可以试着用tbcheck工具检查索引的完整性，必要时进行修复。另外，当数据库表更新大量数据后，删除并重建索引可以提高查询速度。
2．避免或简化排序
应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素：
●索引中不包括一个或几个待排序的列；
●group by或order by子句中列的次序与索引的次序不一样；
●排序的列来自不同的表。
为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。
3．消除对大型表行数据的顺序存取
在嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询10亿行数据。避免这种情况的主要方法就是对连接的列进行索引。例如，两个表：学生表（学号、姓名、年龄……）和选课表（学号、课程号、成绩）。如果两个表要做连接，就要在“学号”这个连接字段上建立索引。
还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的where子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序 *** 作：
SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008
虽然在customer_num和order_num上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的 *** ，所以应该改为如下语句：
SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001
UNION
SELECT ＊ FROM orders WHERE order_num=1008
这样就能利用索引路径处理查询。
4．避免相关子查询
一个列的标签同时在主查询和where子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。
5．避免困难的正规表达式
MATCHES和LIKE关键字支持通配符匹配，技术上叫正规表达式。但这种匹配特别耗费时间。例如：SELECT ＊ FROM customer WHERE zipcode LIKE “98_ _ _”
即使在zipcode字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为SELECT ＊ FROM customer WHERE zipcode >“98000”，在执行查询时就会利用索引来查询，显然会大大提高速度。
另外，还要避免非开始的子串。例如语句：SELECT ＊ FROM customer WHERE zipcode[2，3]>“80”，在where子句中采用了非开始子串，因而这个语句也不会使用索引。
6．使用临时表加速查询
把表的一个子集进行排序并创建临时表，有时能加速查询。它有助于避免多重排序 *** 作，而且在其他方面还能简化优化器的工作。例如：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>“98000”
ORDER BY cust.name
如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个临时文件中，并按客户的名字进行排序：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
ORDER BY cust.name
INTO TEMP cust_with_balance
然后以下面的方式在临时表中查询：
SELECT ＊ FROM cust_with_balance
WHERE postcode>“98000”
临时表中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。
注意：临时表创建后不会反映主表的修改。在主表中数据频繁修改的情况下，注意不要丢失数据。
7．用排序来取代非顺序存取
非顺序磁盘存取是最慢的 *** 作，表现在磁盘存取臂的来回移动。SQL语句隐藏了这一情况，使得我们在写应用程序时很容易写出要求存取大量非顺序页的查询。
有些时候，用数据库的排序能力来替代非顺序的存取能改进查询。
实例分析
下面我们举一个制造公司的例子来说明如何进行查询优化。制造公司数据库中包括3个表，模式如下所示：
1．part表
零件号?????零件描述????????其他列
（part_num）?（part_desc）??????（other column）
102，032???Seageat 30G disk?????……
500，049???Novel 10M neork card??……
……
2．vendor表
厂商号??????厂商名??????其他列
（vendor _num）?（vendor_name） （other column）
910，257?????Seageat Corp???……
523，045?????IBM Corp?????……
……
3．parven表
零件号?????厂商号?????零件数量
（part_num）?（vendor_num）?（part_amount）
102，032????910，257????3,450,000
234，423????321，001????4，000，000
……
下面的查询将在这些表上定期运行，并产生关于所有零件数量的报表：
SELECT part_desc，vendor_name，part_amount
FROM part，vendor，parven
WHERE part.part_num=parven.part_num
AND parven.vendor_num = vendor.vendor_num
ORDER BY part.part_num
如果不建立索引，上述查询代码的开销将十分巨大。为此，我们在零件号和厂商号上建立索引。索引的建立避免了在嵌套中反复扫描。关于表与索引的统计信息如下：
表?????行尺寸???行数量?????每页行数量???数据页数量
（table）?(row size)?（Row count）?（Rows/Pages）?（Data Pages）
part????150?????10，000????25???????400
Vendor???150?????1，000???? 25???????40
Parven???13????? 15，000????300?????? 50
索引?????键尺寸???每页键数量???页面数量
（Indexes）?(Key Size)?（Keys/Page)???(Leaf Pages）
part?????4??????500???????20
Vendor????4??????500???????2
Parven????8??????250???????60
看起来是个相对简单的3表连接，但是其查询开销是很大的。通过查看系统表可以看到，在part_num上和vendor_num上有簇索引，因此索引是按照物理顺序存放的。parven表没有特定的存放次序。这些表的大小说明从缓冲页中非顺序存取的成功率很小。此语句的优化查询规划是：首先从part中顺序读取400页，然后再对parven表非顺序存取1万次，每次2页（一个索引页、一个数据页），总计2万个磁盘页，最后对vendor表非顺序存取1.5万次，合3万个磁盘页。可以看出在这个索引好的连接上花费的磁盘存取为5.04万次。
hibernate如何优化大数据量 *** 作？建议你直接用Jdbc好了，用batch，这样是最快的。
如何实现大数据量数据库的历史数据归档打开数据库
con.Open()
读取数据
OdbcDataReader reader = cmd.ExecuteReader()
把数据加载到临时表
dt.Load(reader)
在使用完毕之后，一定要关闭，要不然会出问题
reader.Close()
这个问题是这样的：
首先你要明确你的插入是正常业务需求么？如果是，那么只能接受这样的数据插入量。
其次你说数据库存不下了 那么你可以让你的数据库上限变大 这个你可以在数据库里面设置的 里面有个数据库文件属性 maxsize
最后有个方法可以使用，如果你的历史数据不会对目前业务造成很大影响 可以考虑归档处理 定时将不用的数据移入历史表 或者另外一个数据库。
注意平时对数据库的维护 定期整理索引碎片
时间维度分区表，然后定情按照规则将属于历史的分区数据迁移到，历史库上，写个存储自动维护分区表。
如何用java jdbc 向数据库表插入大数据量一次性插入大量数据，只能使用循环，
如：游标，while 循环语句
下面介绍While 循环插入数据，
SQL 代码如下：
IF OBJECT_ID('dbo.Nums') IS NOT NULL
DROP TABLE dbo.Nums
GO
CREATE TABLE dbo.Nums(n INT NOT NULL PRIMARY KEY)
DECLARE @max AS INT, @rc AS INT
SET @max = 5000000
SET @rc = 1
INSERT INTO Nums VALUES(1)
WHILE @rc * 2 <= @max
BEGIN
INSERT INTO dbo.Nums SELECT n + @rc FROM dbo.Nums
SET @rc = @rc * 2
END
INSERT INTO dbo.Nums SELECT n + @rc FROM dbo.Nums WHERE n + @rc <= @max
--以上函数取自Inside SQL Server 2005: T-SQL Query一书。
INSERT dbo.Sample SELECT n, RAND(CAST(NEWID() AS BINARY(16))) FROM Nums
php 怎么解决 大数据量 插入数据库ini_set('max_execution_time','0')
$pdo = new PDO("mysql:host=localhostdbname=test","root","123456")
$sql = "insert into test(name,age,state,created_time) values"
for($i=0$i<100000$i++){
$sql .="('zhangsan',21,1,'2015-09-17')"
}
$sql = substr($sql,0,strlen($sql)-1)
var_dump($sql)
if($pdo ->exec($sql)){
echo "插入成功！"
echo $pdo ->lastinsertid()
}
试试吧。10万条1分钟多，我觉得还行
请教如何通过WCF传输大数据量数据就是直接把DataSet 类型作为参数直接传递给服务端
WCF默认支持这么做，直接传Datatable不行。
你看一下 “服务引用设置”中你选的 *** 类型是什么，我选的是System.Array
字典 *** 类型是默认第一项 System.Collections.Generic.Dictionary
又是一个把自己架在火上烤的需求啊，
如果不考虑传输因素，可以调整wcf配置，提升传递的容量，如果是对象传递可能还要调整对象层次的深度
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）