Floating Heart

30 分钟快快乐乐学 SQL Performance Tuning

2009-01-04T05:20:00Z

http://www.cnblogs.com/WizardWu/archive/2008/10/27/1320055.html

有些程序员在撰写数据库应用程序时，常专注于 OOP 及各种 framework 的使用，却忽略了基本的 SQL 语句及其「性能 (performance) 优化」问题。版工曾听过台湾某半导体大厂的新进程序员，所组出来的一段 PL/SQL 跑了好几分钟还跑不完；想当然尔，即使他的 AJAX 及 ooxx 框架用得再漂亮，系统性能也会让使用者无法忍受。以下是版工整理出的一些数据库规划、SQL performance tuning 简单心得，让长年钻研 .NET、AJAX、一堆高深 ooxx framework，却无暇研究 SQL statement 的程序员，透过最短时间对本帖的阅读，能避免踩到一些 SQL 的性能地雷。

(注：本帖的 SQL 语句皆经过测试可正常执行无误。有兴趣实验者，可直接拷贝后，粘贴至 SQL Server 中执行。)

1、数据库设计与规划

• Primary Key 字段的长度尽量小，能用 small integer 就不要用 integer。例如员工数据表，若能用员工编号当主键，就不要用身分证号码。

• 一般字段亦同。若该数据表要存放的数据不会超过 3 万笔，用 small integer 即可，不必用 integer。

• 文字字段若长度固定，如：身分证号码，就不要用 varchar 或 nvarchar，应该用 char 或 nchar。

• 文字字段若长度不固定，如：地址，则该用 varchar 或 nvarchar。除了可节省存储空间外，存取硬盘时也会较有效率。

• 设计字段时，若其值可有可无，最好也给一个默认值，并设成「不允许 NULL」(一般字段默认为「允许 NULL」)。因为 SQL Server 在存放和查询有 NULL 的数据表时，会花费额外的运算动作 [2]。

• 若一个数据表的字段过多，应垂直切割成两个以上的数据表，并可用同名的 Primary Key 一对多连结起来，如：Northwind 的 Orders、Order Details 数据表。以避免在存取数据时，以「集簇索引 (clustered index)」扫描时会加载过多的数据，或修改数据时造成互相锁定或锁定过久。

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

2、适当地建立索引

• 记得自行帮 Foreign Key 字段建立索引，即使是很少被 JOIN 的数据表亦然。

• 替常被查询或排序的字段建立索引，如：常被当作 WHERE 子句条件的字段。

• 用来建立索引的字段，长度不宜过长，不要用超过 20 个 Byte 的字段，如：地址。

• 不要替内容重复性高的字段建立索引，如：性别；反之，若重复性低的字段则适合建立索引，如：姓名。

• 不要替使用率低的字段建立索引，以免浪费硬盘空间。

• 不宜替过多字段建立索引，否则反而会影响到「INSERT、UPDATE、DELETE」的性能，尤其是以「OLTP (联机事务处理；在线交易)」为主的网站数据库。

• 若数据表存放的数据很少，就不必刻意建立索引。否则可能数据库沿着存放索引的「树状结构」(Balanced Tree) 去搜寻索引中的数据，反而比扫描整个数据表还慢。

• 若查询时符合条件的数据很多，则透过「非集簇索引 (non-clustered index)」搜寻的性能，反而可能不如整个数据表逐笔扫描。

• 建立「集簇索引」的字段选择至为重要，会影响到整个索引结构的性能。要用来建立「集簇索引」的字段，务必选择「整数」类型 (键值会较小)、唯一、不可为 NULL。

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

3、适当地使用索引

• 有些书籍会提到，使用「LIKE、%」做模糊查询时，即使您已替某个字段建立索引 (如下方代码的 CustomerID 字段)，但以常量字符开头才会使用到索引，若以万用字符 (%) 开头则不会使用索引，如下所示：

USE Northwind;
GO
SELECT * FROM Orders WHERE CustomerID LIKE 'D%'; --使用索引
SELECT * FROM Orders WHERE CustomerID LIKE '%D'; --不使用索引

在 SQL Server 2005 执行完成后按 Ctrl + L，可检阅如下图的「执行计划」。

图 1　可看出「查询最佳化程序」有使用到索引做搜寻

图 2　在此的「集簇索引」扫描，并未直接使用索引，性能上几乎只等于扫描整个数据表

但经版工反复测试，这种语法是否会使用到索引，抑或会逐笔扫描，并非绝对的。仍要看所下的查询关键词，以及字段内所存储的数据内容而定。但对于存储数据笔数庞大的数据表，最好还是少用 LIKE 做模糊查询。

• 以下的运算符会造成「负向查询」，常会让「查询最佳化程序」无法有效地使用索引，最好能用其它运算符和语法改写 (经版工测试，并非有负向运算符，就绝对无法使用索引)：
NOT 、 != 、 <> 、 !> 、 !< 、 NOT EXISTS 、 NOT IN 、 NOT LIKE

• 避免让 WHERE 子句中的字段，去做字符串的串接或数字运算，否则可能导致「查询最佳化程序」无法直接使用索引，而改采「集簇索引扫描」(经版工测试并非绝对)。

• 数据表中的数据，会依照「集簇索引」字段的顺序存放，因此当您下 BETWEEN、GROUP BY、ORDER BY 时若有包含「集簇索引」字段，由于数据已在数据表中排序好，因此可提升查询速度。

• 若使用「复合索引」，要注意索引顺序上的第一个字段，才适合当作过滤条件。

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

4、避免在 WHERE 子句中对字段使用函数

