请教SQL Server 2000执行速度的问题

suzg 2002-02-26 10:59:40
初学者请教:

Win2000下用Delphi6+ADO+SQL Server2000,程序与SQL Server在同一台电脑上。
有一个Table1中有10个字段,姑且称为a0,a1,.....a9,其中a0,a1共同为主键。
应用程序需要向表里添加数据,但数据可能是表中已经有的(通过a0,a1判断),那么就忽略掉。
建立了一个存储过程用来向表里添加数据,将@a0, @a1 .... @a9作为参数。
IF NOT EXISTS (SELECT a0 FROM Table1 where @a0=a0 and @a1=a1)
INSERT INTO Table1 (a0, a1.....a9)
VALUES (@a0, @a1, ......@a9)
在Delphi中,通过ADOStoredProc的
Parameters.ParamByName('').Value 将@a0到@a9赋值,然后ExecProc。

但这样的速度很慢,做了一个试验,将
10个参数赋值Parameters.ParamByName('').Value:=x 和ExecProc放在一个循环中,
执行1000次计算时间,结果是16-19秒,即使给表中有的数据,不会执行INSERT,也要13秒
虽然我的机器配置有些低,但感觉不应该如此慢。

请教:我这里做的有什么问题?还是需要什么优化?请给出具体建议,十分感谢!!
...全文
79 6 打赏 收藏 转发到动态 举报
写回复
用AI写文章
6 条回复
切换为时间正序
请发表友善的回复…
发表回复
suzg 2002-02-26
  • 打赏
  • 举报
回复
请zws说详细点,谢谢!
suzg 2002-02-26
  • 打赏
  • 举报
回复
TO:wwwwwwww(我我),你贴的这些在SQL Server的帮助我也看过,不过我具体怎么做有些不是很清楚,我才来这里请教的。

希望能够针对我的这个问题回答,转贴别处的话请说明在那里就可以了,我应该能找得到的。

谢谢!
zws 2002-02-26
  • 打赏
  • 举报
回复
唯一索引
stiwin 2002-02-26
  • 打赏
  • 举报
回复
我方面的知识我以想了解了下
wwwwwwww 2002-02-26
  • 打赏
  • 举报
回复
查询优化建议
有些查询天生就消耗大量资源。这与基本的数据库和索引问题有关。这些查询的效率并不低,因为查询优化器会以最有效的可能方式实现这些查询。然而,它们确实消耗大量资源,而且 Transact-SQL 面向集合的性质使这些查询看起来效率很低。查询优化器的智能水平无法消除这些构造的固有资源成本。与不复杂的查询相比,这些查询的固有成本十分昂贵。虽然 Microsoft® SQL Server™ 2000 使用最佳的访问计划,但受到基础构造可能性的限制。例如,下列类型的查询可能占用大量资源:

返回大结果集的查询


高度不唯一的 WHERE 子句
不过有一些针对优化查询和提高查询性能的建议,其中包括:

添加更多的内存(尤其是如果服务器运行许多复杂查询而且其中几个查询执行很慢)。


在有多个处理器的计算机上运行 SQL Server。多个处理器使 SQL Server 得以利用并行查询。有关更多信息,请参见并行查询处理。


考虑重新编写查询。
如果查询使用游标,则确定如果使用效率更高的游标类型(如快速只进游标)或单纯查询能否更有效地编写游标查询。单纯查询的性能一般优于游标操作。一组游标语句通常是一个外循环操作,在此操作中,一旦使用内部语句便开始处理外循环内的每行,因此可考虑使用 GROUP BY 或 CASE 语句或改为使用子查询。


如果应用程序使用循环,可考虑在查询内放入循环。应用程序常包含带参数化查询的循环,该循环执行许多次并要求运行应用程序的计算机与 SQL Server 之间有网络往返。可改为使用临时表创建一个更复杂的查询。只需提供一个网络往返,查询优化器即会更好地优化这个查询。


不要对同一查询内的单个表使用多个别名以模拟索引交叉。模拟索引交叉已没有必要,因为 SQL Server 会自动考虑索引交叉并且可以在同一查询内的相同表上使用多个索引。例如,给出下列示例查询:
SELECT * FROM lineitem
WHERE partkey BETWEEN 17000 AND 17100 AND
shipdate BETWEEN '1/1/1994' AND '1/31/1994"

SQL Server 可以在 partkey 和 shipdate 列上都使用索引,然后在两个子集之间执行哈希匹配以获得索引交叉。

