linji

三清山游

52775569@qq.com(linji) — Sun, 05 Jul 2009 12:00:15 GMT

上海宝石园→三山假日宾馆→南部索道→神龙山庄→西海岸→三清山顶。

SQL聚集索引和非聚集索引

52775569@qq.com(linji) — Sat, 27 Jun 2009 03:30:14 GMT

微软的SQL SERVER提供了两种索引：聚集索引(clustered index，也称聚类索引、簇集索引)和非聚集索引(nonclustered index，也称非聚类索引、非簇集索引)……
　　(一)深入浅出理解索引结构
　　实际上，您可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引：聚集索引(clustered index，也称聚类索引、簇集索引)和非聚集索引(nonclustered index，也称非聚类索引、非簇集索引)。下面，我们举例来说明一下聚集索引和非聚集索引的区别：
　　其实，我们的汉语字典的正文本身就是一个聚集索引。比如，我们要查“安”字，就会很自然地翻开字典的前几页，因为“安”的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个字;同样的，如果查“张”字，那您也会将您的字典翻到最后部分，因为“张”的拼音是“zhang”。也就是说，字典的正文部分本身就是一个目录，您不需要再去查其他目录来找到您需要找的内容。
　　我们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。
　　如果您认识某个字，您可以快速地从自典中查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而需要去根据“偏旁部首”查到您要找的字，然后根据这个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“张”字，我们可以看到在查部首之后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码却是63页，“张”的下面是“弩”字，页面是390页。很显然，这些字并不是真正的分别位于“张”字的上下方，现在您看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。
　　我们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。
　　通过以上例子，我们可以理解到什么是“聚集索引”和“非聚集索引”。
　　进一步引申一下，我们可以很容易的理解：每个表只能有一个聚集索引，因为目录只能按照一种方法进行排序。
　　(二)何时使用聚集索引或非聚集索引
　　下面的表总结了何时使用聚集索引或非聚集索引(很重要)。
动作描述使用聚集索引使用非聚集索引
外键列应应
主键列应应
列经常被分组排序(order by) 应应
返回某范围内的数据应不应
小数目的不同值应不应
大数目的不同值不应应
频繁更新的列不应应
频繁修改索引列不应应
一个或极少不同值不应不应
　　事实上，我们可以通过前面聚集索引和非聚集索引的定义的例子来理解上表。如：返回某范围内的数据一项。比如您的某个表有一个时间列，恰好您把聚合索引建立在了该列，这时您查询2004年1月1日至2004年10月1日之间的全部数据时，这个速度就将是很快的，因为您的这本字典正文是按日期进行排序的，聚类索引只需要找到要检索的所有数据中的开头和结尾数据即可;而不像非聚集索引，必须先查到目录中查到每一项数据对应的页码，然后再根据页码查到具体内容。
　(三)结合实际，谈索引使用的误区
　　理论的目的是应用。虽然我们刚才列出了何时应使用聚集索引或非聚集索引，但在实践中以上规则却很容易被忽视或不能根据实际情况进行综合分析。下面我们将根据在实践中遇到的实际问题来谈一下索引使用的误区，以便于大家掌握索引建立的方法。
　　1、主键就是聚集索引
　　这种想法笔者认为是极端错误的，是对聚集索引的一种浪费。虽然SQL SERVER默认是在主键上建立聚集索引的。
　　通常，我们会在每个表中都建立一个ID列，以区分每条数据，并且这个ID列是自动增大的，步长一般为1。我们的这个办公自动化的实例中的列 Gid就是如此。此时，如果我们将这个列设为主键，SQL SERVER会将此列默认为聚集索引。这样做有好处，就是可以让您的数据在数据库中按照ID进行物理排序，但笔者认为这样做意义不大。
　　显而易见，聚集索引的优势是很明显的，而每个表中只能有一个聚集索引的规则，这使得聚集索引变得更加珍贵。
　　从我们前面谈到的聚集索引的定义我们可以看出，使用聚集索引的最大好处就是能够根据查询要求，迅速缩小查询范围，避免全表扫描。在实际应用中，因为ID号是自动生成的，我们并不知道每条记录的ID号，所以我们很难在实践中用ID号来进行查询。这就使让ID号这个主键作为聚集索引成为一种资源浪费。其次，让每个ID号都不同的字段作为聚集索引也不符合“大数目的不同值情况下不应建立聚合索引”规则;当然，这种情况只是针对用户经常修改记录内容，特别是索引项的时候会负作用，但对于查询速度并没有影响。
　　在办公自动化系统中，无论是系统首页显示的需要用户签收的文件、会议还是用户进行文件查询等任何情况下进行数据查询都离不开字段的是“日期”还有用户本身的“用户名”。
　　通常，办公自动化的首页会显示每个用户尚未签收的文件或会议。虽然我们的where语句可以仅仅限制当前用户尚未签收的情况，但如果您的系统已建立了很长时间，并且数据量很大，那么，每次每个用户打开首页的时候都进行一次全表扫描，这样做意义是不大的，绝大多数的用户1个月前的文件都已经浏览过了，这样做只能徒增数据库的开销而已。事实上，我们完全可以让用户打开系统首页时，数据库仅仅查询这个用户近3个月来未阅览的文件，通过“日期”这个字段来限制表扫描，提高查询速度。如果您的办公自动化系统已经建立的2年，那么您的首页显示速度理论上将是原来速度8倍，甚至更快。
　　在这里之所以提到“理论上”三字，是因为如果您的聚集索引还是盲目地建在ID这个主键上时，您的查询速度是没有这么高的，即使您在“日期”这个字段上建立的索引(非聚合索引)。下面我们就来看一下在1000万条数据量的情况下各种查询的速度表现(3个月内的数据为25万条)：
　　(1)仅在主键上建立聚集索引，并且不划分时间段：
　　Select gid,fariqi,neibuyonghu,title from tgongwen
　　用时：128470毫秒(即：128秒)
　　(2)在主键上建立聚集索引，在fariq上建立非聚集索引：
　　select gid,fariqi,neibuyonghu,title from Tgongwen
　　where fariqi> dateadd(day,-90,getdate())
　　用时：53763毫秒(54秒)
　　(3)将聚合索引建立在日期列(fariqi)上：
　　select gid,fariqi,neibuyonghu,title from Tgongwen
　　where fariqi> dateadd(day,-90,getdate())
　　用时：2423毫秒(2秒)
　　虽然每条语句提取出来的都是25万条数据，各种情况的差异却是巨大的，特别是将聚集索引建立在日期列时的差异。事实上，如果您的数据库真的有 1000万容量的话，把主键建立在ID列上，就像以上的第1、2种情况，在网页上的表现就是超时，根本就无法显示。这也是我摒弃ID列作为聚集索引的一个最重要的因素。
　　得出以上速度的方法是：在各个select语句前加：
　　declare @d datetime
　　set @d=getdate()
　　并在select语句后加：
　　select [语句执行花费时间(毫秒)]=datediff(ms,@d,getdate())
　2、只要建立索引就能显著提高查询速度
　　事实上，我们可以发现上面的例子中，第2、3条语句完全相同，且建立索引的字段也相同;不同的仅是前者在fariqi字段上建立的是非聚合索引，后者在此字段上建立的是聚合索引，但查询速度却有着天壤之别。所以，并非是在任何字段上简单地建立索引就能提高查询速度。
　　从建表的语句中，我们可以看到这个有着1000万数据的表中fariqi字段有5003个不同记录。在此字段上建立聚合索引是再合适不过了。在现实中，我们每天都会发几个文件，这几个文件的发文日期就相同，这完全符合建立聚集索引要求的：“既不能绝大多数都相同，又不能只有极少数相同”的规则。由此看来，我们建立“适当”的聚合索引对于我们提高查询速度是非常重要的。
　　3、把所有需要提高查询速度的字段都加进聚集索引，以提高查询速度
　　上面已经谈到：在进行数据查询时都离不开字段的是“日期”还有用户本身的“用户名”。既然这两个字段都是如此的重要，我们可以把他们合并起来，建立一个复合索引(compound index)。
　　很多人认为只要把任何字段加进聚集索引，就能提高查询速度，也有人感到迷惑：如果把复合的聚集索引字段分开查询，那么查询速度会减慢吗?带着这个问题，我们来看一下以下的查询速度(结果集都是25万条数据)：(日期列fariqi首先排在复合聚集索引的起始列，用户名neibuyonghu排在后列)
　　(1)select gid,fariqi,neibuyonghu,title from Tgongwen
　　where fariqi>'2004-5-5'
　　查询速度：2513毫秒
　　(2)select gid,fariqi,neibuyonghu,title from Tgongwen
　　where fariqi>'2004-5-5' and neibuyonghu='办公室'
　　查询速度：2516毫秒
　　(3)select gid,fariqi,neibuyonghu,title from Tgongwen
　　where neibuyonghu='办公室'
　　查询速度：60280毫秒
　　从以上试验中，我们可以看到如果仅用聚集索引的起始列作为查询条件和同时用到复合聚集索引的全部列的查询速度是几乎一样的，甚至比用上全部的复合索引列还要略快(在查询结果集数目一样的情况下);而如果仅用复合聚集索引的非起始列作为查询条件的话，这个索引是不起任何作用的。当然，语句1、2的查询速度一样是因为查询的条目数一样，如果复合索引的所有列都用上，而且查询结果少的话，这样就会形成“索引覆盖”，因而性能可以达到最优。同时，请记住：无论您是否经常使用聚合索引的其他列，但其前导列一定要是使用最频繁的列。
　　(四)其他书上没有的索引使用经验总结
　　1、用聚合索引比用不是聚合索引的主键速度快
　　下面是实例语句：(都是提取25万条数据)
　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen
　　where fariqi='2004-9-16'
　　使用时间：3326毫秒
　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid<=250000
　　使用时间：4470毫秒
　　这里，用聚合索引比用不是聚合索引的主键速度快了近1/4。
　　2、用聚合索引比用一般的主键作order by时速度快，特别是在小数据量情况下
　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by fariqi
　　用时：12936
　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by gid
　　用时：18843
　　这里，用聚合索引比用一般的主键作order by时，速度快了3/10。事实上，如果数据量很小的话，用聚集索引作为排序列要比使用非聚集索引速度快得明显的多;而数据量如果很大的话，如10万以上，则二者的速度差别不明显。
　　3、使用聚合索引内的时间段，搜索时间会按数据占整个数据表的百分比成比例减少，而无论聚合索引使用了多少个
　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen
　　where fariqi>'2004-1-1'
　　用时：6343毫秒(提取100万条)
　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen
　　where fariqi>'2004-6-6'
　　用时：3170毫秒(提取50万条)
　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen
　　where fariqi='2004-9-16'
　　用时：3326毫秒(和上句的结果一模一样。如果采集的数量一样，那么用大于号和等于号是一样的)
　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen
　　where fariqi>'2004-1-1' and fariqi<'2004-6-6'
　　用时：3280毫秒
　　4 、日期列不会因为有分秒的输入而减慢查询速度
　　下面的例子中，共有100万条数据，2004年1月1日以后的数据有50万条，但只有两个不同的日期，日期精确到日;之前有数据50万条，有5000个不同的日期，日期精确到秒。
　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen
　　where fariqi>'2004-1-1' order by fariqi
　　用时：6390毫秒
　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen
　　where fariqi<'2004-1-1' order by fariqi
　　用时：6453毫秒
　　(五)其他注意事项
　　“水可载舟，亦可覆舟”，索引也一样。索引有助于提高检索性能，但过多或不当的索引也会导致系统低效。过多的索引甚至会导致索引碎片。
　　索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。
　　1. 不要索引常用的小型表
　　不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。
　　2. 不要把社会保障号码(SSN)或身份证号码(ID)选作键
　　永远都不要使用 SSN 或 ID 作为数据库的键。除了隐私原因以外，SSN 或 ID 需要手工输入。永远不要使用手工输入的键作为主键，因为一旦你输入错误，你唯一能做的就是删除整个记录然后从头开始。
　　3. 不要用用户的键
　　在确定采用什么字段作为表的键的时候，可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可编辑的字段作为键。这样做会迫使你采取以下两个措施：
　　4. 不要索引 memo/notes 字段和不要索引大型文本字段(许多字符)
　　这样做会让你的索引占据大量的数据库空间
　　5. 使用系统生成的主键
　　假如你总是在设计数据库的时候采用系统生成的键作为主键，那么你实际控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。
　　采用系统生成键作为主键还有一个优点：当你拥有一致的键结构时，找到逻辑缺陷很容易。
　　二、改善SQL语句
　　很多人不知道SQL语句在SQL SERVER中是如何执行的，他们担心自己所写的SQL语句会被SQL SERVER误解。比如：
　　select * from table1 where name='zhangsan' and tID > 10000
　　和执行:
　　select * from table1 where tID > 10000 and name='zhangsan'
　　一些人不知道以上两条语句的执行效率是否一样，因为如果简单的从语句先后上看，这两个语句的确是不一样，如果tID是一个聚合索引，那么后一句仅仅从表的10000条以后的记录中查找就行了;而前一句则要先从全表中查找看有几个name='zhangsan'的，而后再根据限制条件条件 tID>10000来提出查询结果。
　　事实上，这样的担心是不必要的。SQL SERVER中有一个“查询分析优化器”，它可以计算出where子句中的搜索条件并确定哪个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。
　　虽然查询优化器可以根据where子句自动的进行查询优化，但大家仍然有必要了解一下“查询优化器”的工作原理，如非这样，有时查询优化器就会不按照您的本意进行快速查询。
　　在查询分析阶段，查询优化器查看查询的每个阶段并决定限制需要扫描的数据量是否有用。如果一个阶段可以被用作一个扫描参数(SARG)，那么就称之为可优化的，并且可以利用索引快速获得所需数据。
　　SARG的定义：用于限制搜索的一个操作，因为它通常是指一个特定的匹配，一个值得范围内的匹配或者两个以上条件的AND连接。形式如下：
　　列名操作符 <常数或变量>
　　或
　　<常数或变量> 操作符列名
　　列名可以出现在操作符的一边，而常数或变量出现在操作符的另一边。如：
　　Name=’张三’
　　价格>5000
　　5000<价格
　　Name=’张三’ and 价格>5000
　　如果一个表达式不能满足SARG的形式，那它就无法限制搜索的范围了，也就是SQL SERVER必须对每一行都判断它是否满足WHERE子句中的所有条件。所以一个索引对于不满足SARG形式的表达式来说是无用的。
　　介绍完SARG后，我们来总结一下使用SARG以及在实践中遇到的和某些资料上结论不同的经验：
　　1、Like语句是否属于SARG取决于所使用的通配符的类型
　　如：name like ‘张%’ ，这就属于SARG
　　而：name like ‘%张’ ,就不属于SARG。
　　原因是通配符%在字符串的开通使得索引无法使用。
　　2、or 会引起全表扫描
　　如：Name=’张三’ and 价格>5000 符号SARG，
　　而：Name=’张三’ or 价格>5000 则不符合SARG。
　　使用or会引起全表扫描。
　　3、非操作符、函数引起的不满足SARG形式的语句
　　不满足SARG形式的语句最典型的情况就是包括非操作符的语句，如：NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等，另外还有函数。下面就是几个不满足SARG形式的例子：
　　ABS(价格)<5000
　　Name like ‘%三’
　　有些表达式，如：
　　WHERE 价格*2>5000
　　SQL SERVER也会认为是SARG，SQL SERVER会将此式转化为：
　　WHERE 价格>2500/2
　　但我们不推荐这样使用，因为有时SQL SERVER不能保证这种转化与原始表达式是完全等价的。
　　4、IN 的作用相当与OR
　　语句：
　　Select * from table1 where tid in (2,3)
　　和
　　Select * from table1 where tid=2 or tid=3
　　是一样的，都会引起全表扫描，如果tid上有索引，其索引也会失效。
　　5、尽量少用NOT
　　6、exists 和 in 的执行效率是一样的
　　很多资料上都显示说，exists要比in的执行效率要高，同时应尽可能的用not exists来代替not in。但事实上，我试验了一下，发现二者无论是前面带不带not，二者之间的执行效率都是一样的。因为涉及子查询，我们试验这次用SQL SERVER自带的pubs数据库。运行前我们可以把SQL SERVER的statistics I/O状态打开。
　　(1)select title,price from titles where title_id in
　　(select title_id from sales where qty>30)
　　该句的执行结果为：
　　表 'sales'。扫描计数 18，逻辑读 56 次，物理读 0 次，预读 0 次。
　　表 'titles'。扫描计数 1，逻辑读 2 次，物理读 0 次，预读 0 次。
　　(2)select title,price from titles where exists
　　(select * from sales where sales.title_id=titles.title_id and qty>30)
　　第二句的执行结果为：
　　表 'sales'。扫描计数 18，逻辑读 56 次，物理读 0 次，预读 0 次。
　　表 'titles'。扫描计数 1，逻辑读 2 次，物理读 0 次，预读 0 次。
　　我们从此可以看到用exists和用in的执行效率是一样的。
　　7、用函数charindex()和前面加通配符%的LIKE执行效率一样
　　前面，我们谈到，如果在LIKE前面加上通配符%，那么将会引起全表扫描，所以其执行效率是低下的。但有的资料介绍说，用函数charindex()来代替LIKE速度会有大的提升，经我试验，发现这种说明也是错误的：
　　select gid,title,fariqi,reader from tgongwen
　　where charindex('刑侦支队',reader)>0 and fariqi>'2004-5-5'
　　用时：7秒，另外：扫描计数 4，逻辑读 7155 次，物理读 0 次，预读 0 次。
　　select gid,title,fariqi,reader from tgongwen
　　where reader like '%' + '刑侦支队' + '%' and fariqi>'2004-5-5'
　　用时：7秒，另外：扫描计数 4，逻辑读 7155 次，物理读 0 次，预读 0 次。
　　8、union并不绝对比or的执行效率高
　　我们前面已经谈到了在where子句中使用or会引起全表扫描，一般的，我所见过的资料都是推荐这里用union来代替or。事实证明，这种说法对于大部分都是适用的。
　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen
　　where fariqi='2004-9-16' or gid>9990000
　　用时：68秒。扫描计数 1，逻辑读 404008 次，物理读 283 次，预读 392163 次。
　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen
　　where fariqi='2004-9-16'
　　union
　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid>9990000
　　用时：9秒。扫描计数 8，逻辑读 67489 次，物理读 216 次，预读 7499 次。
　　看来，用union在通常情况下比用or的效率要高的多。
　　但经过试验，笔者发现如果or两边的查询列是一样的话，那么用union则反倒和用or的执行速度差很多，虽然这里union扫描的是索引，而or扫描的是全表。
　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen
　　where fariqi='2004-9-16' or fariqi='2004-2-5'
　　用时：6423毫秒。扫描计数 2，逻辑读 14726 次，物理读 1 次，预读 7176 次。
　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen
　　where fariqi='2004-9-16'
　　union
　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen
　　where fariqi='2004-2-5'
　　用时：11640毫秒。扫描计数 8，逻辑读 14806 次，物理读 108 次，预读 1144 次。
　　9、字段提取要按照“需多少、提多少”的原则，避免“select *”
　　我们来做一个试验：
　　select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc
　　用时：4673毫秒
　　select top 10000 gid,fariqi,title from tgongwen order by gid desc
　　用时：1376毫秒
　　select top 10000 gid,fariqi from tgongwen order by gid desc
　　用时：80毫秒
　　由此看来，我们每少提取一个字段，数据的提取速度就会有相应的提升。提升的速度还要看您舍弃的字段的大小来判断。
　　10、count(*)不比count(字段)慢
　　某些资料上说：用*会统计所有列，显然要比一个世界的列名效率低。这种说法其实是没有根据的。我们来看：
　　select count(*) from Tgongwen
　　用时：1500毫秒
　　select count(gid) from Tgongwen
　　用时：1483毫秒
　　select count(fariqi) from Tgongwen
　　用时：3140毫秒
　　select count(title) from Tgongwen
　　用时：52050毫秒
　　从以上可以看出，如果用count(*)和用count(主键)的速度是相当的，而count(*)却比其他任何除主键以外的字段汇总速度要快，而且字段越长，汇总的速度就越慢。我想，如果用count(*)， SQL SERVER可能会自动查找最小字段来汇总的。当然，如果您直接写count(主键)将会来的更直接些。
　　11、order by按聚集索引列排序效率最高
　　我们来看：(gid是主键，fariqi是聚合索引列)
　　select top 10000 gid,fariqi,reader,title from tgongwen
　　用时：196 毫秒。扫描计数 1，逻辑读 289 次，物理读 1 次，预读 1527 次。
　　select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc
　　用时：4736毫秒。扫描计数 1，逻辑读 55350 次，物理读 10 次，预读 775 次。
　　select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi desc
　　用时：156毫秒。扫描计数 1，逻辑读 289 次，物理读 0 次，预读 0 次。
　　从以上我们可以看出，不排序的速度以及逻辑读次数都是和“order by 聚集索引列” 的速度是相当的，但这些都比“order by 非聚集索引列”的查询速度是快得多的。
　　同时，按照某个字段进行排序的时候，无论是正序还是倒序，速度是基本相当的。
　　12、高效的TOP
　　事实上，在查询和提取超大容量的数据集时，影响数据库响应时间的最大因素不是数据查找，而是物理的I/0操作。如：
　　select top 10 * from (
　　select top 10000 gid,fariqi,title from tgongwen
　　where neibuyonghu='办公室'order by gid desc) as a
　　order by gid asc
　　这条语句，从理论上讲，整条语句的执行时间应该比子句的执行时间长，但事实相反。因为，子句执行后返回的是10000条记录，而整条语句仅返回 10条语句，所以影响数据库响应时间最大的因素是物理I/O操作。而限制物理I/O操作此处的最有效方法之一就是使用TOP关键词了。TOP关键词是 SQL SERVER中经过系统优化过的一个用来提取前几条或前几个百分比数据的词。经笔者在实践中的应用，发现TOP确实很好用，效率也很高。但这个词在另外一个大型数据库ORACLE中却没有，这不能说不是一个遗憾，虽然在ORACLE中可以用其他方法(如：rownumber)来解决。在以后的关于“实现千万级数据的分页显示存储过程”的讨论中，我们就将用到TOP这个关键词。
　　到此为止，我们上面讨论了如何实现从大容量的数据库中快速地查询出您所需要的数据方法。当然，我们介绍的这些方法都是“软”方法，在实践中，我们还要考虑各种“硬”因素，如：网络性能、服务器的性能、操作系统的性能，甚至网卡、交换机等。
转自: http://hi.baidu.com/76997043/blog/item/0a76c92a00b92df2e7cd4052.html