对字段使用函数，也等于对字段做运算或串接的动作，一样可能会让「查询最佳化程序」无法有效地使用索引。但真正对性能影响最重大的，是当您的数据表内若有 10 万笔数据，则在查询时就需要呼叫函数 10 万次，这点才是真正的性能杀手。程序员应注意，在系统开发初期可能感觉不出差异，但当系统上线且数据持续累积后，这些语法细节所造成的性能问题就会逐步浮现。

SELECT * FROM Orders WHERE DATEPART(yyyy, OrderDate) = 1996 AND DATEPART(mm, OrderDate)=7
可改成
SELECT * FROM Orders WHERE OrderDate BETWEEN '19960701' AND '19960731'

SELECT * FROM Orders WHERE SUBSTRING(CustomerID, 1, 1) = 'D'
可改成
SELECT * FROM Orders WHERE CustomerID LIKE 'D%'

注意当您在下 UPDATE、DELETE 语句时，若有采用 WHERE 子句，也应符合上述原则。。

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

5、AND 与 OR 的使用

在 AND 运算中，「只要有一个」条件有用到索引 (如下方的 CustomerID)，即可大幅提升查询速度，如下图 3 所示：

SELECT * FROM Orders WHERE CustomerID='VINET' AND Freight=32.3800 --使用索引，会出现下图 3 的画面

SELECT * FROM Orders WHERE Freight=32.3800 --不使用索引，会出现上图 2 的画面

图 3

但在 OR 运算中，则要「所有的」条件都有可用的索引，才能使用索引来提升查询速度。因此 OR 运算符的使用必须特别小心。

若您将上方 AND 的范例，逻辑运算符改成 OR 的话，如下所示：

SELECT * FROM Orders WHERE CustomerID='VINET' OR Freight=32.3800

由于无法有效地使用索引，也会出现图 2 的画面。

在使用 OR 运算符时，只要有一个条件 (字段) 没有可用的索引，则其它所有的条件 (字段) 都有索引也没用，只能如图 2 般，把整个数据表或整个集簇索引都扫描过，以逐笔比对是否有符合条件的数据。

据网络上文件的说法 [1]，上述的 OR 运算语句，我们还可用 UNION 联集适当地改善，如下：

SELECT * FROM Orders WHERE CustomerID='VINET'
UNION
SELECT * FROM Orders WHERE Freight=32.3800

此时您再按 Ctrl + L 检阅「执行计划」，会发现上半段的查询会使用索引，但下半段仍用集簇索引扫描，对性能不无小补。

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

6、适当地使用子查询

相较于「子查询 (Subquery)」，若能用 JOIN 完成的查询，一般会比较建议使用后者。原因除了 JOIN 的语法较容易理解外，在多数的情况下，JOIN 的性能也会比子查询较佳；但这并非绝对，也有的情况可能刚好相反。

我们知道子查询可分为「独立子查询」和「关联子查询」两种，前者指子查询的内容可单独执行，后者则无法单独执行，亦即外层查询的「每一次」查询动作都需要引用内层查询的数据，或内层查询的「每一次」查询动作都需要参考外层查询的数据。

以下我们看一个比较极端的例子 [2]。若我们希望所有查询出来的数据，都能另外给一个自动编号，版工我在之前的文章「ASP.NET 数据分页第一篇 - 探讨分页原理及 SQL Server 2005 的 ROW_NUMBER 函数」中有介绍过，可用 SQL Server 2005 中新增的 ROW_NUMBER 函数轻易地达成，且 ROW_NUMBER 函数还能再加上「分群 (PARTITION BY)」等功能，而且执行性能极佳。

图 4　将 Orders 数据表的 830 笔数据都捞出来，并在右侧给一组自动编号

现在我们要如上图 4 般，将 Northwind 数据库中 Orders 数据表的 830 笔数据都捞出来，并自动给一组编号，若用 ROW_NUMBER 函数的写法如下所示，而且性能极佳，只要 2 ms (毫秒)，亦即千分之二秒。

SET STATISTICS TIME ON

SELECT OrderID, ROW_NUMBER() OVER(ORDER BY OrderID) AS 编号
FROM dbo.Orders

但如果是传统的「子查询」写法，或辅以 AS 关键词的「衍生数据表」的语法，写法必须如下 (拷贝后在 SQL Server 中实际可执行)：

SET STATISTICS TIME ON

SELECT OrderID,
(SELECT COUNT(*) FROM dbo.Orders AS 内圈
WHERE 内圈.OrderID <= 外圈.OrderID) AS 编号
FROM dbo.Orders AS 外圈
ORDER BY 编号

但这种旧写法，会像先前所提到的，外层 (外圈) 查询的「每一次」查询动作都需要引用内层 (内圈) 查询的数据。以上方示例而言，外层查询的每一笔数据，都要等内层查询「扫描整个数据表」并作比对和计数，因此 830 笔数据每一笔都要重复扫描整个数据表 830 次，所耗用的时间也因此爆增至 170 ms。

若您用相同的写法，去查询 AdventureWorks 数据库中，有 31,465 笔数据的 Sales.SalesOrderHeader 数据表，用 ROW_NUMBER 函数要 677 ms，还不到 1 秒钟；但用子查询的话，居然要高达 233,835 ms，将近快 4 分钟的时间。

-- 用 ROW_NUMBER 的写法，改查询 AdventureWorks 数据库 (31,465 笔数据，要 677 ms，还不到 1 秒钟)

SELECT SalesOrderID, ROW_NUMBER() OVER(ORDER BY SalesOrderID) AS rownum
FROM Sales.SalesOrderHeader

-- 用「子查询」的写法，改查询 AdventureWorks 数据库 (31,465 笔数据，要 233,835 ms，将近 4 分钟)

SELECT SalesOrderID,
(SELECT COUNT(*) FROM Sales.SalesOrderHeader AS 内圈
WHERE 内圈.SalesOrderID <= 外圈.SalesOrderID) AS 编号
FROM Sales.SalesOrderHeader AS 外圈
ORDER BY 编号