只在必要时才使用查询提示。若查询使用在 SQL Server 早期版本上执行的提示,则应在不指定提示的情况下对该查询进行测试。提示会防碍查询优化器选择更好的执行计划。有关更多信息,请参见 SELECT。
利用 query governor 配置选项和设置。可以使用 query governor 配置选项阻止执行长时间运行的查询,从而防止消耗系统资源。默认情况下,query governor 配置选项允许执行所有查询,而不考虑查询所需的时间。然而,可以将查询调控器设置到最大秒数,以允许执行所有连接的所有查询或只允许执行特定连接的查询。查询调控器基于估计的查询成本而不是实际的已用时间,因此没有任何运行时开销。它还在长时间运行的查询开始前便将其停止,而不是先运行这些查询直到达到某些预定义的限制为止。
wwwwwwww 2002-02-26
  • 打赏
  • 举报
回复
查询优化
完全通过系统级服务器性能优化(如内存大小、文件系统类型、处理器的数目及类型等)解决性能问题可能很诱人。但经验表明大多数性能问题不能用这种方法解决。必须通过这些方法解决性能问题:分析应用程序以及应用程序提交给数据库的查询和更新,并分析这些查询和更新如何与数据库架构交互。

持续时间意外地长的查询和更新可能由下列原因引起:

网络通讯速度慢。


服务器计算机的内存不足或 Microsoft® SQL Server™ 2000 可用的内存不足。


缺少有用的统计数据。


统计数据过期。


缺少有用的索引。


缺少有用的数据条带化。
当查询或更新花费的时间比预期的长时,使用下面的检查清单提高性能。



说明 建议在与技术支持提供商联系之前先参考该检查清单。

性能问题与查询以外的组件是否有关?例如,问题是否为网络性能慢?是否有任何其它可能引起或间接导致性能下降的组件?可以使用 Windows NT 性能监视器监视与 SQL Server 相关和与 SQL Server 不相关的组件性能。有关更多信息,请参见使用系统监视器进行监视。


如果性能问题与查询相关,涉及哪个查询或哪组查询?使用 SQL 事件探查器帮助识别慢速查询。有关更多信息,请参见使用 SQL 事件探查器进行监视。
通过使用 SET 语句启用 SHOWPLAN、STATISTICS IO、STATISTICS TIME 和 STATISTICS PROFILE 选项,可以确定数据库查询性能。

SHOWPLAN 描述 SQL Server 查询优化器选择的数据检索方法。有关更多信息,请参见 SET SHOWPLAN_ALL。


STATISTICS IO 报告与语句内引用的每个表的扫描数、逻辑读取数(在高速缓存中访问的页数)和物理读取数(访问磁盘的次数)有关的信息。有关更多信息,请参见 SET STATISTICS IO。


STATISTICS TIME 显示分析、编译和执行查询所需的时间(以毫秒为单位)。有关更多信息,请参见 SET STATISTICS TIME。


STATISTICS PROFILE 显示每个查询执行后的结果集,代表查询执行的配置文件。有关更多信息,请参见 SET STATISTICS PROFILE。
在 SQL 查询分析器中,还可以打开 graphical execution plan 选项查看关于 SQL Server 如何检索数据的图形表示。

由这些工具收集的信息使您得以确定 SQL Server 查询优化器正在如何执行查询以及正在使用哪些索引。利用这些信息,可以确定通过重写查询、更改表上的索引或修改数据库设计等方法能否提高性能。有关更多信息,请参见分析查询。

是否已经用有用的统计数据优化查询?
SQL Server 自动在索引列上创建对列内的值分布情况的统计。也可以使用 SQL 查询分析器或 CREATE STATISTICS 语句在非索引列上手动创建统计;或者如果将 auto create statistics 数据库选项设置为 true,则自动在非索引列上创建统计。查询处理器可以利用这些统计确定最佳的查询评估策略。在联接操作所涉及的非索引列上维护附加的统计信息可以提高查询性能。有关更多信息,请参见统计信息。

使用 SQL 事件探查器或 SQL 查询分析器内的图形执行计划来监视查询,以确定查询是否有足够的统计信息。有关更多信息,请参见错误和警告事件分类。

查询统计信息是否为最新?统计信息是否自动更新?
SQL Server 自动在索引列上创建并更新查询统计(只要没有禁用自动查询统计更新特性)。另外,可以使用 SQL 查询分析器或 UPDATE STATISTICS 语句在非索引列上手工更新统计;或者如果 auto update statistics 数据库选项设置为 true,则自动在非索引列上更新统计。最新的统计不取决于日期或时间数据。如果尚未进行 UPDATE 操作,则查询统计信息仍是最新的。

如果没有将统计设置为自动更新,则应设置为自动更新。有关更多信息,请参见统计信息。

是否有合适的索引?添加一个或多个索引是否会提高查询性能?有关更多信息,请参见索引优化建议。


是否有任何数据热点或索引热点?如果有,考虑使用磁盘条带化。有关更多信息,请参见使用文件组放置数据和 RAID。


是否为查询优化器提供了优化复杂查询的最有利条件?有关更多信息,请参见查询优化建议。

828

社区成员

发帖
与我相关
我的任务
社区描述
Delphi 非技术区
社区管理员
  • 非技术区社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