博客园_左手心

【整理收藏】合并、压缩JS、CSS文件减少页面HTTP请求数的方法

2011-02-24T08:05:00Z

Web性能优化最佳实践中最重要的一条是减少HTTP请求，它也是YSlow中比重最大的一条规则。减少HTTP请求的方案主要有合并JavaScript和CSS文件、CSS Sprites、图像映射（Image Map）和使用Data URI来编码图片。CSS Sprites和图像映射现在已经随处可见了，但由于IE6和IE7不支持Data URI以及性能问题，这项技术尚未大量使用。目前大部分网页中的JavaScript和CSS文件数量和开发时一致，少量的网页会根据实际情况采取本地合并，这些合并中相当多的是有选择地手动完成，每次新的合并都需要重新在本地完成并上传到服务器，比较的随意和繁琐，同样文件的压缩也有类似的情况。而利用服务端的合并和压缩，我们就可以按照开发的逻辑尽可能让文件的颗粒度变小，利用网页中URL的规则来自动实现文件的合并和压缩，这会相当的灵活和高效。

bo Handler

一，Combo Handler

2008年7月YUI Team宣布在YAHOO! CDN上对YUI JavaScript组件提供Combo Handler服务。Combo Handler是Yahoo!开发的一个Apache模块，它实现了开发人员简单方便地通过URL来合并JavaScript和CSS文件，从而大大减少文件请求数。比如在页面上使用YUI2的Rich Text Editor组件需要引入多个JavaScript文件，常用方式如下：

<script src="http://yui.yahooapis.com/2.8.0r4/build/yahoo-dom-event/
yahoo-dom-event.js"></script>
<script src="http://yui.yahooapis.com/2.8.0r4/build/container/
container_core-min.js"></script>
<script src="http://yui.yahooapis.com/2.8.0r4/build/menu/menu-min.js"></script>
<script src="http://yui.yahooapis.com/2.8.0r4/build/element/element-min.js"></script>
<script src="http://yui.yahooapis.com/2.8.0r4/build/button/button-min.js"></script>
<script src="http://yui.yahooapis.com/2.8.0r4/build/editor/editor-min.js"></script>

而使用Combo Handler服务之后，则上述的代码可以写为：

<script src="http://yui.yahooapis.com/combo?
2.8.0r4/build/yahoo-dom-event/yahoo-dom-event.js&
2.8.0r4/build/container/container_core-min.js&
2.8.0r4/build/menu/menu-min.js&
2.8.0r4/build/element/element-min.js&
2.8.0r4/build/button/button-min.js&
2.8.0r4/build/editor/editor-min.js"></script>

二，nginx_concat_module

nginx_concat_module 是淘宝研发的针对 nginx 的文件合并模块，主要用于合并前端代码减少 http 请求数。如果你的应用环境中部署了 nginx，那么可以考虑尝试此模块减少请求数。

三，Combres

是一个 ASP.NET 网站的客户端资源js,css的压缩，合成和缓存库，基于Apache 2.0协议开源，最新版本是2.0。这个库同时支持WebForm和MVC，主要的特性如下：

资源文件的组织,包括javascript和css文件的组织，每个都可以使用相同的配置或者使用不同的配置。
可以在资源里完成精简，压缩，然后发送给浏览器，所有的这些资源只使用一个Http请求
有一个可扩展的minification架构，开发人员可以选择关闭资源压缩的设置或选择其中一个内置的适配器，类库里带了3个适配器.NET YUI Compressor library, Microsoft Ajax Minifier library和Google Closure compiler service，配置都是通过XML文件进行，非常方便。
对每个请求生成适当的ETag和Expires/Cache-Control 头，支持服务器端的缓存。
和ASP.NET 路由引擎集成，所以对ASP.NET MVC 和ASP.NET WebForm的支持非常好。
支持调试模式，调试的时候不缓存也不压缩，方便调试。

关于Combres库的详细介绍可以看codeproject上的文章： Combres 2.0 - A Library for ASP.NET Website Optimization

四，借助HttpCombiner让你的网站加速

原文地址：http://www.codeproject.com/KB/aspnet/HttpCombine.aspx

中文翻译：http://www.cnblogs.com/aNd1coder/archive/2011/01/12/Speed-up-your-website-by-using-httpCombiner.html

