最近遇到一个有关问题，对四千W条数据的数据库进行更新
最近遇到一个问题，对四千W条数据的数据库进行更新由于我们是做服装生产管理系统的，我们的系统可以实时的收
最近遇到一个问题，对四千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
[解决办法]能不能按照日期每天生成一个表，这样一个表中的数据就不会太大！
对表操作的冲突就会大大减少，不过这样做你的程序肯定也要相应的改动！
从固定操作一个表变成动态操作表！
[解决办法] 头疼的并发问题
[解决办法]这么好的问题不能让沉了，顶起来等高手解答
[解决办法]系统设计上有问题
把问题分散,不要把一个月的数据集中到一天处理
[解决办法]我也同意把问题分散
[解决办法]我同意散分，哈哈。
