关于删除(delete)性能消耗

LikeCode 2008-09-08 06:25:04
有条件从一个表里删除记录性能消耗有多大?
现在假设表里有 20,000 条记录, 每次从该表读取数据时, 都执行一次有条件的delete操作, 读取的频率比较高, 大概就是一个网购网站查看商品那样的频率, 象这样, 每次查询都搜索有条件delete操作, 性能消耗高不高, 可以忽略吗?

竹子个人的理解的话, 消耗应该是要考虑的, 因为这是delete(删除)而不是truncate(清空), 有条件 delete, 数据库应该是要检索表里的每一行数据, 检索出来后, 还要判断条件是否成立, 如果成立, 删除完这条记录, 数据库系统还要做日志记录, 这看起来好象是很麻烦的操作, 另外, 更致命的是, 在竹子所描述的情况下, 这样的操作不是单用户的, 只要是这个网站的浏览者, 都会触发这样的操作, 所以, 竹子认为, 消耗是比较严重的, 也就是说, 频繁的执行数据库更新, 而不仅仅是查询!



请大家赐答! 谢谢!
...全文
500 18 打赏 收藏 转发到动态 举报
写回复
用AI写文章
18 条回复
切换为时间正序
请发表友善的回复…
发表回复
幸运的意外 2008-09-13
  • 打赏
  • 举报
回复
楼主朋友,delete的消耗主要取决于表中记录数和定位条件,如果条件比较简单的话,那么消耗只看表中数据的多少了,当然硬件问题咱不考虑.delete无论如何都会扫描表中所有记录一次.如果在百万级的表中,delete运行完就很费时.就这样.不过对于一个网站来说,因为交易记录一天应当没有问题,如果出现反映慢,那么就采取其他存储方式来保存记录吧.
113244 2008-09-13
  • 打赏
  • 举报
回复
紧张。期待。关注。
hbhuo2008 2008-09-09
  • 打赏
  • 举报
回复
学习了。
utpcb 2008-09-09
  • 打赏
  • 举报
回复
可不可以考虑 能不能每个用户一个临时表 ! 把他的数据放入临时表处理快不
昵称被占用了 2008-09-09
  • 打赏
  • 举报
回复
[Quote=引用 5 楼 CN_SQL 的回复:]
按照你的业务情况,你可能最重要关心的问题应该是
如何避免造成死锁和阻塞的问题,相比性能问题,前者感觉要重要些。
[/Quote]

同意这个观点,delete加排他锁,可能阻塞其他进程

另外,“ 每次从该表读取数据时, 都执行一次有条件的delete操作”应该可以用其他方案代替,难道他“ 每次从该表读取数据”都是执行不带where的SQL语句?
如果读取数据带where,按时间删除完全可以建立一个job来完成,时间调度也比较灵活,可以设置在非高峰期执行
lyn00750 2008-09-09
  • 打赏
  • 举报
回复
mark
dawugui 2008-09-08
  • 打赏
  • 举报
回复
如果你的删除用到了索引,问题不大.但如果没有用到,就麻烦了.
ruihuahan 2008-09-08
  • 打赏
  • 举报
回复
有道理
LikeCode 2008-09-08
  • 打赏
  • 举报
回复
[Quote=引用 7 楼 szx1999 的回复:]
引用楼主 LikeCode 的帖子:
每次从该表读取数据时, 都执行一次有条件的delete操作

设计很失败,后果很严重。
hahaha, joke~ ^_^

不过也许真的需要改进一下你的实现方案……
[/Quote]

不好意思,我也认为这样的设计非常失败,这是我一个同事给的方案,竹子是强烈不同意这样的设计,但同事认为完全没有问题,故有竹子本帖一问。


[Quote=引用 8 楼 Garnett_KG 的回复:]

什么是性能消耗?实在是太不具体了,很不好回答

简单说一下带条件的DELETE执行过程:

1 、按WHERE 条件找到待删除的记录(此时若WHERE 条件符合SARGS且相应的字段含索引,则会用到索引,更快速的读取到记录)

2、 尝试在找到的记录上添加独占锁(XLock),若存在锁冲突,则时delete语句此会被阻塞住。

3、 执行删除动作