通过搜索还发现几个的处理方法，国外的，先记录下，有空了研究测试下

参考文章：Combine, minify and compress JavaScript files to load ASP.NET pages faster

项目地址：http://www.codeproject.com/KB/aspnet/combineMinify.aspx

Combining, Compressing, Minifying ASP.NET ScriptResource and HTML Markups

项目地址：http://www.codeproject.com/KB/aspnet/AspNetOptimizer.aspx

CssJscriptOptimizer

项目地址：http://www.codeproject.com/KB/aspnet/CssAndJavaScriptOptimizer.aspx

CombineAndMinify (刚才又发现了这个，看评价很不错，做个标记)

http://www.codeproject.com/KB/aspnet/CombineAndMinify.aspx

还有个 MbCompression

http://mbcompression.codeplex.com/

本文链接

前端要给力之：URL应该有多长？

2011-02-24T07:38:00Z

URL到底应该有多长？我为什么要提这个问题呢？有许多优化指南里都写着：要尽量减小COOKIE、缩短URL，以及尽可能地使用GET请求等等，以便优化WEB页面的请求和装载。但是，这种所谓“尽可能”、“尽量”只是定性的描述，定量的来看，要缩短到多少个字节才算少呢？

注意最后一条。嗯，不要惊讶，的确是这样长的URL，确切的长度是443bytes。但这是长了呢？还是不算长呢？

要知道以IE为例，可以处理的URL长度为2048 bytes，也就是说，反正~~无论如何，IE是能处理的。其实，一般浏览器也没问题，所以，“正确性”是没问题。所以，接下来我们要说的是效率。

　
一、TCP/IP协议中的包头问题

在TCP/IP网络中，底层协议是一回事，应用层协议又是一回事。所以作为应用层协议的HTTP，自身可以传输多大的内容，以及如何传输(例如HTTP包一般以48K为界限，超过48K时会出现应用层的分包，即所谓的multipart)这些都是由应用层来约定的。而在底层协议中，链路层与传输层对“传多大的包”有各自的约定。简单的说，传输层约定了IP数据包的MSS(最大分段尺寸)，链路层约定了MTU(最大传输单元)。如果一个IP数据包的大小超过MTU(即MSS+TCP报头+IP报头>MTU)，则在链路层会将IP数据包拆成多个信息包传输。

MSS与不同的传输环境相关，有两个推荐值。一般来说，
- 目标地址非本地地址(与源地址在不同一个网段)时，MSS默认值通常是536；否则，
- MSS默认值通常为1460。
MTU与网络环境相关，也有两个推荐值。一般来说，
- 串口为576字节；
- 以太网为1500字节。

MTU/MSS的两种推荐值中都有40个字节的差异，即是(TCP报头+IP报头)的一般值，该值以120 bytes为上限(20+20字节的IP/TCP头部；40+40字节IP/TCP可选头部)。所以在复杂的网络环境中，应用层的网络协议可用的单个数据包的大小,最佳值应小于536-80=456字节，尽量限制在1460-80 = 1380字节以内。这样的限制，是综合考虑传输层与链路层协议的结果。不过一些常见的建议中，也会用536/1460这两个值，与这里的讨论没有太本质的差异。我只是强调，如果我们要一个“足够优化的请求”，那么极限值应该是多少？

　
二、HTTP协议中的包头问题

那么，现在来到HTTP这个应用层协议。一个HTTP请求由头部与数据区构成，对于HTTP GET请求来说，可以只有头部而没有数据区，原因是HTTP头部的内容如下(头部需要以2个连续回车换行结束)：
---------
GET (...) HTTP/1.1
Accept:*/*
Referer:http://www.alipay.net/
Accept-Language:zh-cn
User-Agent: (...)
Accept-Encoding:gzip, deflate
Host:static.alipay.net
Connection:Keep-Alive
Cookie: (...)
---------
---------
GET (...) HTTP/1.1
Accept:*/*
Referer:http://www.alipay.net/
Accept-Language:zh-cn
User-Agent: (...)
Accept-Encoding:gzip, deflate
Host:static.alipay.net
Connection:Keep-Alive
Cookie: (...)
---------