SQL Server数据库优化方案

52775569@qq.com(linji) — Sat, 27 Jun 2009 01:29:22 GMT

查询速度慢的原因很多，常见如下几种：　　1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)
　　2、I/O吞吐量小，形成了瓶颈效应。
　　3、没有创建计算列导致查询不优化。
　　4、内存不足
　　5、网络速度慢
　　6、查询出的数据量过大(可以采用多次查询，其他的方法降低数据量)
　　7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)
　　8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。
　　9、返回了不必要的行和列
　　10、查询语句不好，没有优化
　　可以通过如下方法来优化查询 :
　　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处理查询计划的过程是这样的：
　　11.1、查询语句的词法、语法检查
　　11.2、将语句提交给DBMS的查询优化器
　　11.3、优化器做代数优化和存取路径的优化
　　11.4、由预编译模块生成查询规划
　　11.5、然后在合适的时间提交给系统处理执行
　　11.6、最后将执行结果返回给用户其次，看一下SQL SERVER的数据存放的结构：一个页面的大小为8K(8060)字节，8个页面为一个盘区，按照B树存放。
12、Commit和rollback的区别 Rollback:回滚所有的事物。 Commit:提交当前的事物. 没有必要在动态SQL里写事物，如果要写请写在外面如： begin tran exec(@s) 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 语句中的锁提示。锁提示只读乐观数值乐观行版本控制锁定无提示未锁定未锁定未锁定更新 NOLOCK 未锁定未锁定未锁定未锁定 HOLDLOCK 共享共享共享更新 UPDLOCK 错误更新更新更新 TABLOCKX 错误未锁定未锁定更新其它未锁定未锁定未锁定更新 *指定 NOLOCK 提示将使指定了该提示的表在游标内是只读的。
　　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来限制查询消耗的资源。当评估查询消耗的资源超出限制时，服务器自动取消查询,在查询之前就扼杀掉。 SET LOCKTIME设置锁的时间
21、用select top 100 / 10 Percent 来限制用户返回的行数或者SET ROWCOUNT来限制操作的行
　　22、在SQL2000以前，一般不要用如下的字句: "IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE '%500'"，因为他们不走索引全是表扫描。也不要在Where字句中的列名加函数，如Convert，substring等,如果必须用函数的时候，创建计算列再创建索引来替代.还可以变通写法：Where SUBSTRING(firstname,1,1) = 'm'改为Where firstname like 'm%'(索引扫描)，一定要将函数和列名分开。并且索引不能建得太多和太大。NOT IN会多次扫描表，使用EXISTS、NOT EXISTS ，IN , LEFT OUTER JOIN 来替代，特别是左连接,而Exists比IN更快，最慢的是NOT操作.如果列的值含有空，以前它的索引不起作用，现在2000的优化器能够处理了。相同的是IS NULL，"NOT", "NOT EXISTS", "NOT IN"能优化她，而"<>"等还是不能优化，用不到索引。
　　23、使用Query Analyzer，查看SQL语句的查询计划和评估分析是否是优化的SQL。一般的20%的代码占据了80%的资源，我们优化的重点是这些慢的地方。
　　24、如果使用了IN或者OR等时发现查询没有走索引，使用显示申明指定索引： Select * FROM PersonMember (INDEX = IX_Title) Where processid IN ('男'，'女')
　　25、将需要查询的结果预先计算好放在表中，查询的时候再Select。这在SQL7.0以前是最重要的手段。例如医院的住院费计算。
　　26、MIN() 和 MAX()能使用到合适的索引。
　　27、数据库有一个原则是代码离数据越近越好，所以优先选择Default,依次为Rules,Triggers, Constraint(约束如外健主健CheckUNIQUE……,数据类型的最大长度等等都是约束),Procedure.这样不仅维护工作小，编写程序质量高，并且执行的速度快。
　　28、如果要插入大的二进制值到Image列，使用存储过程，千万不要用内嵌Insert来插入(不知Java是否)。因为这样应用程序首先将二进制值转换成字符串(尺寸是它的两倍)，服务器受到字符后又将他转换成二进制值.存储过程就没有这些动作: 方法：Create procedure p_insert as insert into table(Fimage) values (@image), 在前台调用这个存储过程传入二进制参数，这样处理速度明显改善。
　　29、Between在某些时候比IN 速度更快,Between能够更快地根据索引找到范围。用查询优化器可见到差别。 select * from chineseresume where title in ('男','女') Select * from chineseresume where between '男' and '女' 是一样的。由于in会在比较多次，所以有时会慢些。
　　30、在必要是对全局或者局部临时表创建索引，有时能够提高速度，但不是一定会这样，因为索引也耗费大量的资源。他的创建同是实际表一样。
31、不要建没有作用的事物例如产生报表时，浪费资源。只有在必要使用事物时使用它。
32、用OR的字句可以分解成多个查询，并且通过UNION 连接多个查询。他们的速度只同是否使用索引有关,如果查询需要用到联合索引，用UNION all执行的效率更高.多个OR的字句没有用到索引，改写成UNION的形式再试图与索引匹配。一个关键的问题是否用到索引。
　　33、尽量少用视图，它的效率低。对视图操作比直接对表操作慢,可以用stored procedure来代替她。特别的是不要用视图嵌套,嵌套视图增加了寻找原始资料的难度。我们看视图的本质：它是存放在服务器上的被优化好了的已经产生了查询规划的SQL。对单个表检索数据时，不要使用指向多个表的视图，直接从表检索或者仅仅包含这个表的视图上读，否则增加了不必要的开销,查询受到干扰.为了加快视图的查询，MsSQL增加了视图索引的功能。
　　34、没有必要时不要用DISTINCT和ORDER BY，这些动作可以改在客户端执行。它们增加了额外的开销。这同UNION 和UNION ALL一样的道理。
　　35、在IN后面值的列表中，将出现最频繁的值放在最前面，出现得最少的放在最后面，减少判断的次数。
　　36、当用Select INTO时，它会锁住系统表(sysobjects，sysindexes等等)，阻塞其他的连接的存取。创建临时表时用显示申明语句，而不是 select INTO. drop table t_lxh begin tran select * into t_lxh from chineseresume where name = 'XYZ' --commit 在另一个连接中Select * from sysobjects可以看到 Select INTO 会锁住系统表，Create table 也会锁系统表(不管是临时表还是系统表)。所以千万不要在事物内使用它!!!这样的话如果是经常要用的临时表请使用实表，或者临时表变量。
　　37、一般在GROUP BY 个HAVING字句之前就能剔除多余的行，所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下最优：select 的Where字句选择所有合适的行，Group By用来分组个统计行，Having字句用来剔除多余的分组。这样Group By 个Having的开销小，查询快.对于大的数据行进行分组和Having十分消耗资源。如果Group BY的目的不包括计算，只是分组，那么用Distinct更快
　　38、一次更新多条记录比分多次更新每次一条快,就是说批处理好
　　39、少用临时表，尽量用结果集和Table类性的变量来代替它,Table 类型的变量比临时表好
　　40、在SQL2000下，计算字段是可以索引的，需要满足的条件如下：
　　a、计算字段的表达是确定的
　　b、不能用在TEXT,Ntext，Image数据类型
　　c、必须配制如下选项 ANSI_NULLS = ON, ANSI_PADDINGS = ON, …….
41、尽量将数据的处理工作放在服务器上，减少网络的开销，如使用存储过程。存储过程是编译好、优化过、并且被组织到一个执行规划里、且存储在数据库中的SQL语句，是控制流语言的集合，速度当然快。反复执行的动态SQL,可以使用临时存储过程，该过程(临时表)被放在Tempdb中。以前由于SQL SERVER对复杂的数学计算不支持，所以不得不将这个工作放在其他的层上而增加网络的开销。SQL2000支持UDFs,现在支持复杂的数学计算，函数的返回值不要太大，这样的开销很大。用户自定义函数象光标一样执行的消耗大量的资源，如果返回大的结果采用存储过程
　　42、不要在一句话里再三的使用相同的函数，浪费资源,将结果放在变量里再调用更快
　　43、Select COUNT(*)的效率教低，尽量变通他的写法，而EXISTS快.同时请注意区别： select count(Field of null) from Table 和 select count(Field of NOT null) from Table 的返回值是不同的!!!
　　44、当服务器的内存够多时，配制线程数量 = 最大连接数+5，这样能发挥最大的效率;否则使用配制线程数量<最大连接数启用SQL SERVER的线程池来解决,如果还是数量 = 最大连接数+5，严重的损害服务器的性能。
　　45、按照一定的次序来访问你的表。如果你先锁住表A，再锁住表B，那么在所有的存储过程中都要按照这个顺序来锁定它们。如果你(不经意的)某个存储过程中先锁定表B，再锁定表A，这可能就会导致一个死锁。如果锁定顺序没有被预先详细的设计好，死锁很难被发现
　　46、通过SQL Server Performance Monitor监视相应硬件的负载 Memory: Page Faults / sec计数器如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。
　　Process:
　　1、% DPC Time 指在范例间隔期间处理器用在缓延程序调用(DPC)接收和提供服务的百分比。(DPC 正在运行的为比标准间隔优先权低的间隔)。由于 DPC 是以特权模式执行的，DPC 时间的百分比为特权时间百分比的一部分。这些时间单独计算并且不属于间隔计算总数的一部分。这个总数显示了作为实例时间百分比的平均忙时。
　　2、%Processor Time计数器　如果该参数值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。
　　3、% Privileged Time 指非闲置处理器时间用于特权模式的百分比。(特权模式是为操作系统组件和操纵硬件驱动程序而设计的一种处理模式。它允许直接访问硬件和所有内存。另一种模式为用户模式，它是一种为应用程序、环境分系统和整数分系统设计的一种有限处理模式。操作系统将应用程序线程转换成特权模式以访问操作系统服务)。特权时间的 % 包括为间断和 DPC 提供服务的时间。特权时间比率高可能是由于失败设备产生的大数量的间隔而引起的。这个计数器将平均忙时作为样本时间的一部分显示。
　　4、% User Time表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。 Physical Disk: Curretn Disk Queue Length计数器该值应不超过磁盘数的1.5~2倍。要提高性能，可增加磁盘。 SQLServer:Cache Hit Ratio计数器该值越高越好。如果持续低于80%，应考虑增加内存。注意该参数值是从SQL Server启动后，就一直累加记数，所以运行经过一段时间后，该值将不能反映系统当前值。
　47、分析select emp_name form employee where salary > 3000 在此语句中若salary是Float类型的，则优化器对其进行优化为Convert(float,3000)，因为3000是个整数，我们应在编程时使用3000.0而不要等运行时让DBMS进行转化。同样字符和整型数据的转换。
　　48、查询的关联同写的顺序
　　　　select a.personMemberID, * from chineseresume a,personmember b where personMemberID = b.referenceid and a.personMemberID = 'JCNPRH39681' （A = B ,B = '号码'）
　　
　　select a.personMemberID, * from chineseresume a,personmember b where a.personMemberID = b.referenceid and a.personMemberID = 'JCNPRH39681' and b.referenceid = 'JCNPRH39681' （A = B ,B = '号码'， A = '号码'）
　　
　　select a.personMemberID, * from chineseresume a,personmember b where b.referenceid = 'JCNPRH39681' and a.personMemberID = 'JCNPRH39681' （B = '号码'， A = '号码'）

