8w的数据执行了1小时还没有结果，请支援一下

Rock_Wu 2011-08-01 05:22:35

update AA set Sque=b.Sque
from BB b
where AA.ID=b.ID
and AA.viewdate>'2011-7-30'
and AA.Sque=-2

AA表有4000万行记录，加上and AA.viewdate>'2011-7-30'，查出来只有100万
BB 表只有8万行，BB表是一个临时表
结果这个update执行了1小时了，还没有执行完
帮忙给分析下什么原因？

...全文

1512 47 打赏收藏转发到动态举报

写回复

用AI写文章

47 条回复

切换为时间正序

请发表友善的回复…

发表回复

hanmos 2011-08-09

打赏
举报

Mark

Rock_Wu 2011-08-06

打赏
举报

上千万行，上亿的数据处理真的不是那么好弄
搞不好就超时

尤其是要做关联Update

zhangjianfeila 2011-08-04

打赏
举报

虽然内容不多，楼主能把自己所学到的一些东西分享出来，我们都应该感谢，国内技术牛人挺多的，但愿意分享的并不见多。所以，有人会觉得这个国内最大的IT平台上头条的会显得肤浅，那些觉得肤浅应该是属于牛人。。就是只耕作，不分享的人

dhysf 2011-08-03

打赏
举报

[Quote=引用 38 楼 dongbula 的回复:]
遇到这种问题，单独采用某一种手段是不行的，需要多管齐下，
1、where 字段需要增加索引，
2、最好按字段单独索引
3、更新时使用简单日志
4、增加文件和文件组，将数据和索引各自单独存放在不同的物理文件当中以提高io吞吐量
5、更新时打开性能跟踪器和数据库性能优化跟踪器，以判断真正的瓶颈在哪里？
6、进行第5步的同时，在数据库中跟踪锁的信息，也可以判断瓶颈。
你这种情况，多半是cp……
[/Quote]
顶

dongbula 2011-08-03

打赏
举报

遇到这种问题，单独采用某一种手段是不行的，需要多管齐下，
1、where 字段需要增加索引，
2、最好按字段单独索引
3、更新时使用简单日志
4、增加文件和文件组，将数据和索引各自单独存放在不同的物理文件当中以提高io吞吐量
5、更新时打开性能跟踪器和数据库性能优化跟踪器，以判断真正的瓶颈在哪里？
6、进行第5步的同时，在数据库中跟踪锁的信息，也可以判断瓶颈。
你这种情况，多半是cpu或者磁盘io上出了问题。

oO寒枫Oo 2011-08-03

打赏
举报

[Quote=引用 36 楼 prince6635 的回复:]

我之前也碰到过这种问题，我的数据更多200w左右，后来发现是因为update的字段在其中一个index中，每次update都要重新build这些index，这就是bottleneck所在，lz看下Sque是不是在哪个index中，有的话先删除那个index然后update完再把index加回来试试。
[/Quote]
删除那个index在这里显然不可行这么多记录重建索引估计得好几个小时

prince6635 2011-08-03

打赏
举报

我之前也碰到过这种问题，我的数据更多200w左右，后来发现是因为update的字段在其中一个index中，每次update都要重新build这些index，这就是bottleneck所在，lz看下Sque是不是在哪个index中，有的话先删除那个index然后update完再把index加回来试试。

abee23 2011-08-03

打赏
举报

mark

prince6635 2011-08-03

打赏
举报

[Quote=引用 37 楼 lxpbs8851 的回复:]

引用 36 楼 prince6635 的回复:

我之前也碰到过这种问题，我的数据更多200w左右，后来发现是因为update的字段在其中一个index中，每次update都要重新build这些index，这就是bottleneck所在，lz看下Sque是不是在哪个index中，有的话先删除那个index然后update完再把index加回来试试。

删除那个index在这里显然不可行 ……
[/Quote]
他之所以慢就是因为在update的时候要重建这个Sque字段，只要他是index的一部分，需要把包含这个字段的index删除，等到update完再加回来就好了，8w数据表的index删除一般不会timeout，真的会就把SQL中的Timeout设置成大的值，或者是0（无限）就好了，反正我的问题是这么解决的，只是提个建议罢了。

worldy 2011-08-03

打赏
举报

出现在where中的字段，必须设置索引，否则。。。。。。。。。

金矿科技 2011-08-02

打赏
举报

每天在论坛回复可以得10分；

oO寒枫Oo 2011-08-02

打赏
举报

索引在此处其实是阻力
更新操作需要大量的磁盘读取操作肯定不会很快。
建议方案：
1.将所要更新的数据分时间段分批进行更新
2.在数据库“属性”里，“选项”页，故障还原模型选“简单”。因为你的更新操作会产生大量的日志文件
这个操作你可以在更新操作的时候设置好大大降低你的日志生成量

Rock_Wu 2011-08-02

打赏
举报

[Quote=引用 23 楼 grandtree 的回复:]

使用临时表不见得能够改善性能，反而多增加了一次表连接，还是在原表上增加索引比较好
[/Quote]

索引都是聚集索引了，表太大了，索引也吃力

还是以前的架构有缺陷
总行数是1.2亿行，3个月的，每个月4000万行按月分区表。
出错的时候是7月29日，月底了，数据几乎达到峰值了。所以有点难为Update操作了。
select操作还行。

现在换一个方案，每天把数据从事务数据库抽出来插入历史数据的同时，也插入一个临时的作业表
每天就操作这个作业表，100多万行。