高手救我,为什麽查询的速度那麽慢?(100分)

  • 主题发起人 主题发起人 wang241
  • 开始时间 开始时间
W

wang241

Unregistered / Unconfirmed
GUEST, unregistred user!
我用DELPHI30,PARADOX数据库,数据库放在一个NOVELL的服务器上,数据库的结构非常简单,6个字段,
Z1 D
Z2 A,8
Z3 A,16
Z4 S
Z5 A,50
Z6 A,50
数据库中共有58000条记录,7兆多字节,一个非常简单的SQL语句进行查询
datamodule1.query1.close;
datamodule1.query1.sql.clear;
datamodule1.query1.sql.add('select * from zysj.dbf');
datamodule1.query1.sql.add('where trim(z3)=:zz3');
datamodule1.query1.parambyname'zz3').asstring:=trim(edit1.text);
if not datamodule1.query1.prepared then
datamodule1.query1.prepare;
datamodule1.query1.open;

一切就是这麽简单,可是查询一个数据竟要15-20秒,这绝对无法向用户交代。
把Z1,Z2,Z3设为PRIMARY KEY也无济于事(好象快一点点,心理感觉上)。
有讨论说DABASE比PARADOX快,于是换成DABASE的库文件,结果也一样,让人无法忍受。

我实在是无计可施,请高人指点,这100块银圆还请笑纳。

wang241@163.net
 
建议如下:
1.不要用z1,z2,z3做联合主键,where子句中只用到z3
2.Paradox中主键是不是自动建立主索引,如不是,得建立主索引
3.显性调用TDabaBase控件,用来控制交易
4.建立一个数值型的索引,而不用字符型
5.再看看你的网络负担
另:本人做过一套系统,Sql Server 7.0(比Paradox慢n倍),100万条记录,主键
查询也是闪现既过
 
1、改用ACCESS数据库,ADO方式(不用BDE)。
2、最好采用客户--服务器方式,把检索数据的任务交给服务器端。(用INTERBASE,
或干脆SQL SERVER)
 
从1X 秒的放映速度 和 你的数据库规模来看。 应不是本地处理和网络负荷的影响。
我看大概问题出在 where trim(z3) 上吧。
 
问题出在trim(z3)上?
摆明不把Borland的精英门放在眼里!
 
面条之言诧异,用Sql Server?那岂不是更慢.
INTERBASE在速度方面还可以,但比起文件型数据库...
 
王坏人呀,好久不见了,最近还好吗?
我觉得问题出在你的数据库选用上,可能是数据库太大,造成网络符合过中的缘故吧
换MSSQL问题应该可以解决(Interbase?)。
本地数据库是先把所有数据放到本机,然后逐条记录筛选,就想过滤,呵呵,速度当然慢
 
很容易解决,方法仅限于文件型数据库:

datamodule1.query1.sql.add('select * from zysj.dbf');
//datamodule1.query1.sql.add('where trim(z3)=:zz3');

即不加where条件,而使用Filter
datamodule1.query1.Filtered:=True;
datamodule1.query1.Filter:=format('z3 = ''%s'' ',[trim(edit1.text)]);

试试吧!
 
rss是个聪明人
 
但返回58000条记录到本地不会很爽吧!
 
窃以为与其用参数不如直接:
datamodule1.query1.sql.add('select * from zysj.dbf');
datamodule1.query1.sql.add('where trim(z3)=' + edit1.text);
我最不看好的。还有,rss的说法我也不怎么同意,过滤是最慢的(某本书上说)
Query本来应该就是最快的了,可能是你的服务性能的问题吧,另外索引也很关键,
trim就不要了吧,你在加入数据时trim岂不更爽?这样服务器也能利用索引,应该快很多。
 
我的观点是:
既然数据库放在服务器上,就不因该选用文件型数据库。采用两层或三层结构比较
合理。不但在处理大数据量操作时,可以只向客户机返回检索结果,减小网络负重(
5万多条记录),而且大型数据库都有自己的一套优化方法,一般来说服务器的处理速
度也更高。另外,若多台客户机同时访问数据库,文件型数据库在冲突处理、数据一
致性等方面也无法做到保证。
 
1.过滤在SQL数据库很慢,在文件型数据库很快.
2.文件型数据库不会返回58000条纪录到本地.BDE会自己调节.

请试试再说感受,如果更慢,别骂我.

 
面条此番言论到还在理,但现在讨论的是了Paradox加速问题,
3h就更离谱了,Query最快?那是对真正的网络数据库,本地表好象还是Table强.
(没做过实验,也可以看看李维的书吗)
 
rss看来没吃过BDE的亏
 
没办法喽,如真的几十万条记录,呵呵
1、文件型数据库,TABLE的确比QUERY快
2、MSSQL速度应该不会慢
3、你的设计是否有问题?不用一个表,而是多个表存放历史数据(比如按日期)
每次查询就查指定的表,这样是否可以好点?
 
CJ到底是高人.
 
CJ有理.BDE无罪.
 
rss想不想要BDE的罪证,本人无偿奉送
 
BDE好歹也是Borland的数据库引擎,一大产品.
没有那么坏吧,有了问题先找找自身原因吧,
罪证?罪犯是谁??



 
后退
顶部