　　49、
　　(1)IF 没有输入负责人代码 THEN code1=0 code2=9999 ELSE code1=code2=负责人代码 END IF 执行SQL语句为: Select 负责人名 FROM P2000 Where 负责人代码>=:code1 AND负责人代码 <=:code2
　　(2)IF 没有输入负责人代码 THEN 　Select 负责人名 FROM P2000 ELSE code= 负责人代码 Select 负责人代码 FROM P2000 Where 负责人代码=:code END IF 第一种方法只用了一条SQL语句,第二种方法用了两条SQL语句。在没有输入负责人代码时,第二种方法显然比第一种方法执行效率高,因为它没有限制条件; 在输入了负责人代码时,第二种方法仍然比第一种方法效率高,不仅是少了一个限制条件,还因相等运算是最快的查询运算。我们写程序不要怕麻烦
　　50、关于JOBCN现在查询分页的新方法(如下)，用性能优化器分析性能的瓶颈，如果在I/O或者网络的速度上，如下的方法优化切实有效，如果在CPU或者内存上，用现在的方法更好。

另附：存储过程编写经验和优化措施
　　一、适合读者对象：数据库开发程序员，数据库的数据量很多，涉及到对SP(存储过程)的优化的项目开发人员，对数据库有浓厚兴趣的人。
　　二、介绍：在数据库的开发过程中，经常会遇到复杂的业务逻辑和对数据库的操作，这个时候就会用SP来封装数据库操作。如果项目的SP较多，书写又没有一定的规范，将会影响以后的系统维护困难和大SP逻辑的难以理解，另外如果数据库的数据量大或者项目对SP的性能要求很，就会遇到优化的问题，否则速度有可能很慢，经过亲身经验，一个经过优化过的SP要比一个性能差的SP的效率甚至高几百倍。
　　三、内容：
　　1、开发人员如果用到其他库的Table或View，务必在当前库中建立View来实现跨库操作，最好不要直接使用“databse.dbo.table_name”，因为sp_depends不能显示出该SP所使用的跨库table或view，不方便校验。
　　2、开发人员在提交SP前，必须已经使用set showplan on分析过查询计划，做过自身的查询优化检查。
　　3、高程序运行效率，优化应用程序，在SP编写过程中应该注意以下几点：
　　a)SQL的使用规范：
　　i.　尽量避免大事务操作，慎用holdlock子句，提高系统并发能力。
　　ii.　尽量避免反复访问同一张或几张表，尤其是数据量较大的表，可以考虑先根据条件提取数据到临时表中，然后再做连接。
　　iii.　尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该改写;如果使用了游标，就要尽量避免在游标循环中再进行表连接的操作。
　　iv.　注意where字句写法，必须考虑语句顺序，应该根据索引顺序、范围大小来确定条件子句的前后顺序，尽可能的让字段顺序与索引顺序相一致，范围从大到小。
　　v.　不要在where子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
　　vi.　尽量使用exists代替select count(1)来判断是否存在记录，count函数只有在统计表中所有行数时使用，而且count(1)比count(*)更有效率。
　　vii.　尽量使用“>=”，不要使用“>”。
　　viii.　注意一些or子句和union子句之间的替换
　　ix.　注意表之间连接的数据类型，避免不同类型数据之间的连接。
　　x.　注意存储过程中参数和数据类型的关系。
　　xi.　注意insert、update操作的数据量，防止与其他应用冲突。如果数据量超过200个数据页面(400k)，那么系统将会进行锁升级，页级锁会升级成表级锁。
　　b)索引的使用规范：
　　i.　索引的创建要与应用结合考虑，建议大的OLTP表不要超过6个索引。
　　ii.　尽可能的使用索引字段作为查询条件，尤其是聚簇索引，必要时可以通过index index_name来强制指定索引
　　iii.　避免对大表查询时进行table scan，必要时考虑新建索引。
　　iv.　在使用索引字段作为条件时，如果该索引是联合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用。
　　v.　要注意索引的维护，周期性重建索引，重新编译存储过程。
　　c)tempdb的使用规范：
　　i.　尽量避免使用distinct、order by、group by、having、join、cumpute，因为这些语句会加重tempdb的负担。
　　ii.　避免频繁创建和删除临时表，减少系统表资源的消耗。
　　iii.　在新建临时表时，如果一次性插入数据量很大，那么可以使用select into代替create table，避免log，提高速度;如果数据量不大，为了缓和系统表的资源，建议先create table，然后insert。
　　iv.　如果临时表的数据量较大，需要建立索引，那么应该将创建临时表和建立索引的过程放在单独一个子存储过程中，这样才能保证系统能够很好的使用到该临时表的索引。
　　v.　如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先truncate table，然后drop table，这样可以避免系统表的较长时间锁定。
　　vi.　慎用大的临时表与其他大表的连接查询和修改，减低系统表负担，因为这种操作会在一条语句中多次使用tempdb的系统表。
　　d)合理的算法使用：
　　根据上面已提到的SQL优化技术和ASE Tuning手册中的SQL优化内容,结合实际应用,采用多种算法进行比较,以获得消耗资源最少、效率最高的方法。具体可用ASE调优命令：set statistics io on, set statistics time on , set showplan on 等。
转自: http://hi.baidu.com/onlyafar/blog/item/1bcdf219de623f73dbb4bd44.html