虽然这是较极端的范例，但由此可知子查询的撰写，在使用上不可不慎，尤其是「关联子查询」。程序员在系统开发初期、数据量还很少时感受不到此种 SQL 语法的重大陷阱；但等到系统上线几个月或一两年后，就会有反应迟缓的现象，不可不慎。

注：AS 关键词及「衍生数据表」是 SQL Server 的语法，「衍生数据表」只会存在内存中，AS 关键词的作用是赋予一个别名。过去许多必须用暂存数据表或 View (视图) 的情况，现在都可以用「衍生数据表」来取代，如此一来不但可以降低数据库管理工作的负担，亦可提升查询性能。

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

7、其他查询技巧

• DISTINCT、ORDER BY 语法，会让数据库做额外的计算。此外「联集」的使用，若没有要剔除重复数据的需求，使用 UNION ALL 会比 UNION 更优，因为后者会加入类似 DISTINCT 的算法。

• 在 SQL Server 2005 中，存取数据库对象时，最好明确指定该对象的「结构描述 (Schema)」，也就是使用两节式的名称，如下方代码所示。否则若呼叫者的预设 Schema 不是 dbo，则 SQL Server 在执行时，会先寻找该使用者预设 Schema 所搭配的对象，找不到的话才会转而使用预设的 dbo，会多耗费寻找的时间。因此若要执行一个叫做 dbo.mySP1 的 Stored Procedure，应使用以下的两节式名称：

EXEC dbo.mySP1

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

8、尽可能用 Stored Procedure 取代应用程序直接存取数据表

Stored Procedure 除了经过事先编译、性能较好以外，亦可节省 SQL 语句传递的网络频宽，也方便商业逻辑的重复使用。再搭配自订函数和 View 的使用，将来若要修改数据表结构、重新切割或「反正规化」时亦较方便。

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

9、尽可能在数据来源层，就先过滤数据

使用 SELECT 语法时，尽量避免传回所有的数据至前端而不设定 WHERE 等过滤条件。虽然 ASP.NET 中 SqlDataSource、ObjectDataSource 控件的 FilterExpression 可再做筛选，GridView 控件的 SortExpression 可再做排序，但会多消耗掉数据库的系统资源、web server 的内存和网络频宽。最好还是在数据库和数据来源层，就先用 SQL 条件式或 Stored Procedure 筛选出所要的资料。有关这方面，网友们可参考版工我之前写的「ASP.NET 数据分页」系列的四篇帖子。

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

结论：
本文的观念，不管是写 SQL statement、Stored Procedure、自订函数或 View 皆然。本文只是挑出程序员较容易犯的 SQL 语法性能问题，以期能在短时间浏览过本文后，在写 ADO.NET 程序时能修正以往随兴的 SQL 语句撰写习惯。文中提到的几点，只不过是 SQL 语法性能议题的入门。市面上有很多更进阶的书籍，例如：「The Art of SQL」、「SQL Tuning」，亦有针对 Oracle 或 SQL Server 数据库撰写的 performance tuning 相关书籍，有兴趣者可自行翻阅。

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

参考文件：

[1] SQL 查询最佳化 (网际乌托邦)：
http://www.ithome.com.tw/plog/index.php?op=ViewArticle&articleId=5421&blogId=620

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

参考书籍：

[2] SQL Server 2005 Performance Tuning 效能调校 (台湾书籍)：
作者：胡百敬、姚巧枚、刘承修
出版社：悦知出版社
http://tlsj.tenlong.com.tw/WebModule/BookSearch/bookSearchViewAction.do?isbn=9789866761225&sid=41966

[3] SQL Server 2005 完全实战 (台湾书籍)：
作者：章立民
出版社：碁峰出版社
http://tlsj.tenlong.com.tw/WebModule/BookSearch/bookSearchViewAction.do?isbn=9789861810454&sid=31975

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

网站性能越来越差怎么办？

2009-01-04T05:17:00Z

http://www.cnblogs.com/WizardWu/archive/2009/01/03/1367527.html

新的一年，你的老板或客户，是否曾和你抱怨公司的网站性能愈来愈差？网站大家都会写，自从有了 Visual Studio 之后，连你家楼下的正妹小喵和隔壁的王大婶都会写 ASP.NET。但同样的一个画面，背后的性能却可能是天差地远，更惶论多人同时上线的企业网站，而程序员的身价也因此有所差别。本帖提供一些改善网站性能的点子，从硬件、软件、程序技巧的层面都有，也欢迎大家分享自己的经验或秘技。

(1) 重新调整或重新设计 DB schema、索引 (index)

一个在线系统的性能不佳，主要原因都是来自于数据库规划及 SQL 语句层面，至于 .NET 程序撰写不良都还在其次。

先将数据库适度地做正规化，如：一个 Table 中，避免把常用的字段、很少用的字段，都塞在同一个表中，而影响数据扫描的速度。
应该将很少用的字段，另切割出来成为另一个表。

请参考:
30 分钟快快乐乐学 SQL Performance Tuning:
http://www.cnblogs.com/WizardWu/archive/2008/10/27/1320055.html

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

(2) 改写 SQL 语句，注意 index 是否在查询时有真的被用到

* 同样的功能，一个不良的「关联子查询」和良好的「独立子查询」，之间的 SQL 性能差距，是不到一秒钟和好几分钟以上的差距。

* 一些 SQL 关键词，只要一出现在 SQL 语句中，就可能造成表的「索引 (index)」完全失效或部分失效，变成要整个表去逐行逐列地扫描，
例如: NOT、NOT IN、!=、<>、OR ...等关键词，
还有「LIKE '%关键词'」的模糊查询，也会造成索引失效，但「LIKE '关键词%'」就不会造成索引失效。