这里的GET (...)可以跟着一个完整的GET请求的URL，而GET请求的参数也都放在这个URL上，因此可以不需要有单独的数据区。在上述的这个HTTP请求中，某些特定的客户端可能会多几个或少几个http head field，但通常字段都会比较短。我们仅以这个例子来说明，那么这个“缺省的(不完整的)HTTP头”用掉了多少字节呢？

答案是184字节。不过还需要强调，Referer与当前正在浏览的网址直接相关，例如当前正在浏览的页面是500字节长的URL，那么当前网页上的超链接点击时Referer字段都会填上这个500字节的URL，网页中过长的URL会使得点击超链接时消耗更多的传输，这里也是一例了。

那么不讨论Referer字段的影响，仅以上述为例，我们能用的最佳值，就只剩下了456-184=272字节了。这272字节会有三个地方使用，就是上面标为(...)的三个地方：GET、User-Agent和Cookie。User-Agent这个字段与浏览器相关，不同的浏览器以及该浏览器处理不同的操作系统环境时，都会出现不同。在JS以及服务器上的统计软件中，也常常使用这个字段来判断浏览器环境，例如OS、版本等。这个字段的值有时候会比较长，以我当前的机器为例，该值为：
---------
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; QQWubi 108; EmbeddedWB 14.52 from: http://www.bsalsa.com/ EmbeddedWB 14.52; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 1.1.4322; .NET CLR 3.5.21022; .NET4.0C; .NET4.0E)
---------
占用了274字节。也就是说，事实上理想环境下的使用456字节就已经不够用了。按此前讨论的，我们可以退而求其次：
- 使用536字节的边界值，即不考虑80字节的tcp/ip可选头部。

此外，需要强调的是User-Agent长度的可变性，例如上面的“EmbeddedWB……”等64字节在一般的电脑中可能就没有，这是一个第三方组件。同样的，也可能因为其它的浏览器环境(例如傲游)导致这个字段更长。基于这个事实，我仍以本例中的这一特殊情况来做分析。

以536字节为例，我们事实上还有78字节可用，因此在这里我们将优化的第一等级设为：70字节。建议公司可以根据服务器端收集的数据取一个平衡值。

三、COOKIE耗用可以降到0

现在，Cookie是消耗最大的地方，以我当前的机器为例，该值有几种情况(对于不同的协议与域，是不一样的)：

(1) 对于首页http://www.alipay.net/，值有49字节：
ali_apache_id=12.1.11.70.1275978936200.5; lastpg=

(2) 对于http://*.alipay.net/，值有171字节：
ali_apache_id=12.1.11.70.1275978936200.5; ali_apache_sid=12.1.46.46.128998714836.4|1289988948; ALIPAYJSESSIONID=bYWcn4Wq0Z5FBCoHzfpn2f1XxDAmBepay; ali_apache_tracktmp=uid=

(3) 对于https://static.alipay.net/，值有307字节：
cna=AKaaAhYBhU0BAeMdAHlnHNcd; ali_apache_id=169.17.198.19.1272623861747.7; payMethod=directPay; _tb_order=38016166656317; defaultBank=ICBC; __utma=22931947.260433774.1277279158.1277279158.1282287558.2; __utmz=22931947.1282287558.2.2.utmcsr=life.alipay.net|utmccn=(referral)|utmcmd=referral|utmcct=/index.php

(4) 对于http(s)://img.alipay.net/，值有379字节：
apay_id=159588238.127262386236866.128979461890689.1289969142342368.137; cna=AKaaAhYBhU0BAeMdAHlnHNcd; ali_apache_id=169.17.198.19.1272623861747.7; payMethod=directPay; _tb_order=38016166656317; defaultBank=ICBC; __utma=22931947.260433774.1277279158.1277279158.1282287558.2; __utmz=22931947.1282287558.2.2.utmcsr=life.alipay.net|utmccn=(referral)|utmcmd=referral|utmcct=/index.php

(5) 其它情况。

为什么在2、3、4情况下出现了cookie使用的暴增呢？事实上，3、4两种情况虽然略有差异，但产生问题的根源与情况2是完全一致的。所以后文仅以情况2为例。跟踪其http request过程可知：
- 请求首页时，服务器端返回了四个set-cookie应答。