[转]进贤话四~六级测试

52775569@qq.com(linji) — Sun, 31 May 2009 12:53:39 GMT

进贤话四-六级测试命题人：叶鸿昌

一：选择题（每小题2分）
1 “囊捂个”是什么意思？
A 怎么办 B 怎么弄的 C 乱弄的 D 你五哥
2 “翻兜个”在进贤话中是骂人还是夸人？
A 骂人 B 夸人
3 “切嫩屋里发财”是祝福的话么？
A 是 B 不是
4 “恰个的”在进贤话中值得是哪类东西？
A 用的 B 吃的 C 听的 D 看的
5 “表的嫩哇什里”是什么意思？
A 你惊讶什么 B不知道你干什么 C不知道你说什么 D骂人
6 “倒罩个”是什么?
A 日用品 B 水果 C 一种职业 D 常用语
7 “困告”是干什么？
A 睡觉 B 说悄悄话 C 控告 D 困惑
8 “我不佞的嫩”什么意思？
A 我不在乎你 B 我不认识你 C 我不了解你 D 我跟你没关系
9 在进贤话中有个常用语“好过竟”你认为这是个什么词？
A 名词 B 动词 C 形容词 D 副词
10进贤朋友常说“嫩囊系刚个您哦！”你认为这句话应该用在什么地方？
A 朋友见面时 B 朋友相互夸奖 C 朋友理解错误 D 朋友发生误会