请参考:
30 分钟快快乐乐学 SQL Performance Tuning:
http://www.cnblogs.com/WizardWu/archive/2008/10/27/1320055.html

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

(3) 使用 Native 的 DataProvider

放弃 OleDb，改用 ADO.NET Native 的 DataProvider，如: SqlClient、OracleClient。但若您公司坚持要用 Sybase 这种从 2003 年之后，就不曾更新 DB driver 的数据库，就只好继续用性能不佳的 OleDb 去联机了。

据版工我用 Visual Studio 内建的 stress test 工具，测试 OleDb 和 SqlClient 的性能差距，模拟 30 人同时上线，用浏览器撷取一万笔数据，两者的速度就差了一秒钟；且当数据库的数据越多，或越多人同时上线时，性能差距会更明显。

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

(4) 用程序或软件做缓存

用程序做缓存，如 ASP.NET 从 1.x 时代，就已内建的 Cache (缓存) 机制；或用一些第三方的辅助软件、Framework，这方面若有其它网友知道好用的软件，亦恳请留言告知。

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

(5) 用硬件做快取或缓冲、砸钱加装 AP Server

ITHome - 游戏基地网页效能提升的关键人物 (此连结连至台湾网页，若无法开启敬请见谅) :
http://www.ithome.com.tw/itadm/article.php?c=52558

以下引用自原文:

种种缺失使得网站的使用人数锐减。面对网站一堆问题，陈xx也决定要将网站再次大幅度调整，将之前的网页程序，以及 SQL 查询语句全部重写，他们花了三个月的时间执行。

陈xx还在原本的网页服务器，与数据库服务器的架构中，加入一组应用程序服务器，作为网页服务器 cache 数据的来源。

改版之后的新网站，搜寻速度提升许多，先前每日的统计数据中，处理速度超过 3 秒的数据超过 50 万笔；而改版后，每星期超过 3 秒的查询不到 10 笔，而这少数反应速度不够快的查询，也多是内部作业执行大量批处理导致的。

由于原本使用的 L4 Switch 较为老旧，负载量比较差，因此陈xx选择将它汰换新的设备，加强负载量；恰好那时正好准备将应用服务器的架构上线，就藉此机会将网络架构更新。陈xx说，这样的架构搭配负载较强的 L4 交换器，强化网站的处理性能，并凭借此抵御网络攻击。在此之后，网站依然会受到零星攻击，但都不会对造成太大影响。

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

(6) 用硬件做快取或缓冲、砸钱加装 AP Server

数字之墙 - 网站外销的个人实践（二）运营 (此连结连至台湾网页，若无法开启敬请见谅) :
http://epaper.pchome.com.tw/adm/brief_left.htm?s_code=0263

以下引用自原文:

全盛时期，来自美国 blog 的流量每天达 80 万次。这个数字其实不高，对程序高手来说是小菜一碟，但笔者是半吊子工程师，知识有限也因此可能程序写得不好，频频被主机供货商发信警告，要求改善网站系统性能。最后，我决定开发 cache system。

cache system 缓存系统上线后，将数据库读写，从每天 80 万次降低到每天 16 万次。这期间也请高手朋友帮忙进行数据库结构优化，帮助很大。笔者在过程中学习到，一个良好的「缓存系统 (cache system)」对于提供 Widget 功能的网站来说非常重要。

…中间略…

能够做到随时搬迁整个网站到另一家主机供货商，除了程序本身的调整外，还要归功于网站管理软件的盛行。在此要推荐的一套称为 Plesk 的网站管理软件。有的主机供货商会直接帮你安装 Plesk ，免费或另外付费。 Plesk 的所有管理功能都是透过 Web 界面，方便到无以复加，大大降低对技术能力的要求。

除了 Plesk 以外，网站管理软件还有其它选择。还有 WHM 加上 cPanel 的组合，也是常见的网站管理解决方案。不过笔者还是比较偏好使用 Plesk，毕竟使用起来容易，也难怪他们的市场占有率一直是独大。只是，功力高的工程师可能会喜欢 WHM + cPanel，因为弹性比较大。不论选择哪一种，都可以帮助你节省许多时间。

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

(7) 加装实体机器做 Loading Balance (负载平衡)。一些 Server OS 亦内建此类设定功能。

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

(8) 程序技巧 - ADO.NET

能用 DataReader 就不要用 DataSet / DataTable，前者读取速度快又不耗内存；后者虽较有弹性，但速度较慢又会每个使用者消耗许多内存。若您连 DropDownList 控件的数据来源，都用 SqlDataSource 控件的默认值 - DataSet，则当页面里塞了一堆下拉选单时，性能当然会受影响。

但前提是程序员对 ADO.NET 要有一定程度的了解，若只会用 Visual Studio 透过图形界面，拖拉 TableAdapter、DataTable、.xsd 就免谈了。

若为 DataTable 建立 Primary Key，DataTable 会建立一个索引，追踪新增到 DataTable 中的数据是否符合此条件约束 (constraint)。ADO.NET 2.0 会使用 algorithm 的「红黑树算法 (Red-Black Tree，是一种「平衡树」算法) 去处理索引，让 DataTable 的数据量大时，较方便维护索引；但缺点是建立索引时会降低一些性能。

此外，数据库的走访和捞值，应该尽量在一次 DB connection 做完，一个 connection 可搭配多个 DbCommand 对象使用，不用每次都一个 DbConnection 配一个 DbCommand。

在此推荐一本不错的 ADO.NET 原文书:

Programming Microsoft ADO.NET 2.0 Core Reference:
http://www.amazon.com/Programming-Microsoft%C2%AE-ADO-NET-Core-Reference/dp/073562206X/ref=sr_1_1?ie=UTF8&s=books&qid=1230971264&sr=1-1

