数据库大量数据更新的性能问题。

2010-12-02 07:05:55 586 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

嵌入式音频架构 - AudioWeaver 整体概念 AudioWeaver 是DSP Concept公司推出的基于嵌入式平台的音频框架。由AWE Core embedded processing engine 和 Audio Weaver Designer IDE 组成。 Audio Weaver Designer 有三个版本，ST Edition, Standard Edtion 和 Pro Edtion。 Audio Weaver Designer界面： Audio Weaver 的整体使用架构： AWD算法流文件，AWS配置脚本文件，AWB嵌入式b 阅读详情

小弟初入j2ee，工作中遇到一个任务是写一个脚本，来完成对一个表的操作，

具体的操作要求是：新建6个字段，这6个字段的意义是通过关联查询得到的统计数据（求和，统计个数等），现在要求对现有数

据更新，需要的查询没有难点，现只担心性能问题，需要这个更新的操作尽可能的快，该表的数据量是百万级别。

希望有经验的兄弟更够提供一些思路，多多益善。

另外还有一个比较弱的问题。。关于存储过程，现在对存储过程基本的认识，现在主要的疑惑是不知何时应该应用存储过程。

小弟刚入门，问题比较白，见笑了。

希望大家不吝赐教，先谢过了。

...全文

解锁全志T113-i隐藏技能：用RISC-V核跑实时系统比STM32还稳？本文深入探讨了全志T113-i SoC的异构架构潜力，重点解析如何利用其内置的玄铁C906 RISC-V核心独立运行实时系统。通过对比传统MCU与Linux方案，文章提供了从RISC-V核心启动、FreeRTOS移植到与Linux主核进行高效异构通信的完整实战指南，为工控等需要兼顾丰富应用与硬实时控制的场景提供了高集成度的单芯片解决方案。阅读详情

sound9world

Java EE 67,535 成员 225,843 内容

+ 关注 + 加入社区

切换为时间正序

别人家的老公 2010-12-06

打赏
举报

1、建立有效的索引
2、访问表分表
3、读写分离
4、数据缓存
5、库表散列

NickCheng 2010-12-06

打赏
举报

关注中。。。

Seeven 2010-12-06

打赏
举报

我这边也是类似的情况，鉴于行业要求的实时性比较高，我的做法是，把需要合并的数据尽量合并，采用队列表和日志表的方式，轮训操作，实际证明，效果还是可以的，稳定性也还行。

Arvin_Rong 2010-12-06

打赏
举报

直接从SQL存储过程上解决效果一般不太好，这种大数据量或者可预见的大数据量的表，如果是ORACLE数据库的话可以考虑表分区：）

微笑俱乐部 2010-12-06

打赏
举报

广州开普互联公司怎么样？有谁知道的

sound9world 2010-12-06

打赏
举报

非常感谢楼上的建议，我再更新下，

小弟简单写了个存储过程来测试一个字段的更新..在12万条记录的测试数据库中性能不堪入目。。

我贴上来是希望各位高人能够更明了的了解需求，第一次写存储过程照着别人写的改的。。见笑

 

delimiter   $$ 



drop   procedure   if   exists   updateTotalTravels$$ 



create   procedure   updateTotalTravels() 

begin 

    declare   _done   int   default   0; 

    declare   ref_id   varchar(32); 

    declare   ref_count   int; 

    declare   _cur1   cursor   for   select   id   from   ca_travel_method   where   is_system=false; 

    declare   continue   handler   for   sqlstate   '02000 '   set   _done   =   1; 



    open   _cur1; 



    repeat 



    fetch   _cur1   into   ref_id; 

    set   ref_count=(select   count(*)   from   ca_travel   ct   join   ca_travel_method   ctm   on   ct.travel_method_id=ctm.id   where   ctm.id=ref_id   and   ct.status=2); 

    update   ca_travel_method   set   total_travels=ref_count   where   id=ref_id; 

until   _done   end   repeat; 

    close   _cur1; 



end$$ 



delimiter   ; 



call   updateTotalTravels();

peng13482556193 2010-12-06

打赏
举报

搞不明白？

冰思雨 2010-12-04

打赏
举报

单纯的提高数据库脚本的性能，还是建议楼主去数据库区吧。
业务逻辑，表结构，等等都不能更改的情况下，只单纯提高存储过程的执行效率，
是要看具体的数据库系统的。
主流的SQL Server和Oracle数据库，对于数据的存储管理，有很多地方是不同的。
这个要看具体情况了。

最后，表达一下个人看法。
如果一张表里面有百万级的数据，并且还要有数据的批量更新操作。
我是绝对不会把所有数据都存放到这一张表当中去的，绝对会把数据拆分成多个表。
你是无法想像百万级数据的更新操作，对于数据库系统是多么大的负担。
Oracle好像使用快照方式，可以略微提高性能，但是，依然会有其他问题产生。
我以前的单位，做过一个百万级数据的查询迁移工作，使用存储过程，运行了14个小时。
当然，操作的那张表，只是一些备查信息，几乎不会被其他程序用到。