二:判断题（每小题3分）
1 一般进贤人见面的第一句话会说“恰里吧”对么?
2 当有某个人把你惹毛了你通常会说“表捂的我发燥”对么？
3 我对你说“嫩希一炸驹”你应该点头还是摇头？
4 我们进贤地大物勃，热情的进贤人民在热情的接待外地人时总会说“嫩希外楼来嘎！跟俄切归，表在歌里现戏！”对么？
5 忠实的进贤NBA粉丝在观看NBA现场直播是老是会发出“哦戳里，能个球都的振啊！科比还希您啊！”这句话是在夸科比吗?
6 聪明的进贤人都知道当有人劝你说“刚个事制不得勒，咧外捂的您嘎哇俄的希肥子”时你不应该理他，因为他在骂你对吗?
7 “狗都不恰个东西”在进贤话里是一种特别难吃的东西么？
8 有人打电话给你，你讲的头一句话是“嫩希海个啊？”还是“嫩捂什里啊？”
9 “咧希外嫩屋里哦”是进贤人常用的语言吗？
10 “希剁针个特，俄者嫩俄有冒有什里德的！不慎托阮！”这句话中包含了说话者的愉快情绪，对么？

三：分析题（每小题5分）
1 过马路是有个老奶奶对你说“崽里啊！扶的俄过切哈特”你的回答应该是？
2 过马路后老奶奶对你讲“嫩该个崽里很过竟!”她是在夸你，但你应该说什么？
3 当朋友们知道后他们说:“咧希囊捂个。。嫩刚个您还外制好您啊？冒看出来诶。。。！”表示对你很恶心，你应如何说些更恶心的让他们无语？
4 话说你在和你女朋友逛街时遇上了上次的老奶奶她对你女朋友说：“你的诶！该个崽里好过竟咧！表放过节咧，咧嫩外切啊利多个！”你女朋友很懵对你说：“该个老您嘎希癫子啵！哇级刚个事希？”请用一百字左右进贤话把整件事情解释清楚！
5