有探讨许多市面上书籍少见的深入内容，像 Oracle + ADO.NET 的各种应用、Connection Pooling 的特性、各种的数据库 Balk (批次) 作业应用。

请参考:

适时调整 SqlDataSource 控件的 DataSourceMode 属性:
http://www.cnblogs.com/WizardWu/archive/2008/07/15/1243661.html

使用 ADO.NET 的 NextResult 方法取得多个 Result Set:
http://www.cnblogs.com/WizardWu/archive/2008/07/11/1241174.html

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

(9) 程序技巧 - .NET 语法

* 避免一些书上教的，把 DataTable 或大量数据，直接塞进 Session 里，此举在真正要上线的系统必死无疑。Session 在多人同时上线时，内存的消耗是很可观的，因为 Session 是每个用户各存一份在服务器的内存里，而非像「缓存 (cache)」是所有的用户共享服务器的一块内存。在很多 ASP.NET 的需求中，可用 HiddenField 控件或 ViewState 取代 Session。

* 能用「泛型 (Generics)」就不要用旧版的写法，Generics 除了安全外，亦可避免 .NET 类型在 Boxing / Unboxing 转型时影响性能，例如:
能用 List<string> 就不要用旧的 ArrayList，能用 Dictionary<TKey,TValue> 就不要用 Hashtable 或跑双层的循环 (loop)，因 ArrayList、Hashtable 的 element 属于 object 类型，在存储或检索时，会引发 Boxing / Unboxing。

当然上述前提，是系统要用 .NET 开发，还在靠 ASP 或非 OOP 语言硬撑的旧系统就免谈了。

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

(10) 程序技巧 - 数据库「事务 (Transaction)」

您是否知道 SQL Server 的默认「事务隔离等级 (Isolation Level)」，是「ReadCommitted」，当您在写 ADO.NET 用了 SqlTransaction 时，默认是当某个人在修改某一笔记录时，其它所有读取这一笔记录的人，都会被「锁定 (lock)」住，造成其它全部用户的浏览器都在等待中，无法做其它工作。

而 Oracle 事务的特性，是绝不会有类似无法读取的情形，至少会用类似 SQL Server 2005 新增的「快照隔离 (Snapshot Isolation)」，让用户至少能先读取到未 Commit 或 Rollback 的记录，而不用呆坐在浏览器前面傻等。

不过 SQL Server 2005 的「快照隔离」默认未启用。用 SQL Server 开发的系统，若怕用户被锁定的问题，可视 project 需求，改用最宽松的「ReadUncommitted」事务隔离等级，其特性为不会造成任何锁定，但可能会造成 Dirty Read。SQL Server 有下列七种「事务隔离等级」，有兴趣的网友可去查询 ADO.NET 书籍或 MSDN Library:

Chaos
ReadCommitted　　// SQL Server 默认值
ReadUncommitted　// 最宽松，会有 Dirty Read
RepeatableRead
Serializable　　　　// 最严，会有大量的锁定
Snapshot
Unspecified

请参考:

Oracle 11g 学习笔记 (5):
http://www.cnblogs.com/WizardWu/archive/2008/12/07/1349665.html

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

(11) ASP.NET 分页

GridView + SqlDataSource 的默认行为，就是每次换页或排序时，不管数据库有几笔记录都全部重捞一次；当数据库有一百万笔数据，就在每个用户换页时，都一百万笔全部重捞出来，此举消耗了大量的 Web server/ AP server 内存、数据库系统资源、网络频宽，结果网站性能可想而知。

很多企业内的小型网站，为了省钱，随便外包给低价抢标的工作室，或没经验的学生和 SOHO 族，可能因此埋下了恐怖的后遗症。最可怕的是这些未爆弹，在开发期间和系统刚上线、数据量还很少时，都感觉不出来，有如癌症一样，会在将来忽然爆发。

请参考:

ASP.NET 数据分页 1 ~ 4 篇 series :
(有现成的 ASP.NET 2.0 + ObjectDataSource 控件 + Stored Procedure 做「分页」的示例可下载)
http://www.cnblogs.com/WizardWu/archive/2008/09/28/1301616.html
http://www.cnblogs.com/WizardWu/archive/2008/09/07/1286270.html
http://www.cnblogs.com/WizardWu/archive/2008/08/06/1261589.html
http://www.cnblogs.com/WizardWu/archive/2008/08/02/1258832.html
http://blog.sina.com.tw/4907/article.php?pbgid=4907&entryid=3921

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

(12) ASP.NET AJAX 的 UpdatePanel 控件不是万能的

以下引用自 MSDN Magazine:

不论好坏，UpdatePanel 控件都是 ASP.NET AJAX 社区所喜爱的。我说“好”，是因为 UpdatePanel 使部分页面呈现变得相当简单，而说“坏”，是因为它的简便和易用性是以效率和令人啼笑皆非的带宽为代价的。

UpdatePanel 可以为一般的网页带来 AJAX 神奇的好处，但是它不能提供我们与 AJAX 正常关联的高效性。例如，您是否知道，当 UpdatePanel 控件对服务器执行异步 AJAX 回调以更新其内容时，这个请求包含了常规 ASP.NET 回发所包含的一切，其中还包括 ViewState 呢？具有太多 ViewState 的页面会降低性能，并且具有太多 ViewState 的页面在 ASP.NET 应用程序中都太常见。

如果您准备使用 UpdatePanel 控件，您需要清楚您在准备干什么。在许多情况下，从性能的角度而言，应用程序最好是不使用 UpdatePanel，而是使用对 WebMethods 或页面方法的异步调用。

…中間略…

