42 个解决方案
#1
恭喜恭喜
#2
随喜随喜，呵呵
#3
acess垃圾就垃圾在这里
#4
是不是还很占地方？
#5
加速度是负的
#6
100万的MDB,想快都难
#7
是啊,建议数据量大了并且要处理并发,就用SQL SERVER(便宜)或者ORACLE(太贵了).
#8
你的内存也会爆啊
#9
一百万的数组???你用什么数据库都快不起来吧.
#10
MDB 不应该这样用
#11
回复人： baal(邪神)
MDB 不应该这样用
MDB 不应该这样用
#12
回复人： baal(邪神)
MDB 不应该这样用
请教，应该怎么用？师兄把话说完
MDB 不应该这样用
请教，应该怎么用？师兄把话说完
#13
不该用啊
#14
是不是我少“引用”了什么文件，速度才慢的？
#15
?
百万记录的MDB数据读入？
百万记录的MDB数据读入？
#16
要对百万记录的数据进行分析计算，直接对库操作太慢了吧，所以想到读入内存进行计算，以为能快点，没想到读入内存这一关就很慢
#17
近快转为SQL SERVER2000吧.
#18
建议楼主把数据库改为SQL的好了
#19
这么大的数组读入内存，肯定慢了。
如果表设计得好，用SQL指令计算分析，ACCESS也会慢，但应该比你现在的方法快。
这么大的数据量，是考虑换数据库的时候了。
如果表设计得好，用SQL指令计算分析，ACCESS也会慢，但应该比你现在的方法快。
这么大的数据量，是考虑换数据库的时候了。
#20
发现一个问题，读前一二万条记录时，仅用二三秒，然后突然就慢下来了，500条/秒，这是为何？
#21
可以考虑边读取边处理。如果不是一定要全部读取才能处理的话。
#22
超过100万条数据的话,建议你不要用ACCESS数据库,另外,为什么要一次性的将这么多数据全部读到数组中呢!?
#23
后面用的虚拟内存，不满才怪。
#24
这是个用户库，要建树型结构进行业绩核算佣金
#25
用postgresql吧。免费的。
如果不明白怎么用，我们可以一起探讨。
如果不明白怎么用，我们可以一起探讨。
#26
数组是要占内存的。这个速度慢不关access事
#27
我开始用语句打开库读取数据，后来改用DATA控件，速度快了，才用了二分钟，就算合格了，100万条呢
#28
每次算1000条，分开算
用动画提示，正在计算，不可以干别的事情！！
一次读100万，sqlserver一样慢！！
用动画提示，正在计算，不可以干别的事情！！
一次读100万，sqlserver一样慢！！
#29
不能这样计划，因为树型结构中，你怎么分哪1000条呢，就必须全部读入，建立树型结构，再计算
#30
一百万条啊，递归吧（递归从数据库中读出满足条件的记录）， ，不过，，我不知道会不会堆栈溢出哦，恐怕，死机也会发生的。。。
#31
是在這開玩笑吧.
100萬條記錄 * 10個字段 * 每個字段50個字符
100萬條記錄 * 10個字段 * 每個字段50個字符
#32
改用sql2000吧
#33
简单的方法：将数据按照不同的需求分成几个相对较小的数据库，只当需要的时候才载入相应的数据库，ACCESS适合用于比较少的数据。
还有一个方法就是放弃MDB而使用其他的大型数据库，比如SQL SERVER或别的一些东西。
还有一个方法就是放弃MDB而使用其他的大型数据库，比如SQL SERVER或别的一些东西。
#34
up
#35
为什么不用SQL2000或者Oracle8i之类的大型数据库呢?
这样,我想比用MDB要好多了,
至少不会这么浪费时间,这么低效率~
这样,我想比用MDB要好多了,
至少不会这么浪费时间,这么低效率~
#36
一定得选最好的服务器
雇中科院的程序员
用就得用红旗Linux
大型数据库平台
机型最差也得银河曙光
什么SQL Server呀，Oracle呀，dBase呀
能给它装的全给它装上
服务器上边有防火墙，里边有双机热备
机柜旁边站一网管
穿白大褂，特专业的那种
别人一靠近(儿)，甭管有事(儿)没事(儿)都得跟人家喊
核心机密谢绝参观
一口地道的京片子
倍(儿)有面子
机房里再配一个UPS
必须用山特的
一年光维护费费就得几万美金
再建一个办公局域网
二十四在线
就是一个字(儿)——快
下载就得来个万八千K的
周围的工作站不是IBM就是HP
你要用联想呀
你都不好登陆到域上
雇中科院的程序员
用就得用红旗Linux
大型数据库平台
机型最差也得银河曙光
什么SQL Server呀，Oracle呀，dBase呀
能给它装的全给它装上
服务器上边有防火墙，里边有双机热备
机柜旁边站一网管
穿白大褂，特专业的那种
别人一靠近(儿)，甭管有事(儿)没事(儿)都得跟人家喊
核心机密谢绝参观
一口地道的京片子
倍(儿)有面子
机房里再配一个UPS
必须用山特的
一年光维护费费就得几万美金
再建一个办公局域网
二十四在线
就是一个字(儿)——快
下载就得来个万八千K的
周围的工作站不是IBM就是HP
你要用联想呀
你都不好登陆到域上
#37
100万条的数据建议用Oracle,超过百万行的数据，sql 2000照样跟蜗牛似的
#38
把内存升级到2G，该没问题了^_^
#39
建议换数据库，ACCESS是解决不了这么多数据的访问速度的
#40
一定得选最好的服务器
雇中科院的程序员
用就得用红旗Linux
大型数据库平台
机型最差也得银河曙光
什么SQL Server呀，Oracle呀，dBase呀
能给它装的全给它装上
服务器上边有防火墙，里边有双机热备
-----------------------------------------------------
机柜旁边站一网管
穿白大褂，特专业的那种
别人一靠近(儿)，甭管有事(儿)没事(儿)都得跟人家喊
核心机密谢绝参观
一口地道的京片子
倍(儿)有面子
机房里再配一个UPS
必须用山特的
一年光维护费费就得几万美金
再建一个办公局域网
二十四在线
就是一个字(儿)——快
下载就得来个万八千K的
周围的工作站不是IBM就是HP
你要用联想呀
你都不好登陆到域上
---------------------------------------------
呵呵，这老兄挺有趣，估计也是个YY高手吧，没有恶意，莫误会。
雇中科院的程序员
用就得用红旗Linux
大型数据库平台
机型最差也得银河曙光
什么SQL Server呀，Oracle呀，dBase呀
能给它装的全给它装上
服务器上边有防火墙，里边有双机热备
-----------------------------------------------------
机柜旁边站一网管
穿白大褂，特专业的那种
别人一靠近(儿)，甭管有事(儿)没事(儿)都得跟人家喊
核心机密谢绝参观
一口地道的京片子
倍(儿)有面子
机房里再配一个UPS
必须用山特的
一年光维护费费就得几万美金
再建一个办公局域网
二十四在线
就是一个字(儿)——快
下载就得来个万八千K的
周围的工作站不是IBM就是HP
你要用联想呀
你都不好登陆到域上
---------------------------------------------
呵呵，这老兄挺有趣，估计也是个YY高手吧，没有恶意，莫误会。
#41
楼主：除了变更数据库平台没有其他更好的办法。你把全部数据读到内存中处理，思路是对的但是就目前的硬件条件是不可取的。如果不能更换数据库那么你试着变更检索条件看看
#42
一次性显示出一百多万条记录有什么实际意义的,不是想一条条看吧
#1
恭喜恭喜
#2
随喜随喜，呵呵
#3
acess垃圾就垃圾在这里
#4
是不是还很占地方？
#5
加速度是负的
#6
100万的MDB,想快都难
#7
是啊,建议数据量大了并且要处理并发,就用SQL SERVER(便宜)或者ORACLE(太贵了).
#8
你的内存也会爆啊
#9
一百万的数组???你用什么数据库都快不起来吧.
#10
MDB 不应该这样用
#11
回复人： baal(邪神)
MDB 不应该这样用
MDB 不应该这样用
#12
回复人： baal(邪神)
MDB 不应该这样用
请教，应该怎么用？师兄把话说完
MDB 不应该这样用
请教，应该怎么用？师兄把话说完
#13
不该用啊
#14
是不是我少“引用”了什么文件，速度才慢的？
#15
?
百万记录的MDB数据读入？
百万记录的MDB数据读入？
#16
要对百万记录的数据进行分析计算，直接对库操作太慢了吧，所以想到读入内存进行计算，以为能快点，没想到读入内存这一关就很慢
#17
近快转为SQL SERVER2000吧.
#18
建议楼主把数据库改为SQL的好了
#19
这么大的数组读入内存，肯定慢了。
如果表设计得好，用SQL指令计算分析，ACCESS也会慢，但应该比你现在的方法快。
这么大的数据量，是考虑换数据库的时候了。
如果表设计得好，用SQL指令计算分析，ACCESS也会慢，但应该比你现在的方法快。
这么大的数据量，是考虑换数据库的时候了。
#20
发现一个问题，读前一二万条记录时，仅用二三秒，然后突然就慢下来了，500条/秒，这是为何？
#21
可以考虑边读取边处理。如果不是一定要全部读取才能处理的话。
#22
超过100万条数据的话,建议你不要用ACCESS数据库,另外,为什么要一次性的将这么多数据全部读到数组中呢!?
#23
后面用的虚拟内存，不满才怪。
#24
这是个用户库，要建树型结构进行业绩核算佣金
#25
用postgresql吧。免费的。
如果不明白怎么用，我们可以一起探讨。
如果不明白怎么用，我们可以一起探讨。
#26
数组是要占内存的。这个速度慢不关access事
#27
我开始用语句打开库读取数据，后来改用DATA控件，速度快了，才用了二分钟，就算合格了，100万条呢
#28
每次算1000条，分开算
用动画提示，正在计算，不可以干别的事情！！
一次读100万，sqlserver一样慢！！
用动画提示，正在计算，不可以干别的事情！！
一次读100万，sqlserver一样慢！！
#29
不能这样计划，因为树型结构中，你怎么分哪1000条呢，就必须全部读入，建立树型结构，再计算
#30
一百万条啊，递归吧（递归从数据库中读出满足条件的记录）， ，不过，，我不知道会不会堆栈溢出哦，恐怕，死机也会发生的。。。
#31
是在這開玩笑吧.
100萬條記錄 * 10個字段 * 每個字段50個字符
100萬條記錄 * 10個字段 * 每個字段50個字符
#32
改用sql2000吧
#33
简单的方法：将数据按照不同的需求分成几个相对较小的数据库，只当需要的时候才载入相应的数据库，ACCESS适合用于比较少的数据。
还有一个方法就是放弃MDB而使用其他的大型数据库，比如SQL SERVER或别的一些东西。
还有一个方法就是放弃MDB而使用其他的大型数据库，比如SQL SERVER或别的一些东西。
#34
up
#35
为什么不用SQL2000或者Oracle8i之类的大型数据库呢?
这样,我想比用MDB要好多了,
至少不会这么浪费时间,这么低效率~
这样,我想比用MDB要好多了,
至少不会这么浪费时间,这么低效率~
#36
一定得选最好的服务器
雇中科院的程序员
用就得用红旗Linux
大型数据库平台
机型最差也得银河曙光
什么SQL Server呀，Oracle呀，dBase呀
能给它装的全给它装上
服务器上边有防火墙，里边有双机热备
机柜旁边站一网管
穿白大褂，特专业的那种
别人一靠近(儿)，甭管有事(儿)没事(儿)都得跟人家喊
核心机密谢绝参观
一口地道的京片子
倍(儿)有面子
机房里再配一个UPS
必须用山特的
一年光维护费费就得几万美金
再建一个办公局域网
二十四在线
就是一个字(儿)——快
下载就得来个万八千K的
周围的工作站不是IBM就是HP
你要用联想呀
你都不好登陆到域上
雇中科院的程序员
用就得用红旗Linux
大型数据库平台
机型最差也得银河曙光
什么SQL Server呀，Oracle呀，dBase呀
能给它装的全给它装上
服务器上边有防火墙，里边有双机热备
机柜旁边站一网管
穿白大褂，特专业的那种
别人一靠近(儿)，甭管有事(儿)没事(儿)都得跟人家喊
核心机密谢绝参观
一口地道的京片子
倍(儿)有面子
机房里再配一个UPS
必须用山特的
一年光维护费费就得几万美金
再建一个办公局域网
二十四在线
就是一个字(儿)——快
下载就得来个万八千K的
周围的工作站不是IBM就是HP
你要用联想呀
你都不好登陆到域上
#37
100万条的数据建议用Oracle,超过百万行的数据，sql 2000照样跟蜗牛似的
#38
把内存升级到2G，该没问题了^_^
#39
建议换数据库，ACCESS是解决不了这么多数据的访问速度的
#40
一定得选最好的服务器
雇中科院的程序员
用就得用红旗Linux
大型数据库平台
机型最差也得银河曙光
什么SQL Server呀，Oracle呀，dBase呀
能给它装的全给它装上
服务器上边有防火墙，里边有双机热备
-----------------------------------------------------
机柜旁边站一网管
穿白大褂，特专业的那种
别人一靠近(儿)，甭管有事(儿)没事(儿)都得跟人家喊
核心机密谢绝参观
一口地道的京片子
倍(儿)有面子
机房里再配一个UPS
必须用山特的
一年光维护费费就得几万美金
再建一个办公局域网
二十四在线
就是一个字(儿)——快
下载就得来个万八千K的
周围的工作站不是IBM就是HP
你要用联想呀
你都不好登陆到域上
---------------------------------------------
呵呵，这老兄挺有趣，估计也是个YY高手吧，没有恶意，莫误会。
雇中科院的程序员
用就得用红旗Linux
大型数据库平台
机型最差也得银河曙光
什么SQL Server呀，Oracle呀，dBase呀
能给它装的全给它装上
服务器上边有防火墙，里边有双机热备
-----------------------------------------------------
机柜旁边站一网管
穿白大褂，特专业的那种
别人一靠近(儿)，甭管有事(儿)没事(儿)都得跟人家喊
核心机密谢绝参观
一口地道的京片子
倍(儿)有面子
机房里再配一个UPS
必须用山特的
一年光维护费费就得几万美金
再建一个办公局域网
二十四在线
就是一个字(儿)——快
下载就得来个万八千K的
周围的工作站不是IBM就是HP
你要用联想呀
你都不好登陆到域上
---------------------------------------------
呵呵，这老兄挺有趣，估计也是个YY高手吧，没有恶意，莫误会。
#41
楼主：除了变更数据库平台没有其他更好的办法。你把全部数据读到内存中处理，思路是对的但是就目前的硬件条件是不可取的。如果不能更换数据库那么你试着变更检索条件看看
#42
一次性显示出一百多万条记录有什么实际意义的,不是想一条条看吧