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

Question

小弟初入j2ee，工作中遇到一个任务是写一个脚本，来完成对一个表的操作，具体的操作要求是： 新建6个字段，这6个字段的意义是通过关联查询得到的统计数据（求和，统计个数等），现在要求对现有数据更新，需要的查询没有难点，现只担心性能问题，需要这个更新的操作尽可能的快，该表的数据量是百万级别。希望有经验的兄弟更够提供一些思路，多多益善。另外还有一个比较弱的问题。。关于存储过程，现在对存储过程基本的认识，现在主要的疑惑是不知何时应该应用存储过程。小弟刚入门，问题比较白，见笑了。希望大家不吝赐教，先谢过了。

Answer 1

不知道你具体需求，必不可少的是建索引！你数据库使用是什么？SQLSERVER Oracle？建议到数据库区咨询下

Answer 2

..恩。。我本想直接一个update 对那个6个字段直接给子查询的结果就完事的。。 因为考虑性能 才想的多了起来 无奈所知有限。。想不出什么 
 分表，恩，谢谢楼上几位给的建议。我去查查..

Answer 3

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

Answer 4

感谢楼上的回答，我的情况类似于后者。一个百万级数据的表，要增加6个字段，同时要将现有数据的这6个字段的值查询出来更新上去。这个脚本应该是在server shut down的时候执行，公司的产品每个月更新一次，需求就是希望脚本的只能能有更好的performance再次感谢，我会参考你的宝贵建议。。

Answer 5

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

Answer 6

单纯的提高数据库脚本的性能，还是建议楼主去数据库区吧。
业务逻辑，表结构，等等都不能更改的情况下，只单纯提高存储过程的执行效率，
是要看具体的数据库系统的。
主流的SQL Server和Oracle数据库，对于数据的存储管理，有很多地方是不同的。
这个要看具体情况了。最后，表达一下个人看法。
如果一张表里面有百万级的数据，并且还要有数据的批量更新操作。
我是绝对不会把所有数据都存放到这一张表当中去的，绝对会把数据拆分成多个表。
你是无法想像百万级数据的更新操作，对于数据库系统是多么大的负担。
Oracle好像使用快照方式，可以略微提高性能，但是，依然会有其他问题产生。
我以前的单位，做过一个百万级数据的查询迁移工作，使用存储过程，运行了14个小时。
当然，操作的那张表，只是一些备查信息，几乎不会被其他程序用到。

Answer 7

 非常感谢楼上的建议，我再更新下，   小弟简单写了个存储过程来测试一个字段的更新..在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(); 
 

Answer 8

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