当您使用 UpdatePanel 在一个页面上执行无闪烁更新时，您可能会认为您在进行高效构建。毕竟，UpdatePanel 使用的是 AJAX，不是吗？不幸的是，如果您在 UpdatePanel 更新时检验一下网络中的通信，您会发现您根本就没有保存什么东西，至少是在发送的时候没有保存。通常在回发期间传送到服务器的 ViewState 数据（与其他数据）也会在 UpdatePanel 回调期间传送。事实上，来自 UpdatePanel 的异步 XML-HTTP 请求中所增长的数据，几乎与在标准 ASP .NET 回发中增长的数据相同。下面是有关 ASP.NET AJAX 不可告人的秘密：UpdatePanel 虽易于使用，但是通信效率不高。

几乎没有什么办法可让您提高 UpdatePanel 的效率，但是您可以放弃使用 UpdatePanel，并转而使用 ASP.NET AJAX 的其他功能来更新页面内容，它不仅同样流畅，而且更加高效。它只需要多一点点力气，但是最后的结果往往让人觉得是值得付出的，因为您可以大大降低在客户端与服务器之间传输的数据量。

请参考:

UpdatePanel 提示和技巧 (MSDN Magazine, 2007/6):
http://msdn.microsoft.com/zh-cn/magazine/cc163413.aspx

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

(13) Design Patterns

虽然「设计模式」不是为解决性能问题而诞生的，但可适度防止没经验的新人做出蠢事。多学一些 .NET 技术敌营注重的系统架构、OOAD、Design Patterns 和相关的 Framework，对提升自己的身价和薪资也有帮助。

相關書籍:

C# 3.0 Design Patterns:
http://oreilly.com/catalog/9780596527730/index.html

Head First Design Patterns:
http://oreilly.com/catalog/9780596007126/index.html

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

ASP.NET MVC Framework Series by ScottGu

2009-01-03T05:55:00Z

ASP.NET MVC Road-Map Update

Introducing the ASP.NET MVC Framework

ASP.NET MVC Framework Tutorial Part 1

ASP.NET MVC Framework Tutorial Part 2: URL Routing

ASP.NET MVC Framework Tutorial Part 3: Passing ViewData from Controllers to Views

ASP.NET MVC Framework Tutorial Part 4: Handling Form Edit and Post Scenarios

ASP.NET MVC Source Code Now Available

ASP.NET MVC Source Refresh Preview

ASP.NET MVC Preview 3 Release

ASP.NET MVC Preview 4 Release Part 1

ASP.NET MVC Preview 5 and Form Posting Scenarios

More Posts

一位软件工程师的6年总结

2008-12-28T00:45:00Z

http://blog.csdn.net/java2000_net/archive/2008/08/29/2850290.aspx

作者：成晓旭

“又是一年毕业时”，看到一批批学子离开人生的象牙塔，走上各自的工作岗位；想想自己也曾经意气风发、踌躇满志，不觉感叹万千……本文是自己工作6年的经历沉淀或者经验提炼，希望对所有的软件工程师们有所帮助，早日实现自己的人生目标。本文主要是关于软件开发人员如何提高自己的软件专业技术方面的具体建议，前面几点旨在确定大的方向，算是废话吧。

谨以此文献给那个自己为你奉献3年青春与激情的开发团队。还有团队成员：PPL、YT、YK 、TYF、LGL、CHL、CDY、CB、DPD。

1、分享第一条经验：“学历代表过去、能力代表现在、学习力代表未来。”其实这是一个来自国外教育领域的一个研究结果。相信工作过几年、十几年的朋友对这个道理有些体会吧。但我相信这一点也很重要：“重要的道理明白太晚将抱憾终生！”所以放在每一条，让刚刚毕业的朋友们早点看到哈！

2、一定要确定自己的发展方向，并为此目的制定可行的计划。不要说什么，“我刚毕业，还不知道将来可能做什么？”，“跟着感觉走，先做做看”。因为，这样的观点会通过你的潜意识去暗示你的行为无所事事、碌碌无为。一直做技术，将来成为专家级人物？向管理方向走，成为职业经理人？先熟悉行业和领域，将来自立门户？还是先在行业里面混混，过几年转行做点别的？这很重要，它将决定你近几年、十年内“做什么事情才是在做正确的事情！”。

3、软件开发团队中，技术不是万能的，但没有技术是万万不能的！在技术型团队中，技术与人品同等重要，当然长相也比较重要哈，尤其在MM比较多的团队中。在软件项目团队中，技术水平是受人重视和尊重的重要砝码。无论你是做管理、系统分析、设计、编码，还是产品管理、测试、文档、实施、维护，多少你都要有技术基础。算我孤陋寡闻，我还真没有亲眼看到过一个外行带领一个软件开发团队成功地完成过软件开发项目，哪怕就一个，也没有看到。倒是曾经看到过一个“高学历的牛人”(非技术型)带一堆人做完过一个项目，项目交付的第二天，项目组成员扔下一句“再也受不了啦！”四分五裂、各奔东西。那个项目的“成功度”大家可想而知了。

4、详细制定自己软件开发专业知识学习计划，并注意及时修正和调整(软件开发技术变化实在太快)。请牢记：“如果一个软件开发人员在1、2年内都没有更新过自己的知识，那么，其实他已经不再属于这个行业了。”不要告诉自己没有时间。来自时间管理领域的著名的“三八原则”告诫我们：另外的那8小时如何使用将决定你的人生成败！本人自毕业以来，平均每天实际学习时间超过2小时。