这四个应答(http response head)如下：
--------

Set-Cookie:ali_apache_sid=10.2.46.46.128998714836.4|1289988948; path=/; domain=.alipay.net
Set-Cookie:JSESSIONID=A8CE523AEA03E2C990D6796D6BAEC81E; Path=/
Set-Cookie:ALIPAYJSESSIONID=bYWcn4Wq0Z5FBCoHzfpn2f1XxDAmBepay; Domain=.alipay.net; Path=/
Set-Cookie:ali_apache_tracktmp=uid=; Domain=.alipay.net; Path=/

--------

所以在此后的所有http请求中，都将使用如前例(3)中的171字节的cookie。但是，显然的，至少有以下几种情况这些cookie是无意义的：
- 如果访问的是重定向页面，包括返回Status Code：302的重定向，以及html页面中使用http-meta的重定向；
- 如果访问的页面是被缓存的，例如返回Status Code：304的“Not Modified”；
- 如果访问的页面是静态的、无需识别cookie的，例如static.alipay.net中的.img、.js和.css文件等。

显然，我们在img、static中的图片或其它静态资源是可以被缓存的，而且无论是缓存还是第一次存取，cookie值都完全没有意义。对于静态页面(.html)来说，如果我们不是要通过http server来统计分析静态页面的访问情况，那么这些cookie也是不需要的。所以，对于这些资源、内容，我们应该强调的使这些cookie不被发送，或尽量少的使用(对于部分的.html静态页，我们可能仅仅需要用于分析用户访问链的session id)。

优化cookie的方式很简单：将这些静态资源部署在不以.alipay.net为domain的服务器/组里，或使用其它的独立域名。这种情况下，对于特定的——当然也是最大量的一部分——资源，COOKIE耗用可以降到0。

　
四、缩短url

总算来到我们的正题：URL可以有多长？通过前面的分析，我们仍然还有70字书可以用，即使在特定条件下，我们需要给一些页面访问留下track数据(例如session)，那么我们仍然有40~50个字节可以用。不过，仅此而已，我们离本文最开始提到的443 bytes仍然有相当相当长的距离。

但我们真的需要这么长的URL吗？

答案是不需要，我们完全可以缩短URL。例如前面的例子，我们原始的URL的get部分是：
---------
/min?b=javascript&f=arale/lang/aspect.js,arale/lang/md5.js,arale/lang/uri.js,arale/lang/tmpl.js,arale/lang/date.js,arale/lang/number.js,arale/http/jsonp.js,arale/http/ajax.js,arale/http/core.js,arale/event/event-chain.js,arale/class/declare.js,arale/fx/animator.js,aralex/widget.js,aralex/tplwidget.js,aralex/view.js,aralex/tab/tab.js,aralex/dropdown/dropdown.js,aralex/slider/slider.js,aralex/slider/switchslider.js
---------
---------
/min?b=javascript&f=arale/lang/aspect.js,arale/lang/md5.js,arale/lang/uri.js,arale/lang/tmpl.js,arale/lang/date.js,arale/lang/number.js,arale/http/jsonp.js,arale/http/ajax.js,arale/http/core.js,arale/event/event-chain.js,arale/class/declare.js,arale/fx/animator.js,aralex/widget.js,aralex/tplwidget.js,aralex/view.js,aralex/tab/tab.js,aralex/dropdown/dropdown.js,aralex/slider/slider.js,aralex/slider/switchslider.js
---------

仔细观察，它的意思其实是
---------
/min?b=javascript&f=...
---------

字段f后面的，其实是arale这个脚本项目中的一些静态资源的拼接。在服务器端，min这个程序根据参数"b=javascript&f=..."将一些脚本碎片拼接成一个单独.js文件并返回到浏览器，如果没有变化，则直接返回Status Code：304。

那么，事实上我们每次请求的“f=...”字段后面的参数块将会是完全一样的。或者，即使在不同的情况下要求拼接的文件列表不一样，也仅有相当有限的组合。这使我们自然的想到一个东西：求和。用这种方式对上述的字符串求一个key(例如hash、md5、crc)，然后我们就可以用这个唯一key来查找拼接后的.js内容——这也意味着min程序不需要每次都拼接文本。这样一来，上面的URL可以变成(以对f字段后的396字节求crc32为例)：
---------
/min?b=javascript&f=313466DB
---------
考虑到不同的版本管理：
---------
/min?b=javascript&v=0.9b&f=313466DB
---------

