最近遇到一个问题，对四千W条数据的数据库进行更新
由于我们是做服装生产管理系统的，我们的系统可以实时的收集到员工的生产每扎货的生产信息，一般二K人的客户，一个月收集到的数据是400万条，我们每个月初都需要计算每一扎货的生产时间（前一扎货的结束是本扎的开始，当然还得扣掉中间休息时间，第一扎货的开始时间取上班时间）而且还需要跟工序表计算每扎货的SAM以及单价。
  1、现在遇到的问题是更新这么多数据该需要非常长的时间，有没有办法可以提速。
  2、如果更新这么多数据会导致硬盘瓶劲，硬盘改写数据太多，磁盘读写速度跟不上。
  3、这么多数据很容易产生锁，当然有的是旧锁，导致急时的数据采集上来时会超时。

------解决方案--------------------
升级软硬

索引
分区

------解决方案--------------------
如果为了系统稳定，就要控制并发了。
将用户操作分出优先级，加强控制。
牺牲速度
------解决方案--------------------

探讨

如果为了系统稳定，就要控制并发了。
将用户操作分出优先级，加强控制。
牺牲速度

------解决方案--------------------
即使改400万条数据，耗时也不会很久呀。。。偶有时也改BOM，800多万
还有计件绩效，3千多万。。。呵

仔细规划设计，没那么恐怖。提供有偿支持

另：企业版支持分区
------解决方案--------------------
以今天的软硬件技术发展来看 4千万条记录的表 也只能算普通,
 把你的数据库结构写出来 并讲清 你需要得到什么样的结果
让大家给你评点 你才会有更大的进步,
 不要怕丢脸 讲得透彻 理解深刻 你才会有进步 还让更多的人能学到东西 

期待你早点 写出你现有的表设计及索引 和期待的结果 让我们也可以练练手

------解决方案--------------------
还有 SQL Server 2008 R2 新鲜出炉 火辣登场了 .
 2000 实在是有些太老了.
------解决方案--------------------
靠规划设计了，找平衡了
------解决方案--------------------
要末数据库设计有问题，要末就是对业务的理解有问题，需要重新进行抽象。
------解决方案--------------------
1:如果月与月之间数据没有联系的话，月初将上个月的数据库备份出来，找台机器去算。
2：如果没上面的条件的话，找闲的时候算
3：如果没有上面2个条件的话，每天算。
------解决方案--------------------
创建索引UPDATE会更慢,怎么可能提高UPDATE速度,晕
------解决方案--------------------
一次性更新绝对是设计上的问题

------解决方案--------------------
更新时把索引先关掉.
------解决方案--------------------
无论怎么看，都是设计的问题。
------解决方案--------------------
I got it
------解决方案--------------------
能不能按照日期每天生成一个表，这样一个表中的数据就不会太大！
对表操作的冲突就会大大减少，不过这样做你的程序肯定也要相应的改动！
从固定操作一个表变成动态操作表！
------解决方案--------------------
头疼的并发问题
------解决方案--------------------
这么好的问题不能让沉了，顶起来等高手解答
------解决方案--------------------
系统设计上有问题

把问题分散,不要把一个月的数据集中到一天处理
------解决方案--------------------
我也同意把问题分散
------解决方案--------------------
我同意散分，哈哈。