5、书籍是人类进步的阶梯，对软件开发人员尤其如此。书籍是学习知识的最有效途径，不要过多地指望在工作中能遇到“世外高人”，并不厌其烦地教你。对于花钱买书，我个人经验是：千万别买国内那帮人出的书！我买的那些家伙出的书，!00%全部后悔了，无一本例外。更气愤的是，这些书在二手市场的地摊上都很难卖掉。“拥有书籍并不表示拥有知识；拥有知识并不表示拥有技能；拥有技能并不表示拥有文化；拥有文化并不表示拥有智慧。”只有将书本变成的自己智慧，才算是真正拥有了它。

6、不要仅局限于对某项技术的表面使用上，哪怕你只是偶尔用一、二次。“对任何事物不究就里”是任何行业的工程师所不应该具备的素质。开发Windows应用程序，看看Windows程序的设计、加载、执行原理，分析一下PE文件格式，试试用SDK开发从头开发一个Windows应用程序；用VC＋＋、 Delphi、Java、.Net开发应用程序，花时间去研究一下MFC、VCL、J2EE、.Net它们框架设计或者源码；除了会用J2EE、 JBoss、Spring、Hibernate等等优秀的开源产品或者框架，抽空看看大师们是如何抽象、分析、设计和实现那些类似问题的通用解决方案的。试着这样做做，你以后的工作将会少遇到一些让你不明就里、一头雾水的问题，因为，很多东西你“知其然且知其所以然”！

7、在一种语言上编程，但别为其束缚了思想。“代码大全”中说：“深入一门语言编程，不要浮于表面”。深入一门语言开发还远远不足，任何编程语言的存在都有其自身的理由，所以也没有哪门语言是“包治百病”的“灵丹妙药”。编程语言对开发人员解决具体问题的思路和方式的影响与束缚的例子俯拾皆是。我的经验是：用面对对象工具开发某些关键模块时，为什么不可以借鉴C、C51、汇编的模块化封装方式？用传统的桌面开发工具(目前主要有VC++、Delphi)进行系统体统结构设计时，为什么不可以参考来自Java社区的IoC、AOP设计思想，甚至借鉴像Spring、Hibernate、JBoss等等优秀的开源框架？在进行类似于实时通信、数据采集等功能的设计、实现时，为什么不可以引用来自实时系统、嵌入式系统的优秀的体系框架与模式？为什么一切都必须以个人、团队在当然开发语言上的传统或者经验来解决问题？？？“他山之石、可以攻玉”。

8、养成总结与反思的习惯，并有意识地提炼日常工作成果，形成自己的个人源码库、解决某类问题的通用系统体系结构、甚至进化为框架。众所周知，对软件开发人员而言，有、无经验的一个显著区别是：无经验者完成任何任务时都从头开始，而有经验者往往通过重组自己的可复用模块、类库来解决问题（其实这个结论不应该被局限在软件开发领域、可以延伸到很多方面）。这并不是说，所有可复用的东西都必须自己实现，别人成熟的通过测试的成果也可以收集、整理、集成到自己的知识库中。但是，最好还是自己实现，这样没有知识产权、版权等问题，关键是自己实现后能真正掌握这个知识点，拥有这个技能。

9、理论与实践并重，内外双修。工程师的内涵是：以工程师的眼光观察、分析事物和世界。一个合格的软件工程师，是真正理解了软件产品的本质及软件产品研发的思想精髓的人（个人观点、欢迎探讨）。掌握软件开发语言、应用语言工具解决工作中的具体问题、完成目标任务是软件工程师的主要工作，但从软件工程师这个角度来看，这只是外在的东西，并非重要的、本质的工作。学习、掌握软件产品开发理论知识、软件开发方法论，并在实践中理解、应用软件产品的分析、设计、实现思想来解决具体的软件产品研发问题，才是真正的软件工程师的工作。站在成熟理论与可靠方法论的高度思考、分析、解决问题，并在具体实践中验证和修正这些思想与方式，最终形成自己的理论体系和实用方法论。

10、心态有多开放，视野就有多开阔。不要抱着自己的技术和成果，等到它们都已经过时变成垃圾了，才拿出来丢人现眼。请及时发布自己的研究成果：开发的产品、有创意的设计或代码，公布出来让大家交流或者使用，你的成果才有进化和升华的机会。想想自己2000年间开发的那些Windows系统工具，5、6年之后的今天，还是那个样子，今天流行的好多Windows系统工具都比自己的晚，但进化得很好，且有那么多用户在使用。并且，不要保守自己的技术和思想，尽可能地与人交流与分享，或者传授给开发团队的成员。“与人交换苹果之后，每个人还是只有一个苹果；但交换思想之后，每个人都拥有两种思想”，道理大家都懂，但有多少人真正能做到呢？

11、尽量参加开源项目的开发、或者与朋友共同研制一些自己的产品，千万不要因为没有钱赚而不做。网络早已不再只是“虚拟世界”，网上有很多的开源项目、合作开发项目、外包项目，这都是涉猎工作以外的知识的绝好机会，并且能够结识更广的人缘。不要因为工作是做ERP，就不去学习和了解嵌入式、实时、通信、网络等方面的技术，反过来也是一样。如果当他别人拿着合同找你合作，你却这也不会，那也不熟时，你将后悔莫及。

12、书到用时方恨少，不要将自己的知识面仅仅局限于技术方面。诺贝尔经济学奖得主西蒙教授的研究结果表明： “对于一个有一定基础的人来说，他只要真正肯下功夫，在6个月内就可以掌握任何一门学问。”教育心理学界为感谢西蒙教授的研究成果，故命名为西蒙学习法。可见，掌握一门陌生的学问远远没有想想的那么高难、深奥。多方吸取、广泛涉猎。极力夯实自己的影响圈、尽量扩大自己的关注圈。财务、经济、税务、管理等等知识，有空花时间看看，韬光养晦、未雨绸缪。