现在，我们将URL控制在了一个相当小的规模，而且加上了版本管理和内容的有效性验证，需要的情况下，服务器端的min程序也可以做动态生成以及缓存。这些改造与我们原始的需求并没有任何的冲突。重要的是，我们成功地将get请求控制在了35字节，余留的空间完全满足我们

整体优化的需要：第一等级的优化，70字节！

　
五、技术成熟性与价值

1、twritter中早就使用这样的技术了。

2、与arale项目类似的，YQL(Yahoo! Query Language)项目也有类似的需求，因此他们将“在URL上传入一个sql”通过上述技术变成了一个短名，例如：
http://y.ahoo.it/iHQ8c0sv
相当于
http://developer.yahoo.com/yql/console/?q=select%20woeid%20from%20geo.places%20where%20text%3D%22san%20francisco%2C%20ca%22

3、微软还“傻傻说不清楚”，所以你看他们的官网很慢。^^.

4、当我们有条件将http头部减小到456字节以下时，应尽力为之。例如旺旺因为有独立客户端，所以可以定制http request head，以缩减User-Agent等字段。

5、当我们总是从浏览器端发出最小化的HTTP请求时，网络总是可以最快速的将请求提交到服务器，无需等待多个包并组合。这在慢速网络，以及存在大量丢包的网络中效果将为极为明显。简单地说，如果有人在局域网中用迅雷或BT，那么最小化HTTP请求将会使网页的浏览体验提升得相当相当明显。

6、我们应该做脚本等静态资源的版本管理了。

本文链接

CSS Border使用小分享(转)

2010-09-19T03:13:00Z

CSS Border使用小分享
原理
css盒模型
一个盒子包括: margin+border+padding+content
– 上下左右边框交界处出呈现平滑的斜线. 利用这个特点, 通过设置不同的上下左右边框宽度或者颜色可以得到小三角, 小梯形等.
– 调整宽度大小可以调节三角形形状.

示例1
一般情况下, 我们设置盒子的宽高度, 及上下左右边框, 会呈现如下图
#test1 {
height:20px;
width:20px;
border-color:#FF9600 #3366ff #12ad2a #f0eb7a;
border-style:solid;
border-width:20px;
}