请用进贤话来形容下这张图片！
四：写作题(25分）
假如你叫肥子，你的好友搭头想在星期六来你家玩。可他不清楚去你家的路线，所以请你用进贤话编辑一个短信发给他，告诉他怎么样来你家！（要求：不少于150字语句通顺无明显语法错误）
提示：向左走——盲左边走
向右走——盲右边走
一直走——七将走

转载：(恰噶)牛B的进贤县

52775569@qq.com(linji) — Sun, 31 May 2009 12:52:21 GMT

------------------------------------------

SAS：报表分析工具使企业管理更上一层楼

52775569@qq.com(linji) — Sat, 04 Apr 2009 14:47:32 GMT

美国SAS软件研究所（上海）有限公司

　　企业的需求

----在中国，许多大型企业都已经成功地建立了自己的OLTP（On-Line Transaction Processing）系统，在日常业务运行中积累了纷繁复杂的数据。信息技术人员每天都需要基于这些宝贵的数据资源，制作满足管理人员和业务人员需求的报表。但是，就目前中国的许多企业来讲，制作报表还只是局限于对数据库中存储的数据进行直接的输出和展示，而实际上千篇一律的数字罗列是解决不了企业的真正需要的。企业所需要的是能够分析、并有针对性地解答企业经营中实际问题的报表。
----在一个成功的信息系统中，信息技术人员会抱怨经理和管理人员总是有制作新的报表的要求，这在目前中国的企业中是非常普遍的现象。其实这证明了你的信息系统很成功，经理和管理人员总在想利用它了解情况，为决策提供支持。正所谓"工欲善其事，必先利其器"。为了更进一步发挥你的信息系统的作用，一定要强化报表制作的能力，这将会给经理和企业管理人员以更大的支持。SAS软件将使你产生强大的企业级的报表制作能力。这里，SAS公司将展示企业制作报表的完整的流程。
----这里所说的"报表"的实质是什么？

首先就是要能抓到所需要的数据，并且能将之重组成所需要的结构形式；
报表绝不仅仅是数字的罗列，而是一定要能分析出数字中隐含的原委和规律性；
报表要有丰富的内涵，还要易于组织和制作，并形成完善的管理机制；
丰富的报表还要能在企业范围内畅通无阻地分发和使用。

　　抓到所需要的数据并将之重组成所需要的结构形式----收集和准备报表所用的数据是一件非常重要且复杂的工作。最好能营造这样一种环境：从收集数据的角度看，要能跨越整个企业的各个系统、平台和数据库取用任何数据；但从报表者制作角度看，最好是面对已经整合起来的、恰好可供制作报表之用的数据集合。这也正是SAS企业级报表制作软件SAS/ER数据收集和准备功能的基本理念。
----SAS/ER可以从几乎任何数据源取得数据，包括DB2、SQLDS、Oracle、Informix、SAP R/2＋R/3、AS/400、Sybase、Adabas、Ingres、DBF、DIF、IDMS/R、IMSDL/I、VSAM以及通过ODBC在Lotus123、MSExcel、MSAccess等处取出数据。实际上通过SAS的DATASTEP可从任何知道其数据结构的数据载体中取出数据，不论这些数据存在于本地还是通过网络存在于远程的载体上。
----在取用这些数据时，SAS/ER将这些不同类型的数据载体看成三种类型：文件服务器、ODBC服务器和远程SAS服务器。
----收集到数据后还要为制作报表组织好所用的数据。从报表设计的角度看SAS/ER给用户提供了简单、易操作的界面，大大方便了非专业用户的可使用性。报表设计者看到的他所需要的数据是已经经过SAS/ER整合的：SAS的数据表格；SAS的MDDB多维数据结构；SAS的数据视窗（View）。
----为了方便报表制作者的使用，SAS/ER为某个报表制作者或群体设置了放置报表制作所需数据的文件夹--InfoFolder，为数据的使用提供了方便和安全。SAS还为企业级报表的需要准备了数据仓库产品SAS/WA，这将为企业数据的充分利用开辟更加广阔的天地。
　　要做好报表，先要分析好数据----在对企业数据进行分析时，早期常用的是书面形式的报表。最简单的报表是所谓LIST式的报表，将所感兴趣的事情以一条条记录的形式打印出来。为了得到比这种冗长记录式报表更为概括的形式，报表又有带有汇总，有横向，有纵向，越来越复杂。
----有经验的企业数据分析人员知道，仅是罗列数据，即使是越来越复杂的数据，也还是让人看不清企业有什么问题，所以这时需要的是"数据分析"。
----在分析企业级的数据时，至少要有三个最基本的层次：

描述性分析；
推断性的进一步分析；
建立统计数学模型，进行深入分析。

----一谈到这些分析，就会使人联想到数学、复杂的公式和难以实现的解题算法。这不仅是计算机用户的难题，也是许多软件供应商望而却步的原因。以数学方法起家的美国SAS软件研究所不仅全面、完整地解决了上述问题，而且以一种非常友好的界面提供给用户。SAS提供给用户的是一个易用、高效的企业数据分析、探索的工具软件。使用者只要对它提出问题和要求，而不用管如何实现。数学问题和算法SAS都替你解决了，而且以交互式操作和图形可视化的界面来面对用户。
　　利用SAS进行描述性数据分析----当你拿到一批企业数据时，对于像产量这样的数据，也许不同层次和角度的汇总量即可说明生产量的各种情况了。这样的钻取技术是SAS提供的最基本手段。但要描述各种不同类型的工艺过程的技术参数或某种具体业务数据时，就不这么简单了。你必须说明这个参数或数据在一段时间内它的数值平均值及中位数是多少，不同数值段的数据出现的频率是多少。可能还要分析这个数据数值中的极差、半极差、方差、标准差以及变异系数等，来描述它在一个过程中变化的程度。在论及数据的频率分布时还应有分布形态的描述，即分布的偏度和峰度等。这可能就是生产中的质量变化趋势，或某种业务发展趋向的动因所在。
----除了这些数据的描述之外，还可以用图形并伴以上述参数来表现，如直方图、柱状图、拼花图等。可视化的图形大大强化了对数据的描述，使你可以对企业复杂的实际运作情况有更深入和清楚的了解。SAS还可为你构造空间图形，还可使这些三维图形进行旋转，以使你更清楚地看到数据的分布及其间的相依关系。
----当你使用SAS来处理数据时，通过交互式操作点动菜单或功能按钮，即可迅速、方便地实现多方位、多种统计形式的要求。例如企业或社会金融活动都是一个极其复杂的大系统，不使用这些建立在实际数据基础上的数据分析处理和多维可视化展现技术，你是不可能看清其中的奥秘的。
　　推断性的进一步分析----在进行企业的经营决策或是金融活动中的重大操作时，决策者往往并不是对要采取的方案一无所知，而是对实施这些方案后是否能达到预期的效果没有把握。即领导的设想要通过收集数据加以论证。SAS可利用企业经营数据，对你将要实施的方案的可行性进行检验，并给出量化的推断。
----在企业的生产实绩中，不同的生产配方或是几种不同的工艺条件的组合，会产生不同的效果。但分布在很大范围的效果数据，让你难以看清其差异。使用SAS的方差分析方法则可定量地比较它们之间的差异及其显著性，由此可以看出使用怎样的配方或工艺参数组合才能使企业得到最好的效益。
----在企业的生产过程中总是有许多干扰或随机效应存在。在进行方差分析时，可将响应效果的变差，解析为由不同配方或不同工艺条件组合所引起的变差，和由于其他随机因素所造成的变差，由此可加深决策者对工艺因素和配方条件作用的认识。
----这样一来，你不仅认识了生产数据，而且分析了生产过程，并能进一步把握对生产、经营运作效果的精准控制。
　　建立统计数学模型进行深入分析----企业中的生产、经营、金融运作等，都是在众多因素的相互影响、相互作用之中而存在的，尽管如此，我们总是想找出其中量化的规律性。各种数理统计方法，如各种相关分析和回归处理建立统计的量化数学模型等，是许多分析人员经常采用的办法。使用SAS，你只要从要处理的数据中指定一个因变量，即你要分析的目标，再指定自变量，即对你要分析目标有影响的那些因素，系统立即就可以给出它们之间的相关关系，并为你建立起一个回归模型。
----在这一操作中，SAS一直使用可视化的图形界面，甚至可将你最感兴趣的部分进行局部放大，以便仔细研究，如观察例外值、反常值；识别可能的趋势；交流数据分析的结果；探索变量之间的关系等。
----上述量化分析的结果，可以使决策者根据报表输出结果，提出可操作的优化企业运作的建议，使企业向着更加良性化的方向发展。
----利用SAS对企业的运作实绩进行描述性分析，对推断性作进一步分析，建立统计数学模型深入分析，已经可以将企业中存在或潜在的问题理出个头绪，不断完善生产和经营。若这些分析还不够，则还可以使用专门企业级的数据挖掘工具EM，以支持更复杂的操作。在世界500强中，98％的企业是利用SAS技术这样做的，它们成功的经历充分说明进行有效的数据分析是何等重要！在中国的企业中，应该积极地吸取这些企业成功的先进经验，作好数据的分析，使报表中输出的信息能够更加有效地辅助企业管理人员进行决策！

　　企业级的报表制作工具

　　SAS提供了强大的数据分析、处理软件,并提供了数据仓库、数据挖掘等一系列决策支持技术。在此基础上SAS又向用户提供了企业级的报表制作工具──SAS/ER,它与多维数据库技术SAS/MDDB和网上实现的能力SAS/IntrNet相结合,在企业管理中发挥着强有力的作用。

　丰富的报表制作能力

　　常用的报表大约有这样三类:列表式的报表;带有各种分类、汇总式的报表;带有各种图表、图形的报表。用SAS/ER可非常方便地制作传统的列表式报表。在列表式报表制作画面上,用户选择相应的数据集,再点击列表的图标,即可完成简单的列表式报表制作过程。此外,SAS/ER还提供了一系列附加功能充实列表式报表:
* 对数据进行筛选;
* 在产生了列表式报表后,要添加一些项目时,只要用鼠标进行拖拉即可,并且还可实现分类列表;
* 提供了各种客户化的处理,如表头、表尾、页码、分页等;
* 此表在屏幕上显示时,若太长、太宽,用户则可加上上下、左右滚动条;
* 在报表制作中和完成后均可进行打印结果的预览;
* 报表制作完后,可以将制作报表的结构和相关数据定义存储起来。报表亦可定义成HTML的结构,供没有安装SAS/ER软件的同事查阅。
利用SAS/ER,用户还可以制作带有各种分类、汇总的报表。在中国的企业或政府机关中,归纳性更强的报表是那种横向有大分类、中分类、小分类,纵向又有不同层次汇总、统计的报表。这样的报表用任何编程语言制作都非常复杂,但使用SAS/ER来做时只不过是按需求用鼠标点击、拖拉操作而已。
* 首先定义报表格式,点击一个多维结构的标记。在此结构中,可从所选数据集中指定用作一层层分类的变量。
* 在为制作报表选定的数据集中确定要进行汇总的变量。
有人分析过,在同样的报表面积上,以图形传达的信息量比用数字传达的信息量要高两个数量级。这很容易理解,因为这正是前面所说的数据分析处理的结果!用SAS分析技术进行过深入分析的图形结果,可以放入SAS/ER制作的报表中,强化报表的表现能力。你还可以在报表中加入需要的图画来进行点缀、装饰,以渲染效果。为了更加方便地进行报表设计,SAS/ER提供有一个报表的样式库,你可拿来套用,亦可用来启发思维。你也可以将自己设计的新报表格式添入报表的样式库,供今后利用,或让同事分享,或建立自己所在部门的标准化报表规范。

　企业级报表制作系统的管理

　　如果你营造了一个企业级规模的报表制作系统,却又疏于管理的话,很可能造成混乱。SAS/ER不仅创造了优裕的报表制作环境,而且设置了整体管理机制。首先是报表制作人的管理。SAS/ER将使用人员分成三类:
* 管理者,他可对数据收集、更新进行操作;
* 高级报表制作者,他应当是某个部门的报表制作的领导者;
* 一般报表制作者,他只能就该部门可使用的数据制作报表。
为了方便报表制作者和数据使用者的管理,SAS/ER还将报表制作者进行了分组。一般将一个部门使用同样数据的人员分在一个组中;再在组内定义上述三种不同类型的人员。在一个组中的人员可以使用一个或一组"文件夹"——InfoFolder,形成了整个企业报表数据的既方便又安全的机制。其次,制作报表所需资源的管理也是很重要的。SAS/ER的管理者要关注:
* 数据存取、交换的数量;
* 在每个数据表中,索引的合理设置,所谓合理主要看其对效率的影响;
* 在网络计算环境中,各服务器和客户机的能力和它所承担任务的平衡;
* 网络运行的速度。
为了优化系统的运作,应遵循两条基本原则:
* 对数据的整理尽可能在数据的存在地进行;
* 在数据的运作中,尽可能使在网络上的传输量最少。
对于上述问题,SAS提供了一系列的方法和对策,优化配置,使系统的效率达到最高。

　多维数据库结构使报表和决策支持系统高效运作

　　所谓多维数据库,就是对一个数据集合按其中的若干分类变量进行不同组合的统计处理,并以多维检索的方式构建其物理结构,这种一次性的、精心策划的统计分析可多次使用。这将最大限度地提高决策支持过程的效率,并节省了计算、处理资源。设想在一个有10个县的专区中,政府部门要对所有的5种民族,分男女进行分类统计,这个对基本人口的统计可能要用在专区工作的诸多方面。这个10县、5民族和分男女的不同分类组合可能有:
* 按县分有10种;
* 按民族分有5种;
* 按男女分有2种;
* 按县和民族分有50种;
* 按县分男女有20种;
* 按民族分男女有10种;
* 按县、民族再分男女则有100种。
总计共有197种分类方法。若分类之后还有几十种统计分析变量,每个变量还要做几种统计处理,可想而知重复统计所造成的重复工作量会有多大。对这样的数据环境就应当建立多维数据库。在SAS/ER的环境中,你可以方便地指定按哪几个分类变量、对哪些分析变量、以哪几种统计计算指标建立多维数据库——MDDB。一旦指定,在将数据集成到SAS/ER环境的同时,系统就建立好了多维数据库。从物理结构上看,这就是具有快速多维检索的、对不同分类方式、对所指定的统计变量、按规定的统计指标进行处理的多维统计表。SAS/MDDB还设置了这个表系统的管理机制,从而更进一步强化了查询检索。SAS/MDDB可以对统计变量进行8种基本统计,还可以有选择地再附加13种进一步的统计处理。
　　利用含有多维数据库机制的SAS/ER企业级报表制作工具,在制作有多种复杂统计、汇总项目的报表时,可能并没有在报表制作时进行统计、汇总,而只是以快速检索的方式从多维数据库中取出这些数值而已。你可以想见其效率比传统工作方式会有多大的提高。你也可以在屏幕上对多维数据库进行查询、检索,同时还可以利用其多维检索进行钻透式(Drilldown)查询,强化了对信息的利用效率。

　利用数据仓库制作报表

　　在大企业的信息系统中,有时会发生系统管理员做不出领导所需要的报表的情况。不是系统中没有数据;也不是编制不出报表制作的程序,而是OLTP性质的信息系统无法运行制作报表所要运行的程序。为了解决这一类的问题,企业建立了数据仓库。这不仅解决了报表制作对OLTP系统的干扰问题,而且大大提高了信息的查询、综合、分析效率,从而使报表制作的更符合领导的需要。SAS报表制作软件SAS/ER建立在SAS数据仓库产品SAS/WA之上。SAS/ER是SAS数据仓库解决方案家族中的有效成员,而SAS/WA又为SAS/ER方便的报表制作和结果输出提供了坚实的后盾。
在网上实现一切营造企业范围内统一、规范的报表制作环境,是为了使企业的信息在内涵和结构上,在一个更高层次上更加通达。SAS/ER已从报表的设计、制作和数据收集、准备上建立了良好的机制,并且可以通过SAS/IntrNet,更进一步地使上述运作都通过Internet和企业Intranet来实现。
SAS/IntrNet是一个功能丰富的软件包,包括了从浏览器通过Web到各个服务器站点及其间各种传输方式的运作,实现了SAS的网际运行。SAS/IntrNet支持:
* 通过Internet或Intranet的浏览器即可进入SAS企业级报表制作环境;
* 除了前述的连接方式外,还可通过JDBC将浏览器和SAS服务器连接起来,这就可以获
得所有SAS功能,包括SAS/ER的运作能力;
* 网际的连通,开拓了数据获取途径;
* 通过Internet或Intranet的浏览器去查询多维数据库——MDDB,使浏览过程更加得
心应手;
* 通过Internet或Intranet进行报表HTML格式的传输和分发,强化了报表利用的效率
、广度和方便程度;
* 无论是"胖"或"瘦"客户机,或是以Java Applet方式运作均可实现上述功能。这是
　　因为SAS也是Internet和Intranet世界的推进者。由于SAS研究所深厚的知识、技术背景,SAS的企业级报表制作工具有别于市场上那些
简易的报表制作工具。它不仅操作方便,可用性强,而且使报表内容的编制能适应企业的需要;在Web上实现的能力,又将企业报表的制作和展现拓展到了最广泛的程度。SAS以高知识含量的信息技术支持企业早日获得更大的成功。

转自：http://www.ithome-cn.net/technology/mis/mis82.htm

《清明》

52775569@qq.com(linji) — Sat, 04 Apr 2009 14:21:54 GMT

（唐）杜牧

清明时节雨纷纷，路上行人欲断魂。
借问酒家何处有？牧童遥指杏花村。

祭奠祖先、缅怀先人！

无法启动OracleXETNSListener服务的解决方法

52775569@qq.com(linji) — Sun, 07 Dec 2008 02:39:58 GMT

版本：Oracle Database 10g Express Edition
修改计算机名称会导致OracleXETNSListener无法启动。
解决方法：
修改：

%Oracle_Home%\app\oracle\product\10.2.0\server\NETWORK\ADMIN 下
listener.ora
tnsnames.ora

修改这两个文件里指定计算机名称部分。

修改后，restart 服务。

PLSQL

52775569@qq.com(linji) — Sat, 29 Nov 2008 07:27:32 GMT

1--plsql 基本结构
declare
x varchar2(10):='ABCDE';
y STRING(10):='123';
begin
--x:='This is..';
DBMS_OUTPUT.PUT_LINE('x 的值为:'||x||' y的值为:'||y);
/*
DBMS_OUTPUT.PUT('X 的值为:'||x);
DBMS_OUTPUT.NEW_LINE;
*/
END;
/
2--if 语句
DECLARE
A NUMBER;
B VARCHAR2(10);
BEGIN
A:=2;
IF A=1 THEN
B:='A';
ELSIF A=2 THEN
B:='B';
ELSE
B:='C';
END IF;
DBMS_OUTPUT.PUT_LINE('B的值是:'||B);
END;
/
3--case 语句
DECLARE
A NUMBER;
B VARCHAR2(10);
BEGIN
A:=32;
CASE
WHEN A=1 THEN B:='A';
WHEN A=2 THEN B:='B';
WHEN A=3 THEN B:='C';
ELSE B:='OTHERS';
END CASE;
DBMS_OUTPUT.PUT_LINE('B的值是:'||B);
END;
/
4--while 循环
DECLARE
X NUMBER;
BEGIN
X:=0;
WHILE X<=3
LOOP
X:=X+1;
DBMS_OUTPUT.PUT_LINE('内：X='||X);
END LOOP;
DBMS_OUTPUT.PUT_LINE('外：X='||X);
END;
/
5--loop 循环
BEGIN
FOR I IN REVERSE 1..5
LOOP
DBMS_OUTPUT.PUT_LINE('I = '||I);
END LOOP;
DBMS_OUTPUT.PUT_LINE(' END OF FOR LOOP');
END;
/
6--goto 标记
DECLARE
X NUMBER;
BEGIN
X:=0;
<>
X:=X+1;
DBMS_OUTPUT.PUT_LINE(X);
IF X<3 THEN
GOTO REPEAT_LOOP;
END IF;
END;
/
7--意外情况处理
DECLARE
TEST VARCHAR2(10);
BEGIN
SELECT SEQ INTO TEST FROM HELP WHERE ROWNUM=1;
DBMS_OUTPUT.PUT_LINE(TEST);
EXCEPTION
WHEN NO_DATA_FOUND THEN
DBMS_OUTPUT.PUT_LINE('没有找到数据!');
END;
/
8--自定义意外情况处理
DECLARE
TNAME VARCHAR2(10);
E EXCEPTION;
BEGIN
SELECT SEQ INTO TNAME FROM HELP WHERE ROWNUM=1;
IF TNAME<>2 THEN
RAISE E;
END IF;
DBMS_OUTPUT.PUT_LINE(TNAME);
EXCEPTION
WHEN E THEN
DBMS_OUTPUT.PUT_LINE('ERROR NUMBER!');
END;
/
9--记录
DECLARE
TYPE MYRECORD IS RECORD(
ID HELP.SEQ%TYPE,
NAME HELP.INFO%TYPE);
REAL_RECORD MYRECORD;
BEGIN
SELECT SEQ,INFO INTO REAL_RECORD FROM HELP WHERE SEQ=10 AND ROWNUM=1;
DBMS_OUTPUT.PUT_LINE(REAL_RECORD.ID||','||REAL_RECORD.NAME);
END;
/

R 文档

52775569@qq.com(linji) — Sun, 23 Nov 2008 01:35:53 GMT

2005年6月《R导论》HTML 版本：简体中文；繁体中文；（附带的PowerPoint) (版本：0.01β）
2005年11月《R导论》CHM 版本：下载（chm，zip）（K Tu制作）(版本：0.01β）
2006年7月《R导论》PDF 版本：下载（pdf, zip)（版本：0.1）（官方下载）
2006年《R for beginners》中文版：下载（pdf，zip）（版本：2.0）
2006年10月《R 语言定义》HTML 版本（草稿）：简体中文；英文版；(版本：0.01β）
2007年12月《R 内核》HTML 版本（草稿）：简体中文；英文版；(版本：0.01α）
2008年1月《R 数据的导入和导出》HTML 版本：简体中文(分页); 简体中文(单页); (版本：0.01β）
2008年1月R 语言中国论坛（版本：1.0 β）

转自：http://www.biosino.org/R/R-doc/