VB对access数据库查询，但是数据库太大，20万条左右的数据

公司要我用VB做个电子看板，通过这个电子看板显示公司生产的产品的投入数合格数和合格率，但是公司产线用的是access数据库，是进口设备自动生成的，反正就是没法用mysql了，每个数据库就有几百M那么大= =，删除数据压缩清理后缩小为几十M，但是公司不停的生产，所以时不时要清理。。。当数据库大的时候VB定时进行查询处理时电脑就好卡（产线电脑配置好低的），而我觉得奇怪的是，为什么那些设备（日本进口的）也有对数据库进行实时查询显示（按秒计算的查询频率），但是却一点也不拖慢系统运行速度，有什么办法可以让自己的程序也对系统资源占用大大降低？

11 个解决方案

#1

每次只加载必要的内容，不要全部加载

#2

自己弄一个数据库，然后定时从access里同步过去。

#3

该回复于2013-10-30 08:19:23被管理员删除

#4

无论任何方式，access都不能支持这么大的数据量。

access无法建立索引，所以“按需加载”没用，access只能做线性的查找。

#5

引用 4 楼 caozhy 的回复:

无论任何方式，access都不能支持这么大的数据量。

access无法建立索引，所以“按需加载”没用，access只能做线性的查找。

这话别当真。老实按你公司的需求建索引吧。按说你们公司连进口设备都用上了，也不缺钱报销一两本ACCESS编程方面的书籍了

#6

用来查询的算法策略（包括 SQL 语句的写法）都大有讲究：

1 尽量避免在 Where 子句中做运算，特别是字符串运算，也要避免长字符串的比较。

  例如某网友做的测试：

select * from records where Mid(card_no,1,4)='5378' (13秒)
select * from records where amount/30< 1000 （11秒）

  改为：

select * from records where card_no like '5378%'（< 1秒）
select * from records where amount < 1000*30（< 1秒）

2 在有索引的大数据表中避免在索引字段上使用 IN 关键字（OR 逻辑）

select count(*) from stuff where id_no in('0','1')（23秒）

（select count(*) from stuff where id_no in = '0' or id_no in = '1' 效果相同）

改成

select count(*) from stuff where id_no='0'
select count(*) from stuff where id_no='1'
后相加，3秒


3 充分利用子查询

  根据我的经验，当先用某一字段查询时可将子集缩得很小，再查询时遍历的开销就小了。

4 尽量避免为了只用一个 SQL 语句而结构得非常复杂的逻辑

5 不必要时，就不要 select *，而是列出你实际需要的字段表，减小对虚拟内存的开销，避免频繁的磁盘交换。

6 实际上数据库表的设计也极有讲究，例如用数字编码代替规律性或固有名词字符串，大大缩小库容。

总之，要对数据库做充分的分析，多做一些测试实验，优化你的查询策略和算法。

#7

引用 5 楼 bcrun 的回复:

Quote: 引用 4 楼 caozhy 的回复:

无论任何方式，access都不能支持这么大的数据量。

access无法建立索引，所以“按需加载”没用，access只能做线性的查找。

这话别当真。老实按你公司的需求建索引吧。按说你们公司连进口设备都用上了，也不缺钱报销一两本ACCESS编程方面的书籍了

好吧，居然是支持索引的。从来没有用过，因为access是给裱糊匠用的。

#8

#9

用DAO，传说对Access做了优化，操作速度比ADO快，而且提供诸如CompactDatabase(函数功能等同于Access里的压缩和修复数据库菜单功能)一类ADO没有的函数

#10

用SQLITE做啊...很小,很好用. 不过VB方面的资料好少.好可怜

#11

这要分析日本设备的数据保留量等信息。
至于为啥不能用mysql 甚至 sqlserver实在保持疑惑，还有个简单的思路，你可以尝试一下。
实时把要查询的数据简化后放入另一个mdb中，保持另一个查询用mdb的苗条。
其实只要能实时进行数据转移，sql server一类的东西使用就不成问题了。
说实话，10w级别数据量，不加索引对sql server都有点难受，别说access了。