(1) 记录日志
(2) 删除聚集索引(数据页)
(3) 删除非聚集索引页
(4) 维护相关的索引结构(可能…
[/Quote]
感谢您的关注,毫无疑问,DELETE比SELECT复杂。
或许竹子说性能消耗描述不准确吧,竹子的意思是这种频繁DELETE会不会带来程序上性能严重降低
fcuandy 2008-09-08
  • 打赏
  • 举报
回复
没看明白,只能关注
Garnett_KG 2008-09-08
  • 打赏
  • 举报
回复

什么是性能消耗?实在是太不具体了,很不好回答

简单说一下带条件的DELETE执行过程:

1 、按WHERE 条件找到待删除的记录(此时若WHERE 条件符合SARGS且相应的字段含索引,则会用到索引,更快速的读取到记录)

2、 尝试在找到的记录上添加独占锁(XLock),若存在锁冲突,则时delete语句此会被阻塞住。

3、 执行删除动作

(1) 记录日志
(2) 删除聚集索引(数据页)
(3) 删除非聚集索引页
(4) 维护相关的索引结构(可能是合并索引页)

4、语句结束(事务提交),修改后的数据页会被保留在BUFFER中,等待底层的线程或CHECKPOINT线程写入磁盘

由此可见,delete比select复杂的多,需要执行的动作也多的多。

等不到来世 2008-09-08
  • 打赏
  • 举报
回复
[Quote=引用楼主 LikeCode 的帖子:]
每次从该表读取数据时, 都执行一次有条件的delete操作
[/Quote]
设计很失败,后果很严重。
hahaha, joke~ ^_^

不过也许真的需要改进一下你的实现方案……
LikeCode 2008-09-08
  • 打赏
  • 举报
回复


感谢大家的关注.


条件大概就是时间段判断.
判断时间是否早于现在时间的N天这样的条件, 也不会复杂到哪里去.






[Quote=引用 3 楼 Haiwer 的回复:]
关键看“条件delete操作”的条件,如果保证条件能高效用到索引(最好聚集索引),那在酸每次删除数据不多的情况下,就可以忽略

也就是说,两个前提:
1、 能高效使用索引
2、限定的数据不很多

[/Quote]

但是这样的检索, 删除 操作过于频繁, 就算是有索引, 性能消耗也能忽略吗?!



[Quote=引用 4 楼 CN_SQL 的回复:]
这样的问题,问得也太大了吧。
你只要在过滤条件的字段上加上合适的索引,会提高其性能的。


如你所说,不管是UPDATE还是DELETE,首先都要去扫描表(也许扫描用得不恰当,即都要”SELECT“操作)
至于记日志的情况,那也要看数据库的恢复模式是什么样的,不同恢复模式下的数据库记日志是不同的。

最后至于,性能消耗的问题,你自己在环境测试了,如果可以忍受的话,那还好,不能的话,想办法改进一下业务处理。
[/Quote]

我另外找个时间测试一下,谢谢.
CN_SQL 2008-09-08
  • 打赏
  • 举报
回复
按照你的业务情况,你可能最重要关心的问题应该是
如何避免造成死锁和阻塞的问题,相比性能问题,前者感觉要重要些。
昵称被占用了 2008-09-08
  • 打赏
  • 举报
回复
关键看“条件delete操作”的条件,如果保证条件能高效用到索引(最好聚集索引),那在酸每次删除数据不多的情况下,就可以忽略

也就是说,两个前提:
1、 能高效使用索引
2、限定的数据不很多
CN_SQL 2008-09-08
  • 打赏
  • 举报
回复
这样的问题,问得也太大了吧。
你只要在过滤条件的字段上加上合适的索引,会提高其性能的。


如你所说,不管是UPDATE还是DELETE,首先都要去扫描表(也许扫描用得不恰当,即都要”SELECT“操作)
至于记日志的情况,那也要看数据库的恢复模式是什么样的,不同恢复模式下的数据库记日志是不同的。

最后至于,性能消耗的问题,你自己在环境测试了,如果可以忍受的话,那还好,不能的话,想办法改进一下业务处理。
wzy_love_sly 2008-09-08
  • 打赏
  • 举报
回复
数据库应该是要检索表里的每一行数据, 检索出来后, 还要判断条件是否成立

update比select消耗肯定是大的多,delete 表 where 索引字段=值,用索引检索
liangCK 2008-09-08
  • 打赏
  • 举报
回复
牛人...

34,575

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server相关内容讨论专区
社区管理员
  • 基础类社区
  • 二月十六
  • 卖水果的net
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

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