13、本文的总结与反思：不要去做技术上的高手，除非你的目标如此。虽然本文是关于提高软件开发知识的建议，做技术的高手是我一向都不赞同的。你可以提高自己的专业知识，但能胜任工作即止。提高软件知识和技术只是问题的表面，本质是要提高自己认识问题、分析问题、解决问题的思想高度。软件专业知识的很多方法和原理，可以很容易地延伸、应用到生活的其它方面。在能胜任工作的基础上，立即去涉猎其它领域的专业知识，丰富自己的知识体系、提高自己的综合素质，尤其是那些目标不在技术方面的朋友

Nagios

2008-12-17T00:41:00Z

Nagios is the industry standard in enterprise-class monitoring for good reason. It allows you to gain insight into your network and fix problems before customers know they even exist. It's stable, scalable, supported, and extensible. Most importantly, it works.

What does Nagios provide?

Comprehensive Network Monitoring
--------------------------------------------------------------------------------
Windows
Linux/Unix
Routers, Switches, Firewalls
Printers
Services
Applications

Immediate Awareness and Insight
--------------------------------------------------------------------------------
Receive immediate notifications of problems via email, pager and cellphone
Multi-user notification escalation capabilities
See detailed status information through the Nagios web interface

Problem Remediation
--------------------------------------------------------------------------------
Acknowledge problems through the web interface
Automatically restart failed applications, services and hosts with event handlers

Proactive Planning
--------------------------------------------------------------------------------
Schedule downtime for anticipated host, service, and network upgrades
Capacity planning capabilites through usage monitoring

Reporting Options
--------------------------------------------------------------------------------
SLA availability reports
Alert and notification history reports
Trending reports through integration with Cacti and RRD-based addons

Multi-Tenant/Multi-User Capabilites
--------------------------------------------------------------------------------
Multiple users can access the web interface
Each user can have their own unique, restricted view

Integration With Your Existing Applications
--------------------------------------------------------------------------------
Trouble ticket systems
Wikis

Easily Extendable Architecture
--------------------------------------------------------------------------------
Over 200 community addons are available to enhance Nagios

Stable, Reliable, and Respected Platform
--------------------------------------------------------------------------------
10 years in development
Scales to monitor 100,000+ nodes
Failover protection capabilities
Winner of multiple awards
Constant media coverage

Huge Community
--------------------------------------------------------------------------------
250,000+ users worldwide
Active mailing lists
Extensive community website network

Customizable Code
--------------------------------------------------------------------------------
Open Source Software
Full access to source code
Released under the GPL license

Nagios远程监控软件的安装与配置详解(1)
Nagios远程监控软件的安装与配置详解(2)
Nagios远程监控软件的安装与配置详解(3)

Oxite

2008-12-10T13:26:00Z

What is this?

This is a simple blog engine written using ASP.NET MVC, and is designed with two main goals:

To provide a sample of 'core blog functionality' in a reusable fashion. Blogs are simple and well understood by many developers, but the set of basic functions that a blog needs to implement (trackbacks, rss, comments, etc.) are fairly complex. Hopefully this code helps.
To provide a real-world sample written using ASP.NET MVC.

We aren't a sample-building team (more on what we are in a bit). We couldn't sit down and build this code base just to give out to folks, so this code is also the foundation of a real project of ours, MIX Online. We also created this project to be the base of our own personal blogs as well so you'll probably see our blogs on the list of sites running Oxite soon.

Getting Started With Oxite

About us

Oxite is a project built by the team behind Channel 9 (and Channel 8, Channel 10, TechNet Edge, Mix Online):

Erik Porter,
Nathan Heskew,
Mike Sampson and
Duncan Mackenzie

You can find out more about our team and our projects in our various posts and videos on Channel 9.

DataTable.Compute Method

2008-11-27T14:23:00Z

你试过循环datatable计算某一列的合计值么，有没试过这种方法：

</span>private void ComputeBySalesSalesID(DataSet dataSet)
{
    // Presumes a DataTable named "Orders" that has a column named "Total."
    DataTable table;
    table = dataSet.Tables["Orders"];


    // Declare an object variable.
    object sumObject;
    sumObject = table.Compute("Sum(Total)", "EmpID = 5");
}

查找一下帮助，你会有更多发现！

New ASP.NET Charting Control:

2008-11-25T13:34:00Z

http://weblogs.asp.net/scottgu/archive/2008/11/24/new-asp-net-charting-control-lt-asp-chart-runat-quot-server-quot-gt.aspx

Microsoft recently released a cool new ASP.NET server control - <asp:chart /> - that can be used for free with ASP.NET 3.5 to enable rich browser-based charting scenarios:

微软出品的免费asp.net图形控件，看样子还挺强大。
又打击一片控件商。干脆全部收购得了。

Visual Studio 2010 and .NET Framework 4.0 Training Kit

2008-11-22T13:39:00Z

Visual Studio 2010和.NET Framework 4.0培训包包含了介绍，动手实战教程和例子，包括以下内容：

C# 4.0
Visual Basic 10
F#
Parallel Computing Platform
WCF
WF
WPF
ASP.NET AJAX 4.0
ASP.NET MVC
Dynamic Data

通过这些内容可以帮助您了解如何使用Visual Studio 2010和.NET Framework 4.0。

Visual Studio 2010 and .NET Framework 4.0 Training Kit下载地址

http://www.microsoft.com/downloads/details.aspx?FamilyID=752cb725-969b-4732-a383-ed5740f02e93&DisplayLang=en

Visual Studio 2010 and .NET Framework 4.0 CTP下载地址

http://www.microsoft.com/downloads/details.aspx?FamilyID=922b4655-93d0-4476-bda4-94cf5f8d4814&DisplayLang=en

Visual Studio 2010 and .NET Framework 4.0 概览

http://msdn.microsoft.com/en-us/vs2008/products/cc948977.aspx