4.2、设计工具和版本划分；1、使用ER-WIN设计数据库，同时设计逻辑视图；2、开发过程中尽量保证设计文档和物理表结构的一致；3、数据库分开发期和运行期两个版本：开发期版本主；6、数据库优化；6.1、数据库性能优化规范（运行期）；1、在运行阶段删除不必要的约束(check)；2、尽量不要使用触发器；3、尽量保留主键约束；4、适当删除外键，以提高性能；5、在
4.2、设计工具和版本划分
1、使用ER-WIN设计数据库，同时设计逻辑视图和物理视图（也可以是PowerDesigner等工具，通过ER图形表示出数据表之间的关系）
2、开发过程中尽量保证设计文档和物理表结构的一致变化
3、数据库分开发期和运行期两个版本：开发期版本主要体现完整的约束，运行期版本体现效率的优化。
6、数据库优化
6.1、数据库性能优化规范（运行期）
1、在运行阶段删除不必要的约束(check)。
2、尽量不要使用触发器
3、尽量保留主键约束
4、适当删除外键，以提高性能
5、在运行期间，通过分析系统的访问量，创建索引来优化性能
6、分析每个表可能的数据增长量，定义自动拆分表规则。将大表进行拆分来提高性能。
7、预先考虑数据清理规则：在什么情况下删除数据库中的旧数据，以此来提高性能。
8、制定数据库备份和灾难恢复计划。
9、为效率考虑，可以在系统测试阶段适当增加冗余字段，或者冗余表。
10、分页的记录输出必须通过存储过程来实现，不能使用API游标来分页，这样可以提高分页的效率。
6.2、拆分表示例
案例：网站有200万用户，有很多模块围绕用户提供服务。
为提高效率，每个表最多只保存与用户有关的10万记录，200万条记录拆分到20个表中。编号为1-10万的用户将记录保存到表一，000编号的记录保存到表二，以此类推。
建立一个拆分信息表，表中保存了哪些表是经过拆分的，拆分到什么程度，拆分规则是什么。
当插入记录的时候，首先判断插入这条记录的用户的ID。存储过程根据ID的范围，自动把数据插入到相应的拆分表中去。
当按照条件查询，存储过程自动连接所有的拆分表，丛中筛选出记录。（一般情况下：同类型的查询远远大于按照条件的全体查询）
6.3、冗余字段建立示例
案例：留言本表中，要保存用户的ID作为外键。通常，通过连接留言表和用户表来得知是哪个用户发布了留言。
为提高效率，在留言本表中增建用户名的字段。插入记录的时候，同时保存用户ID和用户名。这样，当查询时，就不必连接两个表，使效率大大提高。
但是，当用户修改用户名时，要吗更新其他表中的用户名，要吗忽略这种用户名不一致的影响。如何处理取决于用户名在模块中的重要程度。
6.4、冗余表建立示例
案例：有用户表和分组表，两个表之间是多对多的关系，建立一个用户与组的关系表来实现这种关系。
用户表中有百万条记录，组表中几千条记录。如果每个用户都属于多个组的化，关联表中将存在几百万条记录。
现在将用户表和关联表进行拆分，拆分规则为用户的ID范围。当查询某用户的组时，效率大大提高。但是当查询某组下的用户时，需要关联所有的拆分表，效率很低。
为提高效率，建立一个冗余的用户和组的关系表，这个关系表中保存第一个关系表中统一的内容，但是拆分规则为组ID的范围。这样，当查询组中的用户时，丛第二个关系表中查询，效率大大提高。
6.5、存储过程中分页方案
1、首先统计得到符合条件的记录数
2、定义表变量：表变量的第一个字段为自增长类型，第二个字段为记录集中的唯一值字段（一般是主键）
3、使用INSERT () SELECT 语句将符合条件的记录的唯一值字段保存在表变量中。
4、使用WHERE ID IN (SELECT ID FROM 表变量 WHERE ??) 的方法从表变量中读出需要的唯一值字段。
1、首先统计符合条件的记录数，并根据页大小计算页数
2、如果读取第一页，直接使用TOP子句读取
3、如果页数在前一半：
结果集1：SELECT TOP
CurPage*PageSize
Fields FROM Table ORDER BY ID ASC 结果集2：SELECT TOP PageSize * FROM (结果集1) ORDER BY ID DESC
最终结果：SELECT * FROM (结果集2) ORDER BY ID ASC
4、如果页数在后一半：
结果集1：SELECT TOP (PageCount-CurPage + 1)*PageSize Fields FROM Table ORDER BY ID
最终结果：SELECT TOP PageSize * FROM Table ORDER BY ID ASC
7、整体优化和物理优化
7.1、查询优化方法
7.1.1、原因
查询速度慢的原因很多，常见如下几种：
1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)。
2、I/O吞吐量小，形成了瓶颈效应。
3、没有创建计算列导致查询不优化。
4、内存不足。
5、网络速度慢。
6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）。
7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)。
8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。
9、返回了不必要的行和列。
10、查询语句不好，没有优化。
7.1.2、查询优化方法
1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb应放在RAID0上，SQL2000不在支持。数据量（尺寸）越大，提高I/O越重要。
2、纵向、横向分割表，减少表的尺寸(sp_spaceuse) 。
3、升级硬件。
4、根据查询条件，建立索引，优化索引、优化访问方式，限制结果集的数据量。注意填充因子要适当（最好是使用默认值0）。索引应该尽量小，使用字节数小的列建索引好（参照索引的创建）,不要对有限的几个值的字段建单一索引如性别字段。
5、提高网速。
6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。配置虚拟内存：虚拟内存大小应基于计算机上并发运行的服务进行配置。运行 Microsoft SQL Server 2000 时，可考虑将虚拟内存大小设置为计算机中安装的物理内存的 1.5 倍。如果另外安装了全文检索功能，并打算运行 Microsoft 搜索服务以便执行全文索引和查询，可考虑：将虚拟内存大小配置为至少是计算机中安装的物理内存的 3 倍。将 SQL Server max server memory 服务器配置选项配置为物理内存的 1.5 倍（虚拟内存大小设置的一半）。
7、增加服务器CPU个数；但是必须明白并行处理串行处理更需要资源例如内存。使用并行还是串行程是MsSQL自动评估选择的。单个任务分解成多个任务，就可以在处理器上运行。例如耽搁查询的排序、连接、扫描和GROUP BY字句同时执行，SQL SERVER根据系统的负载情况决定最优的并行等级，复杂的需要消耗大量的CPU的查询最适合并行处理。但是更新操作UPDATE，INSERT，DELETE还不能并行处理。
8、如果是使用like进行查询的话，简单的使用index是不行的，但是全文索引，耗空间。 like 'a%' 使用索引；like '%a' 不使用索引；用 like '%a%' 查询时，查询耗时和字段值总长度成正比，所以不能用CHAR类型，而是VARCHAR。对于字段的值很长的建全文索引。
9、DB Server 和APPLication Server 分离；OLTP和OLAP分离。
10、分布式分区视图可用于实现数据库服务器联合体。联合体是一组分开管理的服务器，但它们相互协作分担系统的处理负荷。这种通过分区数据形成数据库服务器联合体的机制能够扩大一组服务器，以支持大型的多层 Web 站点的处理需要。有关更多信息，参见设计联合数据库服务器。（参照SQL帮助文件'分区视图'）：
a、在实现分区视图之前，必须先水平分区表。
b、在创建成员表后，在每个成员服务器上定义一个分布式分区视图，并且每个视图具有相同的名称。这样，引用分布式分区视图名的查询可以在任何一个成员服务器上运行。系统操作如同每个成员服务器上都有一个原始表的复本一样，但其实每个服务器上只有一个成员表和一个分布式分区视图。数据的位置对应用程序是透明的。
11、重建索引DBCC REINDEX，DBCC INDEXDEFRAG，收缩数据和日志 DBCC SHRINKDB，DBCC SHRINKFILE设置自动收缩日志。对于大的数据库不要设置数据库自动增长，它会降低服务器的性能。在T-sql的写法上有很大的讲究，下面列出常见的要点：首先，DBMS处理查询计划的过程是这样的：
a、 查询语句的词法、语法检查；
b、 将语句提交给DBMS的查询优化器；
c、 优化器做代数优化和存取路径的优化；
d、 由预编译模块生成查询规划；
e、 然后在合适的时间提交给系统处理执行；
f、 最后将执行结果返回给用户其次，看一下SQL SERVER的数据存放的结构：一个页
面的大小为8K(8060)字节，8个页面为一个盘区，按照B树存放。
12、Commit和rollback的区别：Rollback:回滚所有的事务。 Commit:提交当前的事务。没有必要在动态SQL里写事务，如果要写请写在外面如：
BEGIN TRANS
COMMIT TRANS
或者将动态SQL 写成函数或者存储过程。
13、在查询SELECT语句中用WHERE字句限制返回的行数，避免表扫描，如果返回不必要的数据，浪费了服务器的I/O资源，加重了网络的负担降低性能。如果表很大，在表扫描的期间将表锁住，禁止其他的联接访问表，后果严重。
14、SQL的注释申明对执行没有任何影响。
15、尽可能不使用光标，它占用大量的资源。如果需要row-by-row地执行，尽量采用非光标技术，如：在客户端循环，用临时表，Table变量，用子查询，用CASE语句等等。游标可以按照它所支持的提取选项进行分类：
?只进：必须按照从第一行到最后一行的顺序提取行。FETCH NEXT 是唯一允许的提取操
作,也是默认方式。
?可滚动性：可以在游标中任何地方随机提取任意行。游标的技术在SQL2000下变得功能
很强大，他的目的是支持循环。有四个并发选项
READ_ONLY：不允许通过游标定位更新(Update)，且在组成结果集的行中没有锁。
OPTIMISTIC WITH valueS：乐观并发控制是事务控制理论的一个标准部分。乐观并发控制用于这样的情形，即在打开游标及更新行的间隔中，只有很小的机会让第二个用户更新某一行。当某个游标以此选项打开时，没有锁控制其中的行，这将有助于最大化其处理能力。如果用户试图修改某一行，则此行的当前值会与最后一次提取此行时获取的值进行比较。如果任何值发生改变，则服务器就会知道其他人已更新了此行，并会返回一个错误。如果值是一样的，服务器就执行修改。选择这个并发选项。
OPTIMISTIC WITH ROW VERSIONING：此乐观并发控制选项基于行版本控制。使用行版本控制，其中的表必须具有某种版本标识符，服务器可用它来确定该行在读入游标后是否有所更改。在 SQL Server 中，这个性能由 timestamp 数据类型提供，它是一个二进制数字，表示数据库中更改的相对顺序。每个数据库都有一个全局当前时间戳值：@@DBTS。每次以任何方式更改带有 timestamp 列的行时，SQL Server 先在时间戳列中存储当前的 @@DBTS 值，然后增加 @@DBTS 的值。如果某 个表具有 timestamp 列，则时间戳会被记到行级。服务器就可以比较某行的当前时间戳值和上次提取时所存储的时间戳值，从而确定该行是否已更新。服务器不必比较所有列的值，只需比较 timestamp 列即可。如果应用程序对没有 timestamp 列的表要求基于行版本控制的乐观并发，则游标默认为基于数值的乐观并发控制。
SCROLL LOCKS：这个选项实现悲观并发控制。在悲观并发控制中，在把数据库的行读入游标结果集时，应用程序将试图锁定数据库行。在使用服务器游标时，将行读入游标时会在其上放置一个更新锁。如果在事务内打开游标，则该事务更新锁将一直保持到事务被提交或回滚；当提取下一行时，将除去游标锁。如果在事务外打开游标，则提取下一行时，锁就被丢弃。因此，每当用户需要完全的悲观并发控制时，游标都应在事务内打开。更新锁将阻止任何其它任务获取更新锁或排它锁，从而阻止其它任务更新该行。然而，更新锁并不阻止共享锁，所以它不会阻止其它任务读取行，除非第二个任务也在要求带更新锁的读取。滚动锁根据在游标定义的 SELECT 语句中指定的锁提示，这些游标并发选项可以生成滚动锁。滚动锁在提取时在每行上获取，并保持到下次提取或者游标关闭，以先发生者为准。下次提取时，服务器为新提取中的行获取滚动锁，并释放上次提取中行的滚动锁。滚动锁独立于事务锁，并可以保持到一个提交或回滚操作之后。如果提交时关闭游标的选项为关，则 COMMIT 语句并不关闭任何打开的游标，而且滚动锁被保留到提交之后，以维护对所提取数据的隔离。所获取滚动锁的类型取决于游标并发选项和游标 SELECT 语句中的锁提示。
16、用Profiler来跟踪查询，得到查询所需的时间，找出SQL的问题所在;用索引优化器优化索引。
17、注意UNION和UNION ALL 的区别。UNION ALL好。
18、注意使用DISTINCT，在没有必要时不要用，它同UNION一样会使查询变慢。重复的记录在查询里是没有问题的。
19、查询时不要返回不需要的行、列。
20、用sp_configure 'query governor cost limit'或者SET QUERY_GOVERNOR_COST_LIMIT来限制查询消耗的资源。当评估查询消耗的资源超出限制时，服务器自动取消查询,在查询
包含各类专业文献、各类资格考试、专业论文、文学作品欣赏、高等教育、外语学习资料、应用写作文书、幼儿教育、小学教育、数据库开发规范70等内容。　
　数据库设计规范、 技巧与命名规范一、数据库设计过程 数据库技术是信息资源管理...开始,确定建模目标,开发建模计划,组织建模队伍,收集源材 料,制定约束和 规范。... 　1.3 关键词编程规范、数据库、ORACLE、PL/SQL 1.4 术语和定义本规范采用以下的术语描述: ★ 规则 规则:编程时强制必须遵守 强制必须遵守的原则。 强制必须遵守 ... 　16 数据库编程规范 4 / 19 合肥 第一部分 概述 1.1 文档目的本文档的编写目的是为了项目开发人员在使用数据库的过程中, 使用统一的命名和编码 规范,使数据库... 　MySQL数据库开发规范1.3_互联网_IT/计算机_专业资料。mysql库的开发规范 平安金融科技 数据库(MySQL)开发规范 作者: 简朝阳 Last Updated: 25/02/14 19:30:18... 　禁止使用空格 在数据库对象命名时,禁止使用空格。第 6 页共 20 页 SQL SERVER 数据库开发规范 第二章 常用数据类型下面是我们再数据库设计中常用的几种数据类型... 　第3章 使用规范 3.1 综合 ? 数据库的结构只有数据库管理员能够修改,避免开发人员自己增加数据库对象或者 重庆艾思博科技有限公司 修改数据库对象。若要修改,需要... 　数据库设计规范_计算机软件及应用_IT/计算机_专业资料。在javaweb项目中,规范数据库的整体设计,便于项目的开发维护 数据库设计规范目的为规范数据库管理,统一数据库... 　5) 编制文档 对所有的快捷方式、MYSQL 数据库命名规范、限制和函数都要编制文档. 采用给表、列、触发器等加注释的数据库工具.对开发、支持和跟踪修改非常有用. ... 　数据库设计规范 V00.01.000 第 1 页共 25 页 历史版本 版本 V00.00.001 类型新建 日期
作者苏寒 说明集合项目现状,参考部分资料 编写成稿 第...十万条记录，求高效更新SQL -oracle- TryCatch
>> Content
十万条记录，求高效更新SQL
卡和担保人之间1对多关系，现在要把3个担保人信息guaranty放入卡信息表card中。对于超过3个担保人的卡随机取3个担保人信息既可。现在的处理方式是写了个存储过程，定义两个游标，分别是卡和担保人，取出每张卡信息，再根据卡号查到担保人，然后写入卡信息表。但这样效率很低，3个小时只更新了15000条。求高效方法，可以建索引、临时表、存储过程等数据库可以使用的技术。网上看过纵列转横列的方法，但都不知道怎么给整进来。数据表信息卡信息有11万条，担保信息有10万条。两个担保人的卡有5000张，三个担保人的有3000个，四个担保人的有500个卡信息表cardcreate&table&card&(卡号&varchar2(32)&not&null,担保人1&varchar2(20),担保人1证件号&varchar2(32),担保人1电话&varchar2(20),担保人2&varchar2(20),担保人2证件号&varchar2(32),担保人2电话&varchar2(20),担保人3&varchar2(20),担保人3证件号&varchar2(32),担保人3电话&varchar2(20))担保人表guarantycreate&table&guaranty&(cardno&varchar2(32),--卡号ownername&varhcar2(20),&--&担保人姓名certid&varchar2(32),&--&证件号tel&varchar2(20)&--&电话)数据:&card卡号,担保人1,担保人1证件号,担保人1电话,担保人2,担保人2证件号,担保人2电话,担保人3,担保人3证件号,担保人3电话c1,null,null,null,null,null,null,null,null,nullc2,null,null,null,null,null,null,null,null,nullc3,null,null,null,null,null,null,null,null,nullc4,null,null,null,null,null,null,null,null,nullc5,null,null,null,null,null,null,null,null,nullc6,null,null,null,null,null,null,null,null,nullc7,null,null,null,null,null,null,null,null,nullc8,null,null,null,null,null,null,null,null,nullguarantycardno,ownername,certid,telc1,name1,id1,tel1c1,name2,id2,tel2c2,name3,id3,tel3c2,name4,id4,tel4c2,name5,id5,tel5c2,name6,id6,tel6c3,name7,id7,tel7c4,name8,id8,tel8希望得到最终结果：卡号,担保人1,担保人1证件号,担保人1电话,担保人2,担保人2证件号,担保人2电话,担保人3,担保人3证件号,担保人3电话c1,name1,id1,tel1,name2,id2,tel2,null,null,nullc2,name3,id3,tel3,name4,id4,tel4,name5,id5,tel5c3,name7,id7,tel7,null,null,null,null,null,nullc4,name8,id8,tel8,null,null,null,null,null,nullc5,null,null,null,null,null,null,null,null,nullc6,null,null,null,null,null,null,null,null,nullc7,null,null,null,null,null,null,null,null,nullc8,null,null,null,null,null,null,null,null,null
------Solutions------
;with&bas(select&*,ROW_NUMBER()over(partition&by&cardno&order&by&cardno)&as&row&from&guaranty)update&aset&担保人1=b.ownername,担保人1证件号=b.certid,担保人1电话=b.tel,担保人2=c.ownername,担保人2证件号=c.certid,担保人2电话=c.tel,担保人3=d.ownername,担保人3证件号=d.certid,担保人3电话=d.telfrom&"card"&as&aleft&join&b&on&a.卡号=b.cardno&and&b.row=1left&join&b&as&c&on&a.卡号=c.cardno&and&c.row=2left&join&b&as&d&on&a.卡号=d.cardno&and&c.row=3guaranty--有没有列区分大小的，如同一个卡的，第1个和第2个担保人
------Solutions------
通过视图方式更新，分3次执行，分别填充担保人1、2、3的数据。UPDATE&&(SELECT&*&&&&&FROM&&&&&&&&&(SELECT&GUARANTY.*,ROW_NUMBER()&OVER(PARTITION&BY&CARDNO)RN&FROM&GUARANTY&)&A,&&&&&&&&&CARD&&&WHERE&A.RN&=&1&AND&CARD.CARDNO&=&A.CARDNO)SET&CARD.担保人1&=&A.OWNERNAME,&&&&CARD.担保人1证件号&=&A.CERTID,&&&&CARD.担保人1电话&=&A.TEL;UPDATE&&(SELECT&*&&&&&FROM&&&&&&&&&(SELECT&GUARANTY.*,ROW_NUMBER()&OVER(PARTITION&BY&CARDNO)RN&FROM&GUARANTY&)&A,&&&&&&&&&CARD&&&WHERE&A.RN&=&2&AND&CARD.CARDNO&=&A.CARDNO)SET&CARD.担保人2&=&A.OWNERNAME,&&&&CARD.担保人2证件号&=&A.CERTID,&&&&CARD.担保人2电话&=&A.TEL;UPDATE&&(SELECT&*&&&&&FROM&&&&&&&&&(SELECT&GUARANTY.*,ROW_NUMBER()&OVER(PARTITION&BY&CARDNO)RN&FROM&GUARANTY&)&A,&&&&&&&&&CARD&&&WHERE&A.RN&=&3&AND&CARD.CARDNO&=&A.CARDNO)SET&CARD.担保人3&=&A.OWNERNAME,&&&&CARD.担保人3证件号&=&A.CERTID,&&&&CARD.担保人3电话&=&A.TEL;
------Solutions------
create&table&tmp_guarantyasselect&cardno&as&"卡号",&&&&&&&&&&&&&&&max(case&when&isort&=&1&then&cardno&else&null&end)&as&"担保人1",&&&&&&&&&&&&&&max(case&when&isort&=&1&then&certid&else&null&end)&as&"担保人1证件号",&&&&&&&&&&&&&&max(case&when&isort&=&1&then&tel&else&null&end)&as&"担保人1电话",&&&&&&&&&&&&&&max(case&when&isort&=&2&then&cardno&else&null&end)&as&"担保人2",&&&&&&&&&&&&&&max(case&when&isort&=&2&then&certid&else&null&end)&as&"担保人2证件号",&&&&&&&&&&&&&&max(case&when&isort&=&2&then&tel&else&null&end)&as&"担保人2电话",&&&&&&&&&&&&&&max(case&when&isort&=&3&then&cardno&else&null&end)&as&"担保人3",&&&&&&&&&&&&&&max(case&when&isort&=&3&then&certid&else&null&end)&as&"担保人3证件号",&&&&&&&&&&&&&&max(case&when&isort&=&3&then&tel&else&null&end)&as&"担保人3电话"&&&&&&&&&from&(select&t.*,&row_number()&over(partition&by&cardno&order&by&certid)&as&isort&from&guaranty&t)&&&&&&&&where&isort&&=&3&&&&&&&&group&by&merge&into&card&ausing&tmp_guaranty&b&&&on&(a.卡号&=&b.卡号)&when&matched&thenupdate&set&a.担保人1&=&&&&&&&&b.担保人1,&&&&&&&&&&&a.担保人1证件号&=&&b.担保人1证件号,&&&&&&&&&&&a.担保人1电话&=&&&&b.担保人1电话,&&&&&&&&&&&a.担保人2&=&&&&&&&&b.担保人2,&&&&&&&&&&&a.担保人2证件号&=&&b.担保人2证件号,&&&&&&&&&&&a.担保人2电话&=&&&&b.担保人2电话,&&&&&&&&&&&a.担保人3&=&&&&&&&&b.担保人3,&&&&&&&&&&&a.担保人3证件号&=&&b.担保人3证件号,&&&&&&&&&&&a.担保人3电话&=&&&&b.担保人3电话;
------Solutions------
create&table&new_cardasselect&c.卡号,&&&&&&&&g.担保人1,&g.担保人1证件号,&g.担保人1电话,&&&&&&&g.担保人2,&g.担保人2证件号,&g.担保人2电话,&&&&&&&g.担保人3,&g.担保人3证件号,&g.担保人3电话&&from&card&c,&&&&&&&&(select&cardno&as&"卡号",&&&&&&&&&&&&&&&&max(case&when&isort&=&1&then&cardno&else&null&end)&as&"担保人1",&&&&&&&&&&&&&&&max(case&when&isort&=&1&then&certid&else&null&end)&as&"担保人1证件号",&&&&&&&&&&&&&&&max(case&when&isort&=&1&then&tel&else&null&end)&as&"担保人1电话",&&&&&&&&&&&&&&&max(case&when&isort&=&2&then&cardno&else&null&end)&as&"担保人2",&&&&&&&&&&&&&&&max(case&when&isort&=&2&then&certid&else&null&end)&as&"担保人2证件号",&&&&&&&&&&&&&&&max(case&when&isort&=&2&then&tel&else&null&end)&as&"担保人2电话",&&&&&&&&&&&&&&&max(case&when&isort&=&3&then&cardno&else&null&end)&as&"担保人3",&&&&&&&&&&&&&&&max(case&when&isort&=&3&then&certid&else&null&end)&as&"担保人3证件号",&&&&&&&&&&&&&&&max(case&when&isort&=&3&then&tel&else&null&end)&as&"担保人3电话"&&&&&&&&&&from&(select&t.*,&row_number()&over(partition&by&cardno&order&by&certid)&as&isort&from&guaranty&t)&&&&&&&&&where&isort&&=&3&&&&&&&&&group&by&cardno)&g&where&c.卡号&=&g.卡号;rename&card&to&card_rename&new_card&to&
------Solutions------
才10万条记录就解决不了了？我做了下测试我在虚拟机里30万条记录更新也就几分钟而已，用特殊方法2分钟就搞定了sql语句上面都给得很全但方法都基本就两种，第一。根据guaranty表构造出一个card子表利用card子表与card表关联来更新card表第二。根据guaranty表&利用create&table&as&select&语句建一个新的card表，然后将新card表改名针对这两种方法操作难度根据你对你的库的熟悉度和oracle熟悉程度来采用
------Solutions------
我也觉得10万是个很小的数量，但真正执行的时候花了很长时间，明天我去实验一下
------Solutions------
with&bas(select&*,ROW_NUMBER()over(partition&by&cardno&order&by&cardno)&as&row&from&guaranty)update&aset&担保人1=b.ownername,担保人1证件号=b.certid,担保人1电话=b.tel,担保人2=c.ownername,担保人2证件号=c.certid,担保人2电话=c.tel,担保人3=d.ownername,担保人3证件号=d.certid,担保人3电话=d.telfrom&"card"&as&a&&&&left&join&b&on&a.卡号=b.cardno&and&b.row=1&&&&left&join&b&as&c&on&a.卡号=c.cardno&and&c.row=2&&&&left&join&b&as&d&on&a.卡号=d.cardno&and&c.row=3--OK!博客访问： 3014
博文数量： 1
注册时间：
ITPUB论坛APP
ITPUB论坛APP
APP发帖 享双倍积分
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
发布时间： 16:02:01
&&&& 最近一直在学习SQL Server 2005 ，原有的项目中很多的地方用到了游标，效率很低，三个表联合查询，把结果更新到另外一个表中时，由于表的数据量较大，A表达到了1500万条、B表600万、C表300.........
阅读(1643) | 评论(0) | 转发(0)
给主人留下些什么吧！~~
请登录后留言。2008年2月 MS-SQL Server大版内专家分月排行榜第二2007年7月 MS-SQL Server大版内专家分月排行榜第二2002年3月 MS-SQL Server大版内专家分月排行榜第二2002年1月 MS-SQL Server大版内专家分月排行榜第二2001年12月 MS-SQL Server大版内专家分月排行榜第二
2013年2月 MS-SQL Server大版内专家分月排行榜第三
2011年 总版技术专家分年内排行榜第四2010年 总版技术专家分年内排行榜第九2009年 总版技术专家分年内排行榜第八
2011年10月 总版技术专家分月排行榜第一
2011年8月 总版技术专家分月排行榜第三
2012年10月 荣获微软MVP称号2011年10月 荣获微软MVP称号
本帖子已过去太久远了，不再提供回复功能。