用来查询的算法策略（包括 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 实际上数据库表的设计也极有讲究，例如用数字编码代替规律性或固有名词字符串，大大缩小库容。总之，要对数据库做充分的分析，多做一些测试实验，优化你的查询策略和算法。
这话别当真。老实按你公司的需求建索引吧。按说你们公司连进口设备都用上了，也不缺钱报销一两本ACCESS编程方面的书籍了
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 实际上数据库表的设计也极有讲究，例如用数字编码代替规律性或固有名词字符串，大大缩小库容。总之，要对数据库做充分的分析，多做一些测试实验，优化你的查询策略和算法。
这话别当真。老实按你公司的需求建索引吧。按说你们公司连进口设备都用上了，也不缺钱报销一两本ACCESS编程方面的书籍了好吧，居然是支持索引的。从来没有用过，因为access是给裱糊匠用的。
至于为啥不能用mysql 甚至 sqlserver实在保持疑惑，还有个简单的思路，你可以尝试一下。
实时把要查询的数据简化后放入另一个mdb中，保持另一个查询用mdb的苗条。
其实只要能实时进行数据转移，sql server一类的东西使用就不成问题了。
说实话，10w级别数据量，不加索引对sql server都有点难受，别说access了。