taikongxinke 2010-12-03

打赏
举报

[Quote=引用 9 楼 preferme 的回复:]

我想，楼主的意思，应该是通过关联查询百万个数据，所得的结果，更新到一个拥有6个字段的表里面吧？
而不是，通过查询更新百万个数据吧？

如果是前者，想提高性能，在相关的流程后面，添加单一统计代码即可实现。
如果是后者，首先考虑能否改成单一更新操作（就是说，在某个流程里更新单个记录，而不是所有），
其次，考虑将数据分组分批更新，最后，考虑将目标表拆分成多个表逐个更新。

举……
[/Quote]同意该楼想法，也明白其中的思路！

taikongxinke 2010-12-03

打赏
举报

楼主能不能把你的思路和相关代码放出来，让大家分析和研究处理呢？关注！

zn85600301 2010-12-03

打赏
举报

这个问题你还是转数据库区吧
对于大数据量的表一般会考虑表分区
你的查询如果牵扯表关联的话也会影响速度
不过我觉得与其去改表结构不如新建一个表
具体的业务不太清楚所以不好推测

sound9world 2010-12-03

打赏
举报

感谢楼上的回答，我的情况类似于后者。

一个百万级数据的表，要增加6个字段，同时要将现有数据的这6个字段的值查询出来更新上去。

这个脚本应该是在server shut down的时候执行，公司的产品每个月更新一次，需求就是希望脚本的只能能有更好的performance

再次感谢，我会参考你的宝贵建议。。

yaoweijq 2010-12-03

打赏
举报

既然是要性能快，
那存储过程一般是首选了
先不要建索引
索引只是在查询的时候效率高
新建，更新时反而效率低
现在楼主只是要更新数据
那加字段这个表里面，加的这些字段还是不要建索引了
在查询的表里面建索引，提高查询性能是可行的
有了存储过程
update一般来说性能差别不大
主要是这个查询，性能要尽量高

sosfnima 2010-12-03

打赏
举报

每天回帖即可获得10分可用分！小技巧：教您如何更快获得可用分

liwenlong66 2010-12-03

打赏
举报

建议利用表分区来提高性能

冰思雨 2010-12-02

打赏
举报

我想，楼主的意思，应该是通过关联查询百万个数据，所得的结果，更新到一个拥有6个字段的表里面吧？
而不是，通过查询更新百万个数据吧？

如果是前者，想提高性能，在相关的流程后面，添加单一统计代码即可实现。
如果是后者，首先考虑能否改成单一更新操作（就是说，在某个流程里更新单个记录，而不是所有），
其次，考虑将数据分组分批更新，最后，考虑将目标表拆分成多个表逐个更新。

举例：
一、（前者情况）比如，我有百万个用户，每个用户记录都有是否在线的字段，
通过查询用户表统计所有用户的在线数量，将查询结果保存到在线数量表中。
我想，数据库中的用户在线信息也是通过用户登录和登出（还有Session释放）等操作进行同步的，
那么不妨，在这些操作中添加一些代码，直接更新在线数量表不是更好吗。
这样，就不用通过查询所有用户的数据来确定在线数量了。
二、（后者情况）比如，过年了，给每个用户的年龄字段进行加一操作
（当然，这并不是经常要做的事情，只是举个例子而已）
首先，考虑能否在用户登录操作的时候进行本字段的更改，当然，已经改过的就不改了。
同时，浏览其他用户信息的时候，也要更新其他用户的年龄信息。
如果上述不可实现，其次，可以考虑将所有用户按年龄段分组（可以一年一组，也可以五年一组），
一组一组的进行更新操作，这样，每次更新不会锁住整个表（注：有的数据库只会锁表）。
最后，考虑将用户按地区或者活跃程度进行分表，分别进行更新操作。
例如，如果我们网站活跃用户相对较少，我们把百万用户，按照最后一次登录时间进行分表，
时间跨度分别是半年，半年至一年，一年以上。
上述3个表，最后一次登录时间在半年内的用户，可能相对较少，数据更新时，对其他数据影响较大。这种情况下分表更新就有效果了。其他表虽然数据相对较多，但，与其他数据影响较小，时间长点也就无所谓了吧。
啥意思？就是说，你在更新年龄的时候，如果某个人正好要看你的年龄信息，这时候，一定要等你的年龄信息更新完毕之后，才能显示给他看。但是，你都不活跃了，基本不登录，关心你年龄的人，基本就没有了。

以上信息纯属个人意见和理解。

kemizxp 2010-12-02

打赏
举报

你考虑每更新记录条数少点

sound9world 2010-12-02

打赏
举报

..恩。。我本想直接一个update 对那个6个字段直接给子查询的结果就完事的。。

因为考虑性能才想的多了起来无奈所知有限。。想不出什么

分表，恩，谢谢楼上几位给的建议。我去查查..

取你猪头 2010-12-02

打赏
举报

果断用分区表操作!

sound9world 2010-12-02

打赏
举报

mysql

加载更多回复（4）

数据库大量数据更新的性能问题。

相关推荐