示例2
在上面基础上, 我们把宽高度都设为0时, 会呈现上述的边界斜线.
#test2 {
height:0;
width:0;
overflow: hidden; /* 这里设置overflow, font-size, line-height /
font-size: 0; /是因为, 虽然宽高度为0, 但在IE6下会具有默认的 /
line-height: 0; / 字体大小和行高, 导致盒子呈现被撑开的长矩形 /
border-color:#FF9600 #3366ff #12ad2a #f0eb7a;
border-style:solid;
border-width:20px;
}
这时, 其实我们已经看到有上下左右四个三角形了..如果, 我们把4种颜色, 只保留一种颜色, 余下3种颜色设置为透明(或者设置为和背景色相同的颜色), 那不就出现一个小三角了么

示例3
只保留上面的橙色, 看看
#test3 {
height:0;
width:0;
overflow: hidden;
font-size: 0;
line-height: 0;
border-color:#FF9600 transparent transparent transparent;
border-style:solid;
border-width:20px;
}
可是, IE6下不支持透明啊~~~, 会出现下图的样子
找到一个在IE6下边框透明的文章中找到解决办法, 如下例

示例4
IE6下, 设置余下三条边的border-style为dashed,,,即可达到透明的效果~ 具体原因可以见参考资料3
#test4 {
height:0;
width:0;
overflow: hidden;
font-size: 0;
line-height: 0;
border-color:#FF9600 transparent transparent transparent;
border-style:solid dashed dashed dashed;
border-width:20px;
}
当然, 在IE6下, 不设置透明, 将其颜色设置为背景色, 使其看不出来也是可以的.

示例5
上面我们画的小三角的斜边都是依靠原来盒子的边, 还有另外一种形式的小三角, 就是斜边在盒子的对角线上
#test5 {
height:0;
width:0;
overflow: hidden;
font-size: 0;
line-height: 0;
border-color:#FF9600 #3366ff transparent transparent;
border-style:solid solid dashed dashed;
border-width:40px 40px 0 0 ;
}
保留其中一种颜色, 就可以得到斜边在对角线上的三角形了…多个这样的三角形, 通过设置边框大小, 颜色, 拼凑起来可以形成任意形状的三角形.
像这种不规则的三角形, 延伸一下, 放在气泡框上, 就可以省去拼背景图片的麻烦了.
另外, 关于气泡框, 可以使用棱形字符(◆)来实现, 设置其font-size, 颜色和背景色一致, 定位可以使用margin负值和absolute绝对定位来实现, 见示例.

应用之圆角生成
应该说是近似圆角,,其实由一个高度非常小的梯形展示出来
- 上梯形(无上边框,下左右3px宽度, 左右颜色去掉)+矩形+下梯形
自适应圆角1:
- 整个rc设置为float: left 或 display: inline-block 分为top,bd,bottom, top中又有两个层rc1和rc2, rc1只设置border-top, 高度为0, 并设置左右margin呈短小的一横线, rc2只设置左右border并且左右margin小于rc1, height为1px, 中间bd设置左右border,不设置左右margin;
- 不过 IE 6&7 出现 bug：rc在IE6中依然显示为dispaly:block,而IE7中top 和 bottom缩成一坨,不肯扩展开来,而在rc1/rc2/rc3 中插入文字xxx后只能扩展到文字宽度,不能与bd对齐.
- 见自适应圆角1
自适应圆角2
- 自 Google 系产品的 1px 圆角按钮,,,三层div, 最外层div1正常设置边框宽度1px, 呈现出上下边框线, 中间div2只设置左右边框, 且把左右margin设置成负值, 呈现出圆角处的4个圆点内层div3同样只设置左右边框, 同时margin上下空出div2的高度, margin左右也设置与div2相同的负值.
- 见自适应圆角2
其他小问题
- 透明:
IE6浏览器不支持transparent透明属性,就border生成三角技术而言,直接设置对应的透明边框的border-style属性为dotted或是dashed即可解决这一问题,原因是在IE6下, 点线与虚线均以边框宽度为基准,点线长度必须是其宽度的3倍以上（height>=border-width3）,虚线宽长度必须是其宽度的5倍以上（height>=border-width*5）,否则点线和虚线都不会出现.
- IE6的奇偶bug:
如果定位外框高度或是宽度为奇数,则IE6下,绝对定位元素的低定位和右定位会有1像素的误差.所以,尽量保证外框的高度或宽度为偶数值.
- IE6的空div高度bug:
IE6下,空div会有莫名的高度,也就是说height:0;不顶用,此时形成的尖角的实际占高于其他浏览器是有差异的.可使用font-size:0; + overflow:hidden;修复此问题.
- filter: chroma滤镜
该属性属性可以设置一个对象中指定的颜色为透明色, 如:
border-color: pink;
filter: chroma(color=pink);

参考资料
CSS小三角原理
CSS气泡效果
IE6下边框透明原理解析
CSS3实现的机器猫图形
本文链接

发个编程笑话，娱乐一下

2010-09-14T01:24:00Z

一个女程序员twitter上发了一条tweet:

昨晚梦见男朋友和别的女人在逛街，梦里我的第一反应是查源代码…结果调试半天查不出来为什么显示的是那个女人不是我，最后含泪把那个女人给注释掉了，再一运行就是我男朋友自己逛街了…醒来囧字脸呆了很久…囧rz

评论：
把那个女人的指针指向你即可
谁让你把男朋友设成public的
加个断点看看那女人是谁
心真软，就该把他的接口屏蔽掉。//是我想多了么
protected 逛街(youOnly)
设计问题，应该采用单例模式
没做回归测试
标准做法是做个断言
注释掉了逛街的参数不用改么
不要忘记GC谢谢
查一下Log，只逛街了吗？

本文链接

sqlserver 生成100万个不重复的10位随机数存入数据库

2010-08-26T06:41:00Z

USE tempdb

CREATE   TABLE   RandomNumber(Id   char(10),IsUsed bit not null)
CREATE   UNIQUE   INDEX   IX_RandomNumber   ON   RandomNumber(Id)
WITH   IGNORE_DUP_KEY
GO

DECLARE   @dt   datetime
SET   @dt   =   GETDATE()
SET   NOCOUNT   ON
DECLARE   @row   int
SET   @row   =   1000000
WHILE   @row   > 0
BEGIN
RAISERROR( 'need   %d   rows ',   10,   1,   @row)   WITH   NOWAIT
SET   ROWCOUNT   @row
INSERT   RandomNumber   SELECT
Id   =   RIGHT(10000000000   +   CONVERT(bigint,   ABS(CHECKSUM(NEWID()))),   10)
,IsUsed=0
FROM   syscolumns   c1,   sysobjects   o--,   syscolumns   c2
SET   @row   =   @row   -   @@ROWCOUNT
END
SELECT   BeginDate   =   @dt,   EndDate   =   GETDATE(),   Second   =   DATEDIFF(Second,   @dt,   GETDATE())
GO

SELECT COUNT(*) FROM RandomNumber
GO

--drop table RandomNumber

本文链接

各种按日期、时间段统计SQL语句

2010-06-08T01:49:00Z

--前一日
select * from 表名 where datediff(d,cast(日期 as datetime),getdate())=1

--上周

select * from 表名 where datediff(ww,cast(日期 as datetime),getdate())=1

--上周

select * from 表名 where DATEPART(ww, 日期) = DATEPART(ww, GETDATE())-1 and DATEPART(yy, 日期) = DATEPART(yy, GETDATE())

--上月

select * from 表名 where datediff(month,cast(日期 as datetime),getdate())=1

--上年

select * from 表名 where datediff(year,cast(日期 as datetime),getdate())=1

--按日统计

select count(*),day([date]) from 表名 where year([date]) = '2006' group by day([date])

--按周

select count(*),datename(week,[date]) from 表名 where year([date]) = '2006' group by datename(week,[date])

--按月

select count(*),month([date]) from 表名 where year([date]) = '2006' group by month([date])

--按季

select count(*),datename(quarter,[date]) from 表名 where year([date]) = '2006' group by datename(quarter,[date])

--按年

select count(*),year([date]) from 表名 where
year([date]) >= '2000' group by year([date])

本文链接

SQL 分析函数over partition 分组数据后取前N条

2009-12-15T09:25:00Z

将 ATable 表，如下 A B C aa sx 1000 aa zh 900 bb jj 1100 bb zh 500 bb gg 400 bb wd 300 bb sh 150 cc sh 1500 转换为BTable表，如下 A B C aa sx 1000 aa zh 900 bb jj 1100 bb zh 500 bb gg 400 cc sh 1500 即不满三条的数据，全部取出，...

增加排名列SQL语句（需排名的列值相等时排名相同）

2009-11-28T10:22:00Z

sql 查询数据时按某列排序后增加排名列，需排名的列值相等时排名相同，即如需排名列数组为：9，9，8，7，7，6添加的排名列数组需要显示为两种：第一种：1，1，3，4，4，6 （这种排名方法应该是最普遍的排名方法啦）或者第二种：1，1，2，3，3，4 （某些特殊情况需要）

GridView样式设置

2009-11-20T07:48:00Z

GridView在生成HTML代码的时候会自动加上style="border-collapse:collapse;"以及border=1，rules="all"这些属性，这些在IE下都没什么影响，但是在FF下就会影响显示，style="border-collapse:collapse;"；是由于设置了CellSpacing="0"产生的，当设置CellSpacing="1"后就没有，可以去掉style="border-collapse:collapse;"；默认情况下CellSpacing="0"，所以默认情况下会有style="border-collapse:collapse;"这个属性生成。GridLines="Both"会带来border=1，rules=all这两个属性，设置GridLines="None"后border=0，rules属性则不会出现。

笔记下UltraEdit的一些常用使用技巧

2009-11-17T09:29:00Z

UltraEdit 是每天必用的工具之一．但想想看，实际使用到的功能只是这个工具强大功能的极小的一部分．灵活使用这个工具有的时候能起到事半功倍的效果．记录并收集一些小技巧对自己对别人都有帮助．