博客园_每天写一个demo

【转】JQUERY刷新页面

2011-11-11T09:35:00Z

jquery刷新页面

局部刷新：

这个方法就多了去了，常见的有以下几种；

$.get方法，$.post方法，$.getJson方法,$.ajax方法如下

前两种使用方法基本上一样

$.get(”Default.php”, {id:”1″, page: “2″ },

function(data){

//这里是回调方法。返回data数据。这里想怎么处理就怎么处理了。

});

$.getScript方法：

$.getScript(”http://jqueryajax.com/jquery.js”,

function(){

$(”#go”).click(function(){//回调方法

$(”.block”).animate( { backgroundColor: ‘pink’ }, 1000)

.animate( { backgroundColor: ‘blue’ }, 1000);

});

$.getJson只是返回的数据类型不一样

$.getJson(”Default.php”, {id:”1″, page: “2″ },

function(data){

//注意，这里返回的JSON数据引用方法为”data.info”,不明白的可以查一下json方面的教程。这里就不解释太多了

});

$.ajax 这个方法估计用的人很多吧。不过我不太喜欢用这个。个人觉得前面两个更方便

$.ajax({

type: “POST”, //提交的类型

url: “some.php”,//提交地址

data: “name=John&location=Boston”,//参数

success: function(msg){ //回调方法

alert( “Data Saved: ” + msg );//这里是方法内容，和上面的get方法一样

}

});

下面介绍全页面刷新方法：有时候可能会用到

window.location.reload()刷新当前页面.

parent.location.reload()刷新父亲对象（用于框架）

opener.location.reload()刷新父窗口对象（用于单开窗口）

top.location.reload()刷新最顶端对象（用于多开窗口）

下面再介绍一些javascript基本函数

1.document.write(”");为输出语句
2.JS中的注释为//
3.传统的HTML文档顺序是:document->html->(head,body)
4.一个浏览器窗口中的DOM顺序是:window->(navigator,screen,history,location,document)
5.得到表单中元素的名称和值:document.getElementByIdx(”表单中元素的ID号”).name(或value)
6.一个小写转大写的JS:document.getElementByIdx(”output”).value=document.getElementByIdx(”input”).value.toUpperCase();
7.JS中的值类型:String,Number,Boolean,Null,Object,Function
8.JS中的字符型转换成数值型:parseInt(),parseFloat()
9.JS中的数字转换成字符型:(”"+变量)
10.JS中的取字符串长度是:(length)
11.JS中的字符与字符相连接使用+号.
12.JS中的比较操作符有:==等于,!=不等于,>,>=,<.<=
13.JS中声明变量使用:var来进行声明
14.JS中的判断语句结构:if(condition){}else{}
15.JS中的循环结构:for([initialexpression];[condition];[upadteexpression]){insideloop}
16.循环中止的命令是:break
17.JS中的函数定义:functionfunctionName([parameter],…){statement[s]}
18.当文件中出现多个form表单时.可以用document.forms[0],document.forms[1]来代替.
19.窗口:打开窗口window.open(),关闭一个窗口:window.close(),窗口本身:self
20.状态栏的设置:window.status=”字符”;
21.弹出提示信息:window.alert(”字符”);
22.弹出确认框:window.confirm();
23.弹出输入提示框:window.prompt();
24.指定当前显示链接的位置:window.location.href=”URL”
25.取出窗体中的所有表单的数量:document.forms.length
26.关闭文档的输出流:document.close();
27.字符串追加连接符:+=
28.创建一个文档元素:document.createElement_x(),document.createTextNode()
29.得到元素的方法:document.getElementByIdx()
49.引用一个文件式的JS:<scripttype=”text/javascript”src=”aaa.js”></script>
50.指定在不支持脚本的浏览器显示的HTML:<noscript></noscript>
51.当超链和ONCLICK事件都有时,则老版本的浏览器转向a.html,否则转向b.html.例:<ahref=”a.html”onclick=”location.href=’b.html’;returnfalse”>dfsadf</a>
52.JS 的内建对象有:Array,Boolean,Date,Error,EvalError,Function,Math,Number,Object,RangeError,ReferenceError,RegExp,String,SyntaxError,TypeError,URIError
53.JS中的换行:\n
54.窗口全屏大小:<script>functionfullScreen(){this.moveTo(0,0);this.outerWidth=screen.availWidth;this.outerHeight=screen.availHeight;}window.maximize=fullScreen;</script>
55.JS中的all代表其下层的全部元素
56.JS中的焦点顺序:document.getElementByIdx(”表单元素”).tabIndex=1
57.innerHTML的值是表单元素的值:如<pid=”para”>”howare<em>you</em>”<p></p>,则innerHTML的值就是:howare<em>you</em>
58.innerTEXT的值和上面的一样,只不过不会把<em>这种标记显示出来.
59.contentEditable可设置元素是否可被修改,isContentEditable返回是否可修改的状态.
60.isDisabled判断是否为禁止状态.disabled设置禁止状态
61.length取得长度,返回整型数值
62.addBehavior()是一种JS调用的外部函数文件其扩展名为.htc
63.window.focus()使当前的窗口在所有窗口之前.
64.blur()指失去焦点.与FOCUS()相反.
65.select()指元素为选中状态.
66.防止用户对文本框中输入文本:onfocus=”this.blur()”
67.取出该元素在页面中出现的数量:document.all.tags(”div(或其它HTML标记符)”).length
68.JS中分为两种窗体输出:模态和非模态.window.showModaldialog(),window.showModeless()
69.状态栏文字的设置:window.status=’文字’,默认的状态栏文字设置:window.defaultStatus=’文字.’;
70.添加到收藏夹:external.AddFavorite(”http://www.google.com”,”Google”);
71.JS中遇到脚本错误时不做任何操作:window.onerror=doNothing;指定错误句柄的语法为:window.onerror=handleError;
72.JS中指定当前打开窗口的父窗口:window.opener,支持opener.opener…的多重继续.
73.JS中的self指的是当前的窗口
74.JS中状态栏显示内容:window.status=”内容”
75.JS中的top指的是框架集中最顶层的框架
76.JS中关闭当前的窗口:window.close();
77.JS中提出是否确认的框:if(confirm(”Areyousure?”)){alert(”ok”);}else{alert(”NotOk”);}
78.JS中的窗口重定向:window.navigate(”http://www.google.com”);
79.JS中的打印:window.print()
80.JS中的提示输入框:window.prompt(”message”,”defaultReply”);
81.JS中的窗口滚动条:window.scroll(x,y)
82.JS中的窗口滚动到位置:window.scrollby
83.JS中设置时间间隔:setInterval(”expr”,msecDelay)或setInterval(funcRef,msecDelay)或setTimeout
84.JS中的模态显示在IE4+行,在NN中不行:showModalDialog(”URL”[,arguments][,features]);
85.JS中的退出之前使用的句柄:functionverifyClose(){event.returnValue=”wereallylikeyouandhopeyouwillstaylonger.”;}}window.onbeforeunload=verifyClose;
86.当窗体第一次调用时使用的文件句柄:onload()
87.当窗体关闭时调用的文件句柄:onunload()
88.window.location的属性:protocol(http:),hostname(www.example.com),port(80),host(www.example.com:80),pathname(”/a/a.html”),hash(”#giantGizmo”,指跳转到相应的锚记),href(全部的信息)
89.window.location.reload()刷新当前页面.
89-1.parent.location.reload()刷新父亲对象（用于框架）
89-2.opener.location.reload()刷新父窗口对象（用于单开窗口）
89-3.top.location.reload()刷新最顶端对象（用于多开窗口）
90.window.history.back()返回上一页,window.history.forward()返回下一页,window.history.go(返回第几页,也可以使用访问过的URL)
91.document.write()不换行的输出,document.writeln()换行输出
92.document.body.noWrap=true;防止链接文字折行.
93.变量名.charAt(第几位),取该变量的第几位的字符.
94.”abc”.charCodeAt(第几个),返回第几个字符的ASCii码值.
95.字符串连接:string.concat(string2),或用+=进行连接
96.变量.indexOf(”字符”,起始位置),返回第一个出现的位置(从0开始计算)
97.string.lastIndexOf(searchString[,startIndex])最后一次出现的位置.
98.string.match(regExpression),判断字符是否匹配.
99.string.replace(regExpression,replaceString)替换现有字符串.
100.string.split(分隔符)返回一个数组存储值.
101.string.substr(start[,length])取从第几位到指定长度的字符串.
102.string.toLowerCase()使字符串全部变为小写.
103.string.toUpperCase()使全部字符变为大写.
104.parseInt(string[,radix(代表进制)])强制转换成整型.
105.parseFloat(string[,radix])强制转换成浮点型.
106.isNaN(变量):测试是否为数值型.
107.定义常量的关键字:const,定义变量的关键字:var

本文链接

借船过河：一个据说能看穿你的人性和欲望的心理测试

2011-11-10T14:27:00Z

我10多年前认识个朋友，从国外读书回来，给我说了个心理测验《借船过河》，她说是读心理学时老师教的。然后我拿这个测验测过无数人，都很准。这个也不是算命，但可以让你了解自己的需要，有的人死不承认自己是这样的啊，可实际上就是这样子的。我把这个图画下来了，大家可以对照看，不过要听我先讲故事，然后再开始。

一男人M要与未婚妻F相会结婚，但两人一河相隔，M必须要借船过河才能见到F，于是他开始四处找船。

这时见一个女子L刚好有船，M跟L借，L遇到M后爱上了他，就问：我爱上你了，你爱我吗？M比较诚实，说：对不起，我有未婚妻，我不能爱你。这么一来，L死活是不把船借给M，她的理由是：我爱你，你不爱我，这不公平，我不会借你的！

M很沮丧，继续找船，刚好见一位叫S的女子，就向她借船，S说：我借给你没问题，但有个条件，我很喜欢你，你是不是喜欢我无所谓，但你必须留下陪我一晚，不然我不借你。M很为难，L不借他船，S如果再不借他的话就过不去河与F相见了，据说这个地方只有这两条船。为了彼岸的未婚妻，他不得不同意了S的要求，与S有了NB。次日，S遵守承诺把船借给了M。

见到未婚妻F后，M一直心里有事，考虑了很久，终于决定把向L和S借船的故事跟F说了。可惜，F听了非常伤心，一气之下与M分了手，她觉得M不忠，不能原谅。F失恋了，很受打击。

这时他的生活里出现了位女子E，两人也开始恋爱了，但之前的故事一直让他耿耿于坏，E问M是不是有什么话要跟她说，于是，M一五一十地把他和L、S、F之间的故事讲了一遍。E听了后，说，我不会介意的，这些跟我没关系。

故事讲完了，问题来了，请你把这几个人排列个次序，标准是你认为谁最好，谁第二，谁第三，第四，第五？这个M男也算在内的。建议不要想太复杂，也不需要考虑大众看法，你认为谁做得好就是好。

看到这里请先选择好你的答案，完了往下拉看看答案。

↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓

答案其实很简单，就是用你的潜意识告诉你最想要的是什么。不知道自己要什么，这是很普遍的问题，因为什么都挺重要的，舍弃什么都不成体统，只是每个人的人生追求确实差异很大，看别人追求事业，你也羡慕也很想这样，但不知道为什么总做不到；看别人婚姻幸福，你也很想，可实现起来确实不容易，这和运气也不是太有关系，而是你需要的决定了很多。

我知道，一定有人看了这个答案觉得很失望，就这个呀，这能说明什么呀？别看答案简单，其实这里面既包含这你的价值观，也是对你人生有预示的。

我说两个故事吧。这故事中的两个人是很典型的，都是测过这个游戏的。

一个是我以前乐队成员，贝斯手，当时他写下的是：M、F、S、E、L，这个排列他死不承认，因为当时他还在为音乐梦死磕着，让他承认爱钱这太羞辱了，而且还是结婚狂？但我发现他确实是这样的人，演出有点演出费就赶紧寄家去，还闹过这样的笑话，赚了400块，他好意思地跟别人借一百，说凑个整。爱钱不是坏事，就怕不承认。很多年后，乐队其他人都各奔东西，他留在了那行里，不过做了歌舞厅的伴奏，每天跑场很能赚钱，据说也很快结婚，有了小孩，是个很负责的丈夫，音乐就是他赚钱的工具，生活得也不错。后来我遇到过次他，一肚子不满，虽然开上了车，但理想早破灭了，没事业没爱情，就是富裕的日子。我觉得这就是他的人生轨迹，想追求的还是自己想要的东西。

另一个是天津的一位女主持人，我当时跟她没什么话聊的，就玩了下这个。她的选择是S、M、L、F、E，我告诉她这几个符号代表什么的时候，她有点不高兴，说不准，她怎么把S放第一呢？是因为她觉得S比较公平，要比L简单，F事儿太多，E太冷漠，M不错但就是太墨迹了。每个人理解问题的方式都不同，刚好这个透露了你的潜意识。很多年后，我在北京遇到了位认识她的人，说起这个女主持来，他说，那谁可惜了，早不干主持了，跟他们单位好多男的乱七八遭，后来被单位开了，嫁了个有钱人。

我看问我的朋友，其中选择E为首的占大多数，说明事业对不少来说人还是很重要的，还有距离问题，比如你选择了事业和金钱互相挨着，这很正常，这两项都是有关联的，可如果你把爱情排第一，却又把家庭排最后，那就说明，你未必会依赖婚姻这个形式，这排列组合是可以推理的.我想这个东西确实预示性很强，你要什么肯定会下意识地追求了什么，这点和你的名字命盘也是有据可查的。

M——金钱（Money）

L——爱情（Love）

S——性（Sex）

F——家庭（Family）

E——事业（Enterprise）

本文链接

【转】一起谈.NET技术，关于c#静态方法和实例方法的辨析和应用

2011-11-07T01:06:00Z

本文将围绕c#静态方法和实例方法讨论一下。针对一些观点，如："静态方法是常驻内存", 还有"静态方法比实例方法先装载"，做一个辨析。同时讨论下何时用静态方法，何时用实例方法。

前几日，在微软的好友发给我一个链接：《静态方法和实例化方法之间的区别你知道了嘛？欢迎讨论！！ - 问题最终 ...》，然后说这里某些观点需要澄清一下，希望我写一篇blog。我当时读了这篇blog. 文比较短，列举了静态方法和实例方法的几种案例，也没有论点，然后就请大家讨论。后面评论就比blog热闹多了。言辞也激烈，后来该blog作者干脆把这篇blog删了。现在已经看不到这篇blog了。现在我写这篇blog，一是针对一些观点做个辨析，二是完成好友的所托。

c#静态方法和实例方法的几种用法，见如下代码：这三种形式我们应该都用过。

publicclass SomeClass
{
privatestring myfield =null;
publicstatic instance =new SomeClass();
public instranceMethod() {};
publicstatic staticMethod() {};
}

publicclass AnotherClass
{
publicstatic Main()
{
//第一种方式, 声明实例，调用实例方法
SomeClass someClass =new SomeClass();
someClass.instanceMethod();

//第二种方式，通过一个静态的实例，去调用实例方法
SomeClass.instance.instanceMethod();

//第三种方式，直接调用静态方法
SomeClass.staticMethod();
}
}

这几种方式在调用时间，还有线程安全，面向对象的编程方面都有差别。后文会谈到。

"静态方法是常驻内存"

这是那位blog作者在评论中给出的观点。我觉得"静态方法是常驻内存"的说法是不对的。要知道一个.net类型的静态方法是属于这个.net类型的。而这个.net类型是一个.net 程序集的一部分。这个.net程序集是被一个AppDomain装入到内存里面来的。这个AppDomain是可以从内存卸载的。一个有.net CLR的进程里面可以有多于一个的AppDomain，第一个AppDomain之后的AppDomain都可以动态创建和卸载。这些AppDomain中的.net程序集，既可以有静态方法，也可以有实例方法。不管是静态方法还是实例方法，都是随其程序集所在的AppDomain一起创建和卸载。第一个AppDomain在整个程序运行结束时也会最后被卸载。其中所含的.net程序集自然也卸载。看图1会更明白点。所以静态方法不存在常驻内存一说。

"静态方法比实例方法先装载"

这也是那篇blog的评论中某些人提出的观点。我不知道他们的论据是什么，但是我已经做过实验，而且也写过这两篇blog关于.net反射和metadata加载--致Jeffray Zhao等几位和firelong和[继续讨论]关于Windows PE和.net assembly的加载来证明.net程序集的加载方式是整个地加载，而不是用到某个metadata才加载该metadata, 用到某个方法才加载该方法。因为静态方法和实例方法同属于一个.net类型，而一个.net类型属于一个.net程序集。在整个地加载一个.net程序集的时候，不管是静态方法还是实例方法，都随该程序集全部加载进内存。所以"静态方法比实例方法先装载"也是不成立的。

何时用静态方法，何时用实例方法。

先说实例方法，当你给一个类写一个方法，如果该方法需要访问某个实例的成员变量时，那么就将该方法定义成实例方法。一类的实例通常有一些成员变量，其中含有该实例的状态信息。而该方法需要改变这些状态。那么该方法需要声明成实例方法。

静态方法正好相反，它不需要访问某个实例的成员变量，它不需要去改变某个实例的状态。我们把该方法定义成静态方法。

第一种方式，声明实例，调用实例方法。

当一个类有多个实例，例如学生这个类，实例可以有学生甲，学生乙，学生丙，等等，我们就用第一种方式。在多线程的情况下，只要每个线程都创建自己的实例，那么第一种方法通常是线程安全的。

第二种方式，通过一个静态的实例，去调用实例方法。

这种情况比较特殊，通常是整个程序里该类唯一的一个实例，我们通过调用该实例的实例方法来改变该实例的某些状态。这一个实例在多线程的情况下，通常是线程不安全的。除非我们给这个实例加锁。防止其他线程访问该实例。

第三种方式，直接调用静态方法。

这种情况下静态方法不需要去改变某个实例的状态。只要得到少量的参数就可完成既定事情。比如判断一个文件是否存在，只要给个文件路径和文件名，就能知道该文件是否存在。

学识有限，敬请您指教。

转自：http://www.cnblogs.com/waw/archive/2011/08/29/2158617.html

本文链接

SQL Server的复合索引学习【转载】

2010-05-28T08:50:00Z

概要
什么是单一索引,什么又是复合索引呢? 何时新建复合索引，复合索引又需要注意些什么呢？本篇文章主要是对网上一些讨论的总结。

一.概念

单一索引是指索引列为一列的情况,即新建索引的语句只实施在一列上。

用户可以在多个列上建立索引，这种索引叫做复合索引(组合索引)。复合索引的创建方法与创建单一索引的方法完全一样。但复合索引在数据库操作期间所需的开销更小，可以代替多个单一索引。当表的行数远远大于索引键的数目时，使用这种方式可以明显加快表的查询速度。

同时有两个概念叫做窄索引和宽索引，窄索引是指索引列为1-2列的索引,如果不特殊说明的话一般是指单一索引。宽索引也就是索引列超过2列的索引。

设计索引的一个重要原则就是能用窄索引不用宽索引，因为窄索引往往比组合索引更有效。拥有更多的窄索引，将给优化程序提供更多的选择余地，这通常有助于提高性能。

二.使用

创建索引
create index idx1 on table1(col1,col2,col3)
查询
select * from table1 where col1= A and col2= B and col3 = C

这时候查询优化器，不在扫描表了，而是直接的从索引中拿数据，因为索引中有这些数据，这叫覆盖式查询，这样的查询速度非常快。

三.注意事项

1.何时是用复合索引
在where条件中字段用索引，如果用多字段就用复合索引。一般在select的字段不要建什么索引(如果是要查询select col1 ,col2, col3 from mytable,就不需要上面的索引了)。根据where条件建索引是极其重要的一个原则。注意不要过多用索引，否则对表更新的效率有很大的影响，因为在操作表的时候要化大量时间花在创建索引中.

2.对于复合索引，在查询使用时，最好将条件顺序按找索引的顺序，这样效率最高。如：
IDX1:create   index   idx1   on   table1(col2,col3,col5)
select   *   from   table1   where   col2=A   and   col3=B   and   col5=D

如果是"select   *   from   table1   where   col3=B   and   col2=A   and   col5=D"
或者是"select   *   from   table1   where   col3=B"将不会使用索引，或者效果不明显

3.复合索引会替代单一索引么?
很多人认为只要把任何字段加进聚集索引，就能提高查询速度，也有人感到迷惑：如果把复合的聚集索引字段分开查询，那么查询速度会减慢吗？带着这个问题，我们来看一下以下的查询速度（结果集都是25万条数据）：（日期列fariqi首先排在复合聚集索引的起始列，用户名neibuyonghu排在后列）

IDX1:create   index   idx1   on   Tgongwen(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的查询速度一样是因为查询的条目数一样，如果复合索引的所有列都用上，而且查询结果少的话，这样就会形成“索引覆盖”，因而性能可以达到最优。同时，请记住：无论您是否经常使用聚合索引的其他列，但其前导列一定要是使用最频繁的列。

[参考: 查询优化及分页算法方案 http://blog.csdn.net/chiefsailor/archive/2007/05/28/1628339.aspx]

4.需要在同一列上同时建单一索引和复合索引么?
试验: sysbase   5.0   表table1   字段：col1,col2,col3

试验步骤：
（1）建立索引idx1   on   col1
执行select   *   from   table1   where   col1=A     使用idx1
执行select   *   from   table1   where   col1=A   and   col2=B   也使用idx1

（2）删除索引idx1,然后建立idx2   on   (col1,col2)复合索引
执行以上两个查询，也都使用idx2

（3）如果两个索引idx1,idx2都存在
并不是   where   col1='A'用idx1；where   col1=A   and   col2=B 用idx2。
其查询优化器使用其中一个以前常用索引。要么都用idx1,要么都用idx2.

由此可见，
（1）对一张表来说，如果有一个复合索引 on   (col1,col2)，就没有必要同时建立一个单索引 on col1。
（2）如果查询条件需要，可以在已有单索引 on col1的情况下，添加复合索引on   (col1,col2)，对于效率有一定的提高。
（3）同时建立多字段(包含5、6个字段)的复合索引没有特别多的好处，相对而言，建立多个窄字段(仅包含一个，或顶多2个字段)的索引可以达到更好的效率和灵活性。

5. 一定需要覆盖性查询么？
通常最好不要采用一个强调完全覆盖查询的策略。如果Select子句中的所有列都被一个非群集索引覆盖，优化程序会识别出这一点，并提供很好的性能。不过，这通常会导致索引过宽，并会过度依赖于优化程序使用该策略的可能性。通常，是用数量更多的窄索引，这对于大量查询来说可以提供更好的性能。

本文链接

SQL Server 索引结构及其使用（四

2010-05-28T01:13:00Z

SQL Server 索引结构及其使用（四）

作者：freedk

一、深入浅出理解索引结构
 二、改善SQL语句
 三、实现小数据量和海量数据的通用分页显示存储过程

聚集索引的重要性和如何选择聚集索引

　　在上一节的标题中，笔者写的是：实现小数据量和海量数据的通用分页显示存储过程。这是因为在将本存储过程应用于“办公自动化”系统的实践中时，笔者发现这第三种存储过程在小数据量的情况下，有如下现象：

1、分页速度一般维持在1秒和3秒之间。

2、在查询最后一页时，速度一般为5秒至8秒，哪怕分页总数只有3页或30万页。

　　虽然在超大容量情况下，这个分页的实现过程是很快的，但在分前几页时，这个1－3秒的速度比起第一种甚至没有经过优化的分页方法速度还要慢，借用户的话说就是“还没有ACCESS数据库速度快”，这个认识足以导致用户放弃使用您开发的系统。
　　笔者就此分析了一下，原来产生这种现象的症结是如此的简单，但又如此的重要：排序的字段不是聚集索引！
　　本篇文章的题目是：“查询优化及分页算法方案”。笔者只所以把“查询优化”和“分页算法”这两个联系不是很大的论题放在一起，就是因为二者都需要一个非常重要的东西――聚集索引。
在前面的讨论中我们已经提到了，聚集索引有两个最大的优势：

1、以最快的速度缩小查询范围。

2、以最快的速度进行字段排序。

　　第1条多用在查询优化时，而第2条多用在进行分页时的数据排序。

　　而聚集索引在每个表内又只能建立一个，这使得聚集索引显得更加的重要。聚集索引的挑选可以说是实现“查询优化”和“高效分页”的最关键因素。
　　但要既使聚集索引列既符合查询列的需要，又符合排序列的需要，这通常是一个矛盾。笔者前面“索引”的讨论中，将fariqi，即用户发文日期作为了聚集索引的起始列，日期的精确度为“日”。这种作法的优点，前面已经提到了，在进行划时间段的快速查询中，比用ID主键列有很大的优势。
　　但在分页时，由于这个聚集索引列存在着重复记录，所以无法使用max或min来最为分页的参照物，进而无法实现更为高效的排序。而如果将ID主键列作为聚集索引，那么聚集索引除了用以排序之外，没有任何用处，实际上是浪费了聚集索引这个宝贵的资源。
　　为解决这个矛盾，笔者后来又添加了一个日期列，其默认值为getdate()。用户在写入记录时，这个列自动写入当时的时间，时间精确到毫秒。即使这样，为了避免可能性很小的重合，还要在此列上创建UNIQUE约束。将此日期列作为聚集索引列。
　　有了这个时间型聚集索引列之后，用户就既可以用这个列查找用户在插入数据时的某个时间段的查询，又可以作为唯一列来实现max或min，成为分页算法的参照物。
　　经过这样的优化，笔者发现，无论是大数据量的情况下还是小数据量的情况下，分页速度一般都是几十毫秒，甚至0毫秒。而用日期段缩小范围的查询速度比原来也没有任何迟钝。聚集索引是如此的重要和珍贵，所以笔者总结了一下，一定要将聚集索引建立在：

1、您最频繁使用的、用以缩小查询范围的字段上；

2、您最频繁使用的、需要排序的字段上。

结束语

　　本篇文章汇集了笔者近段在使用数据库方面的心得，是在做“办公自动化”系统时实践经验的积累。希望这篇文章不仅能够给大家的工作带来一定的帮助，也希望能让大家能够体会到分析问题的方法；最重要的是，希望这篇文章能够抛砖引玉，掀起大家的学习和讨论的兴趣，以共同促进，共同为公安科技强警事业和金盾工程做出自己最大的努力。
　　最后需要说明的是，在试验中，我发现用户在进行大数据量查询的时候，对数据库速度影响最大的不是内存大小，而是CPU。在我的P4 2.4机器上试验的时候，查看“资源管理器”，CPU经常出现持续到100%的现象，而内存用量却并没有改变或者说没有大的改变。即使在我们的HP ML 350 G3服务器上试验时，CPU峰值也能达到90%，一般持续在70%左右。
　　本文的试验数据都是来自我们的HP ML 350服务器。服务器配置：双Inter Xeon 超线程 CPU 2.4G，内存1G，操作系统Windows Server 2003 Enterprise Edition，数据库SQL Server 2000 SP3

本文链接

SQL Server 索引结构及其使用（三）

2010-05-28T01:12:00Z

SQL Server 索引结构及其使用（三）

作者：freedk

一、深入浅出理解索引结构
 二、改善SQL语句

实现小数据量和海量数据的通用分页显示存储过程

　　建立一个 Web 应用，分页浏览功能必不可少。这个问题是数据库处理中十分常见的问题。经典的数据分页方法是:ADO 纪录集分页法，也就是利用ADO自带的分页功能（利用游标）来实现分页。但这种分页方法仅适用于较小数据量的情形，因为游标本身有缺点：游标是存放在内存中，很费内存。游标一建立，就将相关的记录锁住，直到取消游标。游标提供了对特定集合中逐行扫描的手段，一般使用游标来逐行遍历数据，根据取出数据条件的不同进行不同的操作。而对于多表和大表中定义的游标（大的数据集合）循环很容易使程序进入一个漫长的等待甚至死机。
　　更重要的是，对于非常大的数据模型而言，分页检索时，如果按照传统的每次都加载整个数据源的方法是非常浪费资源的。现在流行的分页方法一般是检索页面大小的块区的数据，而非检索所有的数据，然后单步执行当前行。
　　最早较好地实现这种根据页面大小和页码来提取数据的方法大概就是“俄罗斯存储过程”。这个存储过程用了游标，由于游标的局限性，所以这个方法并没有得到大家的普遍认可。
　　后来，网上有人改造了此存储过程，下面的存储过程就是结合我们的办公自动化实例写的分页存储过程：

CREATE procedure pagination1
(@pagesize int, --页面大小，如每页存储20条记录
@pageindex int --当前页码
)
as

set nocount on

begin
declare @indextable table(id int identity(1,1),nid int) --定义表变量
declare @PageLowerBound int --定义此页的底码
declare @PageUpperBound int --定义此页的顶码
set @PageLowerBound=(@pageindex-1)*@pagesize
set @PageUpperBound=@PageLowerBound+@pagesize
set rowcount @PageUpperBound
insert into @indextable(nid) select gid from TGongwen 
　　　　　　where fariqi >dateadd(day,-365,getdate()) order by fariqi desc
select O.gid,O.mid,O.title,O.fadanwei,O.fariqi from TGongwen O,@indextable t 
           where O.gid=t.nid and t.id>@PageLowerBound 
                        and t.id<=@PageUpperBound order by t.id
end

set nocount off

以上存储过程运用了SQL SERVER的最新技术――表变量。应该说这个存储过程也是一个非常优秀的分页存储过程。当然，在这个过程中，您也可以把其中的表变量写成临时表：CREATE TABLE #Temp。但很明显，在SQL SERVER中，用临时表是没有用表变量快的。所以笔者刚开始使用这个存储过程时，感觉非常的不错，速度也比原来的ADO的好。但后来，我又发现了比此方法更好的方法。
　　笔者曾在网上看到了一篇小短文《从数据表中取出第n条到第m条的记录的方法》，全文如下：

从publish 表中取出第 n 条到第 m 条的记录： 
SELECT TOP m-n+1 * 
FROM publish 
WHERE (id NOT IN 
　　　　(SELECT TOP n-1 id 
　　　　 FROM publish)) 

id 为publish 表的关键字

我当时看到这篇文章的时候，真的是精神为之一振，觉得思路非常得好。等到后来，我在作办公自动化系统（ASP.NET+ C#＋SQL SERVER）的时候，忽然想起了这篇文章，我想如果把这个语句改造一下，这就可能是一个非常好的分页存储过程。于是我就满网上找这篇文章，没想到，文章还没找到，却找到了一篇根据此语句写的一个分页存储过程，这个存储过程也是目前较为流行的一种分页存储过程，我很后悔没有争先把这段文字改造成存储过程：

CREATE PROCEDURE pagination2
(
@SQL nVARCHAR(4000), --不带排序语句的SQL语句
@Page int, --页码
@RecsPerPage int, --每页容纳的记录数
@ID VARCHAR(255), --需要排序的不重复的ID号
@Sort VARCHAR(255) --排序字段及规则
)
AS

DECLARE @Str nVARCHAR(4000)

SET @Str=''SELECT TOP ''+CAST(@RecsPerPage AS VARCHAR(20))+'' * FROM 
(''+@SQL+'') T WHERE T.''+@ID+''NOT IN (SELECT TOP ''+CAST((@RecsPerPage*(@Page-1)) 
AS VARCHAR(20))+'' ''+@ID+'' FROM (''+@SQL+'') T9 ORDER BY ''+@Sort+'') ORDER BY ''+@Sort

PRINT @Str

EXEC sp_ExecuteSql @Str
GO

其实，以上语句可以简化为：

SELECT TOP 页大小 *
FROM Table1 WHERE (ID NOT IN (SELECT TOP 页大小*页数 id FROM 表 ORDER BY id))
ORDER BY ID

但这个存储过程有一个致命的缺点，就是它含有NOT IN字样。虽然我可以把它改造为：

SELECT TOP 页大小 *
FROM Table1 WHERE not exists
(select * from (select top (页大小*页数) * from table1 order by id) b where b.id=a.id )
order by id

即，用not exists来代替not in，但我们前面已经谈过了，二者的执行效率实际上是没有区别的。既便如此，用TOP 结合NOT IN的这个方法还是比用游标要来得快一些。
　　虽然用not exists并不能挽救上个存储过程的效率，但使用SQL SERVER中的TOP关键字却是一个非常明智的选择。因为分页优化的最终目的就是避免产生过大的记录集，而我们在前面也已经提到了TOP的优势，通过TOP 即可实现对数据量的控制。
　　在分页算法中，影响我们查询速度的关键因素有两点：TOP和NOT IN。TOP可以提高我们的查询速度，而NOT IN会减慢我们的查询速度，所以要提高我们整个分页算法的速度，就要彻底改造NOT IN，同其他方法来替代它。
　　我们知道，几乎任何字段，我们都可以通过max(字段)或min(字段)来提取某个字段中的最大或最小值，所以如果这个字段不重复，那么就可以利用这些不重复的字段的max或min作为分水岭，使其成为分页算法中分开每页的参照物。在这里，我们可以用操作符“>”或“<”号来完成这个使命，使查询语句符合SARG形式。如：

Select top 10 * from table1 where id>200

于是就有了如下分页方案：

select top 页大小 *
from table1 
where id>
(select max (id) from 
(select top ((页码-1)*页大小) id from table1 order by id) as T
) 
order by id

在选择即不重复值，又容易分辨大小的列时，我们通常会选择主键。下表列出了笔者用有着1000万数据的办公自动化系统中的表，在以GID（GID是主键，但并不是聚集索引。）为排序列、提取gid,fariqi,title字段，分别以第1、10、100、500、1000、1万、10万、25万、50万页为例，测试以上三种分页方案的执行速度：（单位：毫秒）

页码	方案1	方案2	方案3
1	60	30	76
10	46	16	63
100	1076	720	130
500	540	12943	83
1000	17110	470	250
10000	24796	4500	140
100000	38326	42283	1553
250000	28140	128720	2330
500000	121686	127846	7168

从上表中，我们可以看出，三种存储过程在执行100页以下的分页命令时，都是可以信任的，速度都很好。但第一种方案在执行分页1000页以上后，速度就降了下来。第二种方案大约是在执行分页1万页以上后速度开始降了下来。而第三种方案却始终没有大的降势，后劲仍然很足。
　　在确定了第三种分页方案后，我们可以据此写一个存储过程。大家知道SQL SERVER的存储过程是事先编译好的SQL语句，它的执行效率要比通过WEB页面传来的SQL语句的执行效率要高。下面的存储过程不仅含有分页方案，还会根据页面传来的参数来确定是否进行数据总数统计。

--获取指定页的数据：

CREATE PROCEDURE pagination3
@tblName varchar(255), -- 表名
@strGetFields varchar(1000) = ''*'', -- 需要返回的列 
@fldName varchar(255)='''', -- 排序的字段名
@PageSize int = 10, -- 页尺寸
@PageIndex int = 1, -- 页码
@doCount bit = 0, -- 返回记录总数, 非 0 值则返回
@OrderType bit = 0, -- 设置排序类型, 非 0 值则降序
@strWhere varchar(1500) = '''' -- 查询条件 (注意: 不要加 where)
AS

declare @strSQL varchar(5000) -- 主语句
declare @strTmp varchar(110) -- 临时变量
declare @strOrder varchar(400) -- 排序类型

if @doCount != 0
begin
if @strWhere !=''''
set @strSQL = "select count(*) as Total from [" + @tblName + "] where "+@strWhere
else
set @strSQL = "select count(*) as Total from [" + @tblName + "]"
end

--以上代码的意思是如果@doCount传递过来的不是0，就执行总数统计。以下的所有代码都是@doCount为0的情况：

else
begin
if @OrderType != 0
begin
set @strTmp = "<(select min"
set @strOrder = " order by [" + @fldName +"] desc"

--如果@OrderType不是0，就执行降序，这句很重要！

end
else
begin
set @strTmp = ">(select max"
set @strOrder = " order by [" + @fldName +"] asc"
end

if @PageIndex = 1
begin
if @strWhere != '''' 

set @strSQL = "select top " + str(@PageSize) +" "+@strGetFields+ "
　　　　　　　　from [" + @tblName + "] where " + @strWhere + " " + @strOrder
else

set @strSQL = "select top " + str(@PageSize) +" "+@strGetFields+ " 
　　　　　　　　from ["+ @tblName + "] "+ @strOrder

--如果是第一页就执行以上代码，这样会加快执行速度

end
else
begin

--以下代码赋予了@strSQL以真正执行的SQL代码
　

set @strSQL = "select top " + str(@PageSize) +" "+@strGetFields+ " from ["
+ @tblName + "] where [" + @fldName + "]" + @strTmp + "(["+ @fldName + "]) 
　　　　　　from (select top " + str((@PageIndex-1)*@PageSize) + " ["+ @fldName + "] 
　　　　　　from [" + @tblName + "]" + @strOrder + ") as tblTmp)"+ @strOrder

if @strWhere != ''''
set @strSQL = "select top " + str(@PageSize) +" "+@strGetFields+ " from ["
+ @tblName + "] where [" + @fldName + "]" + @strTmp + "(["
+ @fldName + "]) from (select top " + str((@PageIndex-1)*@PageSize) + " ["
+ @fldName + "] from [" + @tblName + "] where " + @strWhere + " "
+ @strOrder + ") as tblTmp) and " + @strWhere + " " + @strOrder
end 

end 

exec (@strSQL)

GO

　　上面的这个存储过程是一个通用的存储过程，其注释已写在其中了。在大数据量的情况下，特别是在查询最后几页的时候，查询时间一般不会超过9秒；而用其他存储过程，在实践中就会导致超时，所以这个存储过程非常适用于大容量数据库的查询。笔者希望能够通过对以上存储过程的解析，能给大家带来一定的启示，并给工作带来一定的效率提升，同时希望同行提出更优秀的实时数据分页算法。

本文链接

SQL Server 索引结构及其使用（一）[转]

2010-05-28T01:11:00Z

SQL Server 索引结构及其使用（一）

作者：freedk

一、深入浅出理解索引结构

　　实际上，您可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引：聚集索引（clustered index，也称聚类索引、簇集索引）和非聚集索引（nonclustered index，也称非聚类索引、非簇集索引）。下面，我们举例来说明一下聚集索引和非聚集索引的区别：
　　其实，我们的汉语字典的正文本身就是一个聚集索引。比如，我们要查“安”字，就会很自然地翻开字典的前几页，因为“安”的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个字；同样的，如果查“张”字，那您也会将您的字典翻到最后部分，因为“张”的拼音是“zhang”。也就是说，字典的正文部分本身就是一个目录，您不需要再去查其他目录来找到您需要找的内容。我们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。
　　如果您认识某个字，您可以快速地从自动中查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而需要去根据“偏旁部首”查到您要找的字，然后根据这个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“张”字，我们可以看到在查部首之后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码却是63页，“张”的下面是“弩”字，页面是390页。很显然，这些字并不是真正的分别位于“张”字的上下方，现在您看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。我们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。
　　通过以上例子，我们可以理解到什么是“聚集索引”和“非聚集索引”。进一步引申一下，我们可以很容易的理解：每个表只能有一个聚集索引，因为目录只能按照一种方法进行排序。

二、何时使用聚集索引或非聚集索引

下面的表总结了何时使用聚集索引或非聚集索引（很重要）：

动作描述	使用聚集索引	使用非聚集索引
列经常被分组排序	应	应
返回某范围内的数据	应	不应
一个或极少不同值	不应	不应
小数目的不同值	应	不应
大数目的不同值	不应	应
频繁更新的列	不应	应
外键列	应	应
主键列	应	应
频繁修改索引列	不应	应

事实上，我们可以通过前面聚集索引和非聚集索引的定义的例子来理解上表。如：返回某范围内的数据一项。比如您的某个表有一个时间列，恰好您把聚合索引建立在了该列，这时您查询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毫秒

五、其他注意事项

　　“水可载舟，亦可覆舟”，索引也一样。索引有助于提高检索性能，但过多或不当的索引也会导致系统低效。因为用户在表中每加进一个索引，数据库就要做更多的工作。过多的索引甚至会导致索引碎片。
　　所以说，我们要建立一个“适当”的索引体系，特别是对聚合索引的创建，更应精益求精，以使您的数据库能得到高性能的发挥。
　　当然，在实践中，作为一个尽职的数据库管理员，您还要多测试一些方案，找出哪种方案效率最高、最为有效。

本文链接

SQL Server 索引结构及其使用（二）

2010-05-28T01:11:00Z

SQL Server 索引结构及其使用（二）

作者：freedk

一、深入浅出理解索引结构

改善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 asc

用时：4720毫秒。扫描计数 1，逻辑读 41956 次，物理读 0 次，预读 1287 次。

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 asc

用时：173毫秒。扫描计数 1，逻辑读 290 次，物理读 0 次，预读 0 次。

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这个关键词。
　　到此为止，我们上面讨论了如何实现从大容量的数据库中快速地查询出您所需要的数据方法。当然，我们介绍的这些方法都是“软”方法，在实践中，我们还要考虑各种“硬”因素，如：网络性能、服务器的性能、操作系统的性能，甚至网卡、交换机等。

本文链接

【转】谈谈网页设计中的字体应用 (4) 实战应用篇·下

2009-07-12T08:13:00Z

Yoho, 大家好，又是我哟~ 首先抱歉让大家等了这么多时间。最近实在比较繁忙啦。不过我还是会尽量抽空出来给大家讲点有的没的，欢迎大家继续关注哦。上次我讲了在实际应用font-family时会遇到的浏览器兼容性问题。这次我要从操作系统方面来讲如何安排字体族。另外，由于中文字体的选择范围实在太小，所以本章中设计的内容主要以西文字体为主，比较适合上一章中的“方案二”。 - 不...

【转】谈谈网页设计中的字体应用 (3) 实战应用篇·上

2009-07-12T08:02:00Z

Hello, 大家好，又是我~ 大家有看过font set和一些要注意的基本问题以及通用字体族两篇文章后，应该对字体的基本有了一些了解。现在我们开始把这些知识都应用到实战中吧！ - 规范中 font-family 的解释方式我们定义下面这个字体表：font-family: "Comic Sans MS", "幼圆", "黑体", sans-serif;按照W3C的规范，浏览器在使用这个 font...

博客园_每天写一个demo

【转】JQUERY刷新页面

借船过河：一个据说能看穿你的人性和欲望的心理测试

【转】一起谈.NET技术，关于c#静态方法和实例方法的辨析和应用

SQL Server的复合索引学习【转载】

SQL Server 索引结构及其使用（四

SQL Server 索引结构及其使用（三）

SQL Server 索引结构及其使用（一）[转]

SQL Server 索引结构及其使用（二）

【转】 谈谈网页设计中的字体应用 (4) 实战应用篇·下

【转】 谈谈网页设计中的字体应用 (3) 实战应用篇·上

【转】谈谈网页设计中的字体应用 (4) 实战应用篇·下

【转】谈谈网页设计中的字体应用 (3) 实战应用篇·上